LDAP & Directory Migration

What we migrate

• Platform to platform. Legacy NIS, 389 / Red Hat Directory Server, or Oracle Directory Server (ODSEE / Sun DSEE) onto OpenLDAP, or OpenLDAP ↔ Active Directory coexistence
• Major version upgrades. slapd, schema changes, and backend (mdb/bdb) moves
• Consolidation. Collapsing several directories into one authoritative source
• Infrastructure moves. The directory tier to new data centers or cloud

Migrating off Oracle ODSEE

Oracle put Directory Server Enterprise Edition (ODSEE, the Netscape → iPlanet → Sun DSEE lineage) into sustaining support and steers customers toward Oracle Unified Directory. If you’re running ODSEE 11g and want off it, this is a migration we specialize in. OUD is a valid landing spot, but it’s another Oracle license and another Java stack to feed; OpenLDAP gets you onto a fast, open-source directory you fully own. The entries move easily; it’s everything around the entries where ODSEE migrations go wrong:

• ACIs → slapd ACLs. Sun/Netscape aci rules don’t export to OpenLDAP olcAccess. We translate the access model deliberately, rule by rule, and prove it with before/after bind tests.
• Class of Service and roles. ODSEE’s CoS and nsRole virtual attributes have no native OpenLDAP equivalent. We reproduce the behavior with groups, the dyngroup/memberof overlays, or collective attributes, and confirm consuming apps see identical entries.
• Replication. Sun multi-master replication and its replication agreements become OpenLDAP syncrepl / delta-syncrepl, with change history handled by the accesslog overlay.
• Operational attributes. nsAccountLock, nsUniqueId, and password-policy state map to ppolicy and friends, not 1:1. We decide each mapping explicitly so locked accounts stay locked and nothing silently re-activates.
• Config and plugins. ODSEE’s dse.ldif, indexes, and server plugins (referential integrity, attribute uniqueness, MemberOf) translate to OpenLDAP’s cn=config and the matching overlays (refint, unique, memberof).

How we keep it boring

• Run the old and new directories in parallel; nothing is cut over until the new one is proven
• Replicate or sync entries across; reconcile schema and ACL differences explicitly, not by accident
• Cut over reads first, writes last, with a tested rollback at every step
• Validate binds, group membership, and every app integration before and after

What you avoid

Lost entries, broken binds, surprise downtime, and the trail of “one account that mysteriously stopped working” tickets that follows a rushed migration.