Before we have this conversation, I want to give you some bad news. Your passwords aren’t going to migrate. The good news is that you only do directory services migrations every decade or two. The better news is that I’m not actually sure you need a directory service in the traditional sense that you’ve built directory services. With Apple’s Enterprise Connect and Nomad, we no longer need to bind in order to get Kerberos functionality. With MCX long-dead(ish) you’re now better off doing policies through configuration profiles.
So where does that leave us? There are some options.
- On Prem Active Directory. I can setup Active Directory in about 10 minutes. And I can be binding Mac clients to it. They’ll get their Kerberos TGTs and authenticate into services and the 90s will be as alive on your server as they are in Portland. Here’s the thing, and I kinda’ hate to say it, but no one ever got fired for doing things the old reliable way.
- OpenLDAP. There are some easy builds of OpenLDAP to deploy. You can build a new instance from scratch on a Mac (probably a bad idea) or on a very small Linux box. This is pretty easy, but to get all the cool stuff working, you might need some tweaking.
- Appliances. I’m already working on an article for installing OpenLDAP on a Synology.
- Microsoft Azure Active Directory. If you’re a primarily Microsoft shop, and one that is trying to go server-less, then this is probably for you. Problem is, I can’t guide you through binding a client to Active Directory in Azure just yet.
- Okta/Ping/other IAMs. Some of these can act as a directory service of sorts ( https://help.okta.com/en/prod/Content/Topics/Directory/About_Universal_Directory.htm ). As with Azure, you’re likely not going to bind to them (although Nomad has some interesting stuff if you feel like digging into that).
- A hosted directory service provider (Directory as a Service) like Jumpcloud.
There are probably dozens of other options as well (please feel free to add them in the comments section of this article). No matter what you do, if you have more than a dozen or two users and groups, you’re going to want to export them. So let’s check out what that process looks like. The easy way to export data is to dump all of the services out with one quick command:
sudo slapconfig -backupdb ~/Desktop/slapexport/
This process produces the exact same results as exporting Open Directory from the Server App. To do so, open the Server app and click on the Open Directory entry. From there, click on the cog-wheel icon and choose the option to Archive Open Directory Master.
When prompted, enter your directory administrator (e.g. diradmin) credentials.
Once you have authenticated, provide a path and a password to export the data.
Now you’ll see a sparse image in your export path. Open it to see the backup.ldif file. 
That’s the main thing you’re looking for. The ldif file can be imported into another openldap system, or once you have an ldif file, you can also get that over into csv. To help with this, I wrote a little ldif to csv converter and posted it here.
Finally, you could export just users or groups, or specific objects from the Server App. 
That option is more built for importing into other macOS servers, but if you’d like to try, click on Users in the left sidebar and then click on Export Users from the cog wheel icon towards the bottom of the screen. 
Then select what to export and where to export the file to. 
You can also repeat this process for Groups, if needed.
