OpenLDAP has served us well for over a decade, and whilst there's absolutely nothing wrong with it, 389 Directory Server has some superior features within our operational environment.  I finally bit the bullet and did the migration - in-place, and in no time flat.  Sure, we've only got about a thousand records in our production LDAP, but it is critical infrastructure.

How did I do it?  Easy.  I used our OpsCode/Chef configuration management system against our BastionLinux/AIM software channel/yum repository.

We use RPM to deploy all of our static configuration - I simply copied our custom LDAP schema extensions, converted these to 389 DS format and cut a 389 DS variant of our existing openldap schema RPM.

We've a quite sophisticated Chef cookbook, a variant of which was used in probably the largest public sector LDAP project in Australia last year.  In addition to accepting arbitrary schema RPM's, configuring setup.ini's, TLS certificates, clustering, monitoring etc, we've defined Chef resource/providers for bespoke indexes and loading LDIF files.

It was quite straightforward to compose a slapd2ds recipe which slapcat's the OpenLDAP database to a file, removes slapd from SysV init, does a couple of Perl munges to change a couple of mismatched objectClasses and remove the surplus entryUUID, entryCSN attributes.  After that, it simply calls the above recipe and 389 DS is set up and auto-loaded with the cleaned up LDIF data...

A couple of test runs had been performed bootstrapping a development KVM image with 389 DS and the production data so I was fairly confident that the recipe was producing the desired outcome.  In the event that it had not, it would have been trivial to fall back by restarting the slapd daemon and slinking back to the test server for some more tweaking.

So we're now getting enterprise strength cn=monitor statistics in Zenoss with our ZenPacks.lbn.LDAPMonitor ZenPack, email delivery and authentication and portal SSO continues to function transparently, and all with just a 30 second production outage.

And now that it's been written, this recipe can be used to migrate any customer's OpenLDAP - albeit that it may take slightly longer for an installation of 2M+ records...