What is Active Directory Migration?

When you set up your Active Directory, you made some important decisions about its structure. Some of them, like what security groups and OUs to have, are fairly easy to change over time as your business requirements evolve, but others — such as what domains you have, the domain names you’re using and what your directory schema looks like — are less easy to modify on the fly because they affect the very foundation of your directory. Instead, you need to carefully plan out your changes and implement them carefully as part of a consolidation or restructuring project.

Over time, organizations can find that their original AD design simply hasn’t worked out well, or that the environment has become disorganized and hard to manage. They might need to move objects from one domain to a different target domain in the same AD forest, or undertake more serious repairs and renovations. Similarly, organic growth of the organization can require an Active Directory restructure or redesign. Major changes to the business, such as a merger, acquisition or divestiture, are also common drivers for an Active Directory consolidation or restructuring.

Completing your Active Directory migration correctly and on schedule is essential for user productivity, business continuity and security — but migrations are notoriously complex and risky projects. The first step is careful planning: You need to know exactly what point A (your current environment) and point B (your desired environment) look like, lay out your procedures for getting there, and test your plan thoroughly to work out any issues or oversights.

Then you need to clean up your current AD as much as possible by right-sizing permissions, purging inactive accounts and so forth. You also need to tease out constraints about scheduling and priorities, and get buy-in from all stakeholders. And you should make sure you have a current backup, rollback capabilities and a recovery plan in case you run into problems during the migration process.

Only then should you even think about running any actual migration jobs. If possible, start with a test environment that mirrors your production environment as closely as possible, and then move on to pilot tests in the production environment. Since migrations take time, be sure you have a coexistence strategy that enables users to remain productive no matter which accounts and resources have been migrated and which have not.