Active Directory Migration: Why You Need More Than ADMT

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.

Steps to Take Before You Begin an Active Directory Migration

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 Testing and Validation Plan for Your Migration

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 With Your Organization

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.

Want to Make Your AD Migration Easier?

Leverage Automation for a Successful AD migration

Even using ADMT there are a number of tasks that you’ll need to manage. ReadyWorks can help you automate many of them by:

• Connecting to and orchestrating your tools, databases, and systems to pull together a real-time, centralized view of your AD forest.
• Providing you with dependency maps so you can see the type of applications and users and groups and how they all interact within the AD forest.
• Allowing you to identify typical users for testing and leveraging a self-service portal to automate validation activities.
• Cutting the time spent communicating with users and managers by automating communication based on dates and events. You can even use this functionality to cut the time of cleaning outdated information by automating the distribution of mails to your users to identify which users and groups are valid and using the responses to automatically populate your centralized project database.
• Tracking readiness of AD objects for migration
• Allowing you to automate tasks such as adding user IDs to grant access to databases post migration, by creating a script that is triggered once the move is made and orchestrates your tools to make those changes.

Schedule a Demo to find out how ReadyWorks can help you leverage intelligent automation to deliver a successful and pain-free AD migration!