Developing a good strategy is a key element of a migration from third-party directories to OUD.
For sake of simplification, migration can be broken down in 5 steps as described below:
User Data Migration
Most companies defined some custom LDAP attributes and object classes. They use them in conjunction with standard LDAP schema. LDAP provides a standard way to define schema extensions, so migration of user data is in general quite straight-forward: Custom schema extensions need to be added to the OUD configuration, user data are exported from the existing directory to the standard LDIF format then re-imported into OUD.
By default, OUD schema checking is strict, some user entries may be rejected when they do not strictly adhere with the LDAP schema. In such case, either fix the data, fix the schema or relax the corresponding schema option in OUD configuration.
Migration of passwords may cause problems if they are encrypted with non-standard algorithms. I plan to cover that in a separate post soon.
Directory Metadata Migration
Most directories, including OUD, store meta data along with the User Data. This may include access control information (aci), collective attributes, ldap sub entries etc. Each directory vendor uses its own model, so this aspect of the migration requires attention and must be carefully planned.
Directory Configuration Migration
Each directory has its own configuration model, so the configuration must be ported to OUD. It includes the LDAP ports the directory listen on, the LDAP naming contexts exposed, database indexes, replication settings, security settings, performance setting, etc. This can be done using OUD graphical interface (ODSM) or using command line dsconfig. This is in general quite simple to migrate the directory configuration to OUD. Special care is needed to manage migration of SSL server certificates if certificate renewal is not an option.
Dealing with hard-wired dependencies in client applications
Some LDAP client application have hard-wired dependencies on a directory vendor and/or version. For instance, an application would query the directory service version string and would take some decision based on that. Some applications may also create/update directory-specific metadata. It is quite difficult to identify such issues upfront, but it is usually good policy to classify client applications based on their LDAP traffic patterns: traffic of provisioning applications should be review first, as the probabilities to have dependencies on vendor-specific interface is higher than for application doing simple authentication.
Oracle Virtual Directory (OVD), part of the Oracle Directory Services Plus can be used to emulate directory-specific features.
Switching from existing directory to OUD
From an operational perspective, it is key to define how the actual switch to OUD will occur: Some customers would favor export and import w/o maintaining the 2 environments in sync. This seems very simple, but this
methodology cannot ensure an highly-available deployment with up-to-date entries on both sides. When this is not acceptable, synchronization tools like DIP (Directory Integration Platform) which is a part of Oracle Directory Services Plus can be used to synchronize user data.
Additional options exist to migrate from Oracle Directory Enterprise Edition (DSEE) to OUD as described here.