ADMT will get you some of the way in your AD migration, but remember how your environment has grown over time – you are likely to have thousands of AD objects with different sets of attributes and dependencies. And if you’ve been through a number of mergers and acquisitions, it’s likely you’ve inherited a structure that you aren’t that familiar with. There are some things ADMT won’t do.
To mitigate issues, before you can even think about migrating all your users, workstations, servers, and service accounts you need to do some legwork. You’ll want to understand all your AD object dependencies and which objects are now invalid. If you want to maintain access permissions after your move, read on to find out some of the pitfalls to avoid and ensure a successful AD migration.
- Map your Forest: If you have more than one domain – the top tier structure is called a ‘forest’. Within each domain there are multiple organizational units (OUs) – or files/folders. Those OUs could have been structured in a number of ways. Ask yourself:
- Do you know how your AD forest is structured? If you didn’t set it up, then it’s unlikely you’ll know everything.
- Do you know where the domain controllers are located – for the forest and each of the domains?
- What structure do you want to have in the new domain? Do you want to flatten and simplify it?
You’re going to have to collate all of the information on your AD environment before you can design your structure in the new domain. Completed manually that means collecting and cleaning data from multiple tools, systems and databases on a spreadsheet.
- Have a Spring Clean (whatever the season): ADMT is a ‘lift and shift’ tool which means if you have old information pre-migration, you are just going to move it to clutter up your new domain. It’s a good idea to clean up ahead of your move. To do this, you may want to send out emails to end users and managers to confirm which groups and users are no longer active and delete them.
- Get to know your applications:
- The applications and programs that teams use, generally depend on AD for security permission – i.e., who has access to them. When applications depend on AD for security management you need to make sure that you know what those permissions are – or you could find that users don’t have access post migration.
- Some applications use service accounts, such as SQL server, which uses service accounts and AD groups to grant access to databases. These applications aren’t aware of the changes being made outside of it so, for example, if changes are made to AD, SQL can’t see those changes. You’ll need to manually add user IDs post migration to reestablish access permissions.
- Some applications have their own internal ecosystem that links in with AD – cloud applications such as OKTA require some manual changes to maintain access during a migration.
You’ll need to understand all of these intricacies and that means analyzing your source data to understand the type of applications you are using and how they interact with AD.
- Define a test plan: ADMT doesn’t provide any testing facilities so you’re going to have to define a testing and validation plan for your migration. Consider:
- Creating fictitious users based on typical attributes – for example by business function - and migrate that user before you conduct the real-life migration of the team, making sure all access permissions remain post migration. You may find it helpful to identify and work with typical users within your organization rather than creating test accounts.
- Putting together a post-migration validation plan by identifying key users from different groups and working with them to understand all access permissions are retained post-migration.
- Communicate: Make sure your entire organization knows what’s happening and why. Create a list of FAQs and let them know the timeline for the migration and who they should contact if they have any issues.
By following these tips, you can shield your users and help to maintain the integrity of all your objects during the move. But done manually, there are still challenges. It’s going to take time to collate your data, communicate with employees to understand what’s outdated and to answer any questions. And that’s not accounting for the possibility of human error – post migration you could still be correcting issues and answering calls from users that can’t access their applications.