2 Choosing a Transition Strategy

You must have a methodology to select a strategy for transitioning an existing installation of Directory Server Enterprise Edition to Oracle Unified Directory.


Be aware that the selection of the strategy can be an iterative process.


2.1 Analyze Your Requirements

The transition process must be aligned with your architectural and operational requirements. The selection of the right transition strategy is a key factor for a smooth transition to OUD.

The following are important factors to consider when selecting a transition strategy:

2.1.1 Coexistence of the (O)DSEE and OUD Topologies in Production

Using a coexisting approach provides an incremental transition process where the (O)DSEE and OUD deployments coexist and are synchronized in a production environment while client applications are redirected progressively to OUD.

The coexisting approach also allows applications to revert back to (O)DSEE without any interruption of service.

It is important to be aware that some added-value services/features provided by OUD cannot be deployed until the end of the coexistence so it is recommended to use this strategy for a specific period of time only. Similarly, the topology will not be able to deliver improved write performance made possible by OUD until changes are no longer replicated back to (O)DSEE.

Keeping two environments in production requires additional system resources because the two infrastructures must be managed separately. Furthermore, keeping the two environments synchronized also adds complexity to the system so it is recommended to evaluate whether coexistence is a key requirement or not for your transition project.

2.1.2 Ensuring Coexistence of (O)DSEE and OUD Topologies

During replication all data is copied, synchronized, and kept up-to-date across servers. However, each server does not necessarily contain identical data, especially metadata and certain guidelines have to be followed for coexistence of ODSEE and OUD topologies.

If you choose to have ODSEE and OUD topologies coexist in production, then follow these guidelines:

  • Evaluate the level of data consistency you expect between the two environments.

  • Decide if you require strong consistency with global replication conflict management to ensure that every change is applied in a coherent and ordered manner.

  • Determine how you prefer to handle temporary data consistency by choosing to accommodate synchronization latency or to require near real time data consistency between (O)DSEE and OUD topologies.

  • Establish if you require full synchronization of password policy-related state, ensuring consistent account locking across the entire typology.


Projects that require coexistence for a very short period of time may not require fully-featured global password policy support. A conflict may occur when the same entry is modified simultaneously on different servers. In this specific situation, full conflict management guarantees that the entry will be identical on both servers.

2.1.3 Impact of the Transition on the (O)DSEE Infrastructure

You have to change the (O)DSEE infrastructure to simplify the transition process.

In some specific cases, limited changes to the (O)DSEE infrastructure may greatly simplify the transition process and make support of specific features possible. For example, such modifications to (O)DSEE may include addition of LDAP schema extensions, modification of password policy mode or deployment of retro changelog.

Determine whether well-identified changes to (ODSEE) are acceptable as part of your transition strategy selection.

2.1.4 Transition With or Without Write Service Interruption

The ability to redirect client traffic from (O)DSEE to OUD without interruption of service is an important factor to consider. Administrators should be aware of the built-in automatic mechanisms that ensure write service during transition. For other projects, the interruption of updates is unacceptable.

Some transition strategies proposed in this guide provide full-write high-availability during transition. Other transition strategies would require deployment of additional components such as proxies able to duplicate traffic.

2.1.5 Changes in User Data Structure

Before transitioning the directory service, you may want to take the opportunity to evaluate the existing directory services architecture and user data structure. Or, you might be fine with the existing architecture, but want to revisit only a subset of the user data.

This guide does not address transitions that involve redesigning the user data structure. Contact your Oracle Support representative if your transition requires changes to the user data structure.

2.2 Supported Transition Strategies

Oracle supports certain strategies to transition an existing installation of Directory Server Enterprise Edition to Oracle Unified Directory.

This section describes the strategies that Oracle supports for your transition, and a decision matrix to assist you in choosing the transition strategy that best fits your technological needs. Choose one of the following strategies:

2.2.1 Coexistence Using the Replication Gateway

Use the Replication Gateway to keep (O)DSEE and Oracle Unified Directory topologies synchronized at the native replication protocol level. Replication through the Gateway has very low latency because it does not involve any polling mechanism.

The Replication Gateway is installed and managed like any other OUD component and performs the required adaptation of replication protocols between (O)DSEE and OUD. The Replication Gateway provides strong data consistency between the two types of directories and fully leverages conflict management. As full directory metadata are replicated, the Replication Gateway also synchronizes internal password policy states, ensuring proper account locking.

The Replication Gateway offers a true two-way replication between (O)DSEE and OUD. It is a high-performance conduit that propagates the updates between heterogeneous replicated topologies without being stored at the gateway level. A unit of replication is the suffix as defined on the (O)DSEE side. You can also run the Replication Gateway in one-way mode so that changes from your directory server are replicated to OUD while changes from OUD will not be reflected on (O)DSEE.

For high availability, at least two Replication Gateway servers are deployed between two (O)DSEE masters and two OUD replication servers in every scenario. This eliminates the risk of a single point of failure.

2.2.2 Coexistence Using Oracle Directory Integration Platform (DIP)

Oracle Directory Integration Platform (DIP) is a multi-purpose synchronization tool used among various repositories.

Oracle Directory Integration Platform (DIP) enables you to do the following:

  • Synchronize (O)DSEE and OUD topologies.

  • Run your directory server with OUD as you transition over time with no downtime.

  • Use the changelogs configured on (O)DSEE and OUD to detect changes and replay them back and forth.

Synchronization triggers periodically and processes a configurable maximum number of changes at each run. DIP synchronizes user data only.

For more information about DIP, see Introduction to Oracle Directory Integration Platform in Administering Oracle Directory Integration Platform.

2.2.3 Direct Transition Strategy

The Direct Transition Strategy uses export and import methods with standard directory administrative commands. The user data and configuration are exported from (O)DSEE, and adapted if necessary, using tools and procedures described in this guide. The user data and configuration are then imported into OUD.

The Direct Transition Strategy is a singular transition, and it is simple and quick. It can be used when interruptions on write capabilities are acceptable. Directory Administrators typically use a load balancer or an LDAP proxy to put the infrastructure in read-only mode, export data from (O)DSEE, import the data to OUD, then redirect the traffic to OUD.

2.2.4 Decision Matrix for Transition Strategy

Oracle supports certain strategies to transition an existing installation of Directory Server Enterprise Edition to Oracle Unified Directory. Follow the decision matrix to choose the transition strategy that best fits your technological needs.

The following decision matrix summarizes the key decisions factors in choosing a transition strategy:

Table 2-1 Decision Factors for Transition Strategies

Decision Factors Coexistence Using Replication Gateway Coexistence Using DIP Direct Transition





Data Consistency Level


Low Latency


Latency Depends on DIP Configuration






Impact on (O)DSEE

Depends on (O)DSEE release and setting (Validating Your Transition Strategy)

Enable retro changelog


Write service availability

Built-in support

Built-in support

Requires additional components (*)

Data adaptation/ Structure changes


Yes (limitations apply)

Yes (can be performed at will)

High Availability

Built-in Support

Deployment Specific


(*) not covered in this guide