Geodatabase replication can be used to create replica trees, similar to version trees, allowing organizations to distribute their data across several geodatabases in a hierarchical structure.

For example, some organizations require the ability to replicate a single organization-wide geodatabase across different offices. Each office has a replica with only the data applicable to its area and can transfer changes of this data to the main office. This allows the main office to perform analysis on data that is up-to-date across the entire extent. Connections are fast within an office, but are much slower between offices. The regional offices can also replicate their geodatabase to local offices in the same way that the main office replicates its geodatabase to the regions.

A replica geodatabase can be used as a central hub to host readers and editors. To keep connection speeds fast, editors can create a replica to check out data from the central hub and perform edits, then check the changes back in by synchronizing with the geodatabase.

The central hub can also be used to propagate changes between multiple child replicas. To move changes from one replica to another, the changes in one replica are first synchronized with the parent (or hub) replica. A second child replica can then synchronize with the parent to get these changes.

Mobile users within an organization, such as a maintenance crew, require the ability to edit a portion of the ArcSDE geodatabase in the field. They need to disconnect completely from the organization's infrastructure, often for a prolonged period of time. When preparing for a particular work order or project, the relevant data would be replicated and transferred to a portable device such as a laptop. This device is then disconnected from the network, enabling the field crew to operate independently of the network. The field crew can continue to work with and modify the replicated data even though the crew is disconnected from the network. When a connection to the network is reestablished, any changes made to the data will be transferred back and synchronized with data maintained in the ArcSDE geodatabase.

Some organizations need to contract out the maintenance for part of their geodatabases and have that contractor provide updates every month. The organization needs to be able to incorporate the contractor's changes without completely reloading the data. It also needs an easy way to review just the updates for the month instead of having to perform QA tests on the entire dataset.

This can be accomplished by sending the contractor a replica of the appropriate data for updates. When the contractor sends the changes back to the organization, they can be synchronized with the data maintained in the ArcSDE geodatabase.

An organization needs to support a group of editors as well as users accessing the system with read-only access. To satisfy the requirements of each group, the organization has two ArcSDE geodatabases. One is a production geodatabase, which is edited directly by the editors, while the other is a replica of this geodatabase and is accessed by the readers. Readers can access this data through ArcIMS or ArcGIS Servers.

In this scenario, the replica in the publication geodatabase is a read-only copy of the production geodatabase. The data on the publication geodatabase does not need to be versioned. The replication can be restricted to sending data in only one direction. Edits are made on the production geodatabase and are sent from it to the publication geodatabase. These edits are transferred and synchronized with the data on the publication geodatabase and then served to the readers.

Within your organization, data management may be divided amongst several different groups. For example, one group may be in charge of managing the utility networks while another is tasked with managing the landbase data for the same area. Another example is where you have teams working on many completely independent projects. The datasets for each project may, for the most part, be from different geographic areas, but the organization wants a central repository for all projects.

Your organization can use geodatabase replication to distribute your data amongst various groups, splitting up data into appropriate projects. Each project team would receive a replica of the necessary data from the central ArcSDE geodatabase. The teams would then edit each replica independently of one another, possibly in separate geographic locations, and transfer those edits to the central ArcSDE geodatabase. Conversely, any edits made to the central ArcSDE geodatabase would be transferred to the appropriate replica in the project teams as well.