Helping someone move from one house to another can either be a smooth process or a stressful one that strains relationships. Similarly, migrating from one Microsoft Active Directory (AD) forest to another can be daunting, especially due to factors such as the complexity or size of the environment, the age of the forest, or specific security and business requirements. However, with the right measures, these challenges can be mitigated to ensure a smoother transition.
Before we dive into those measures, let’s first clarify what an AD migration entails, the complexities you might encounter during a migration, and the differences between intra-forest and inter-forest migrations and when each type is performed.
Basics of Active Directory Domain Services Migration
When considering an AD migration, it’s common to focus on migrating end-user devices. AD migrations require determining what you are going to migrate, and any dependencies they may have. For example, moving the finance department may require moving the accounts payable application that the finance department depends on. Depending on the goal of your migration, there might be objects in a domain or forest that may intentionally not be moved and have dependencies that must be met.
Figure 1 shows a sample of the different objects and services that may be part of an Active Directory infrastructure.
- Intra-forest – moving AD objects between domains within the same forest
- Inter-forest – moving AD objects from one forest to a separate forest
With an intra-forest migration, objects are moved from one domain to another within the same forest. Intra-forest migrations are often done during domain consolidations or restructuring. Intra-forest migrations typically are less complex than inter-forest migrations as the schema is the same and the infrastructure is already in place and typically doesn’t require any major changes.
Figure 2 shows an example of an intra-forest migration where users, computers (end-user devices / servers), and groups can migrate from domain B to either domain A or domain C within forest A. In an intra-forest migration additional trust relationships are not required as all domains are within the same forest.
With an inter-forest migration, objects are migrated from one domain in one forest to another domain in a separate forest. Inter-forest migrations typically are done during mergers, acquisitions, or when organizations need to restructure resources for business or security requirements.
Figure 3 shows an example of an inter-forest migration where resources are migrated from domain C in forest 1 to domain Z in forest 2.
While the steps below can be utilized to help either an intra-forest or an inter-forest migration succeed, the primary focus will be on inter-forest migrations.
Plan to Succeed
A well-planned move from one home to another might utilize labeled boxes and a detailed diagram of the house including room location and furniture placement, making the process much smoother. When it comes to an AD migration, the time spent up front with creating a detailed migration plan can be the difference between success and failure. What are some of the key steps in a migration plan?
- Assess the existing AD environment
- Define the migration scope and order of migration
- Determine the migration strategies
- Identify key stakeholders (e.g., Executives, IT, security, and business operations)
- Build a communication plan
Assess the Existing Active Directory Environment
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
Before you pack a single box, you need to walk through your current home—your source AD environment—and take inventory. This step is critical to avoid surprises during the migration.
Take an inventory of all objects and resources within the source AD environment, which is the AD domain you are migrating from. Review the existing schema, look for any custom schema extensions. Next, review the existing organizational-unit (OU) structure and group policies (GPOs) and clean up any objects that are stale, empty, or no longer required.
You’ll also need to assess the services that the source AD environment provides or relies on. Examples of this are:
- Name resolution
- Public Key Infrastructure (PKI)
- Directory synchronization (Entra ID / Federation / SaaS apps)
- Cloud integration (cloud providers / tenants / requirements)
- Provisioning (users / groups / end-user devices / servers)
- Monitoring
- Configuration management
- Security tooling (SIEM / vulnerability management / IDS / IPS)
- Networking
Collect information on any applications that are integrated with the source AD. Determine how they are integrated, what the scope of the application (enterprise / limited) is, what resources within AD they rely on, what attributes within AD they require, and if there any security or business requirements.
Discover all dependencies, including other systems or services that are dependent downstream, or those that provide data or functionality upstream to any systems or services being migrated. Do these dependencies utilize AD integration to perform the necessary functions? Will they work across a trust? Are there other ways that these dependencies can be met that does not utilize AD integration?
Evaluate each dependency critically. Some can be temporarily disconnected (like moving your mattress before the bed frame), while others (like a washer machine without hoses) will halt progress.
Perform an AD health and security check-up during your initial assessment and throughout the migration process. This will be discussed in more depth later in this article.
Define the Migration Scope and Order of Migration
With that information gathered from the initial assessment, the scope for the migration can now be defined. Begin by clearly identifying what will be included in the migration, and just as importantly, what will not. Document what is / isn’t in scope for the migration and the reasoning behind the decision. During a migration, just like during a move, things can get hectic and you may bring something over you didn’t intend to, or leave something behind that was necessary.
For each object or system in scope, assess whether there are any dependencies that need to be addressed before or during the object migration. Some typical examples of dependencies are identifying what servers are hosting what services and applications, what groups are being utilized to provide access to applications or privileged access, and what end-user device(s) are being used by each individual. Two areas that need to be reviewed carefully for dependencies are applications and tooling/infrastructure.
Applications: What Needs to Work on Day One?
Start with business-critical applications and those used organization-wide. For each ask:
- Will they be accessible from the new forest?
- Does the application support multi-forest authentication?
- Has there been any hard coding of domain information that will need to be addressed.
Work through these and then begin working on the other applications in order of criticality.
Tooling/Infrastructure: Are the Essentials in Place?
Tooling and infrastructure often determine whether a migration is smooth or chaotic. Evaluate if it is necessary prior to migration or can it be migrated or built into the new environment later. Some things to consider:
- Provisioning and Automation
Is automation in place for provisioning, changes, and deprovisioning? Manual processes increase operational risk and workload. - Infrastructure Readiness
Is the environment ready to support patching, configuration management, monitoring, security remediation, and certificate management. These services can be compared to buying a new place and not having the tools in place to handle an incident, or not having keys to locked doors. We don’t want the worst to happen, but we must be prepared for it. - Tooling Compatibility
Do any tools require a separate instance in the new environment? Some tools only support a single domain or forest. Vendor consultation or lab testing may be needed to confirm compatibility.
While it may be tempting to begin migrations prior to all the necessary tooling and infrastructure being 100% ready for the new environment, this results in operational overhead and possible security exposure. It can be compared to moving into your new home without the power or water being turned on. While it can be done, the drawbacks quickly outweigh the benefits.
After understanding the scope and infrastructure requirements, the focus shifts to the objects and systems that will be migrated. While there is no hard and fast rule as to the order of migrations, typically, objects are migrated in the following order:
- Synchronize user and group objects
- Update ACLs and profiles on source objects
- Pilot migration (small, representative group of users and systems)
- Migrate end-user devices
- Reconfigure applications and migrate servers
- Clean-up
Following this order minimizes outages that can result during migration. Performing a pilot migration allows application compatibility, network connectivity, or any other issues to be found and addressed before migrations begin. If during the migration of end-user devices an application issue arises, it is easier to roll back a subset of users than it is to roll back servers and applications.
Special attention should be paid to the list of dependencies when planning the order of migrations. Adding cross-trust communication to an application adds extra steps for authentication and provides one more dependency for the application or service to work. If possible, migrate dependent systems and services together.
Determine the Migration Strategies
Migrations from one forest to another typically involve setting up a trust between the two domains, purchasing a migration tool, and utilizing that tooling to synchronize, update permissions, and migrate the resources from the source forest to the destination environment.
There may be reasons why this isn’t desirable. During the assessment there may be source environments that are insecure, dealing with network address translation (NAT), applications that can’t risk downtime, or other business or security requirements that may require handling the whole or part of the migration strategy differently.
Some questions to ask while determining the best strategy for your migration:
- If you are migrating to the cloud, are there ways to make your applications cloud native?
- Whether in the cloud or on premises, would building a second instance of any application that runs in parallel until cut over be a better option?
- Will my end-user population be AD joined, hybrid joined, or Entra ID joined?
- How much of the workforce will require new hardware during migration and can I use that upgrade in place with the migration?
Identify Key Stakeholders
If the AD migration will impact a significant portion of your user population, securing executive support is crucial. Without top-down leadership, the AD migrations may be delayed as other priorities take precedence, leaving your company caught between the old and new forests. Once you have leadership support, identify other key stakeholders needed for the migration. Examples include:
- Information Technology (IT)
- Identity Access and Management (IAM)
- Security
- Network
- Development
- Project Management
- Business Operations
It is essential that key stakeholders agree on migration strategies, overall goals, and governance before starting the migration. This agreement ensures the necessary support when issues arise or when there is pushback.
Communication Plan
A solid communication plan will be required to keep all teams that are performing, impacted by, or supporting the migration updated on migration progress. In a normal business there are constant changes to employees, equipment, standards, initiatives that can impact an AD migration. Making sure all involved know who or what will be migrated, what the dependencies and possible impacts are, and when the migration is expected to take place will minimize concerns and allow time to adjust if necessary.
Health and Security Checkup
Performing a health and security check-up of your existing AD environment and all systems and applications that are in scope to migrate may seem unnecessary. If you are moving from one house to another, why review the existing house and objects within it? You may find that something you originally planned to move isn’t structurally sound or that it doesn’t fit in with the goals you have for the new house. The same is true when migrating from one AD environment to another. Carrying technical debt from one AD forest to another, especially one that has security risks associated with it, could be compared to bringing a gas stove with a known leak to your new house. Either way that problem needs to be resolved, so why risk the safety of your new home by not fixing the problem? Some key areas for AD security and health checks:
- Authentication Protocols Supported / Used
- Privileged Access
- Operating System (OS) and AD Vulnerabilities
- User Accounts (especially Service Accounts)
- Group Membership (Nested / Privileged)
- Certificate Infrastructure
- Application requirements and configurations
- Group Policies
- Backup and Restoration of AD
- Replication
- Network / Firewalls
Resolving any issues prior to migration will normally be the best solution. It assists with the security, health, or complexity of your source environment and ensures that the risk can be resolved and doesn’t become an issue in your new AD forest. Even if the source environment is to be decommissioned in the end, an AD migration takes time, time that could result in that security or health risk compromising your business.
We have all been someplace where something was modified with the goal of coming back to fix it later, only to have that fix forgotten about until much later. An on-going health and security check of both your source and target environment will ensure that risks are not inadvertently introduced during the migration process.
AD Migration Tools
There are a few tools for migrating AD forests, each with their pros and cons. Choosing the right AD migration tool is like hiring a moving company. You want to know as much as possible about the company before letting them move your valuables. Similarly, it’s crucial to thoroughly review and test migration tools to ensure they meet your needs and security requirements.
Here are some tips to help you evaluate AD migration tools you might be considering:
- Download and review the pre-requisites and installation documentation. Are there any security concerns?
- Install the tool in a controlled environment and connect it to your non-production source and target AD forests. Are there any network or firewall concerns that will be an issue with your production environment?
- Create a list of migration scenarios and test the tool on each scenario. Are there any scenarios that aren’t met? Are you modernizing your AD environment, is the tool capable of your modernization goals?
- Perhaps you are looking at free tools, when was the last time it was updated? Does it support the latest communication protocols, or will you need to weaken your security to use the tool? Sometimes free comes at a higher cost.
Migrations
Each migration is different, just as each move from one location to another is. If possible, create a list of test scenarios and work through each of these in a non-production environment prior to beginning pilot migrations.
Special consideration should be given to the planning and subsequent configuration of the synchronization of users and groups from one domain to another. Verify the correct options and attributes have been selected and tested with a single organizational unit and a single set of objects. Resolve any issues prior to moving forward.
Select a small, representative group of users and systems to make up your pilot migration. Review users, roles, application sets, and locations and create ‘personas’ for each unique group. Utilize users and systems from each of these ‘personas’ to make up your pilot migration. Performing migrations on each ‘persona’ will provide critical information that will drive the timing of production migrations.
Once the infrastructure, system, and application dependencies have been found and mitigated for the ‘persona’ in the pilot migration, that group can then be safely migrated to the new environment. Do this for all end-user devices and users until they are utilizing their new credentials on migrated systems.
Applications should be assessed and a migration plan created for each application. While reviewing each application ask yourself: Is there expertise (talent) and availability (migration window) to migrate the servers and reconfigure the applications including a possible roll back?
If the application is critical, has limited support, or has a small migration window it may be better to build out a second instance in the new environment and cut over to that instance.
Post-Migration Checklist and Validation
To successfully move from one home to another, you need a checklist. This includes reminders to make sure services like utility companies or the post office are notified, or reminders to not forget those objects you saved till the very end are packed in the car with you. The same is true with an AD migration. Having a checklist and using it to validate the status of your migration and the overall health of the AD environments throughout the duration of the migration will ensure a smoother transition to the new AD forest.
Here is an example of some things you may want to put on your post-migration checklist:
Post-Migration Checklist |
|---|
Object(s) migrate over successfully |
Users are using the new domain username / password |
End-User devices were successfully joined (AD / Hybrid / Entra Only) |
Intune and/or group policies working as expected |
Users and computers have received the correct certificates |
Service accounts utilizing the new domain |
Applications and software working as expected |
New or unexpected events in the event log |
Security |
Privileged access working from the new environment |
Security tooling able to monitor and/or manage the migrated objects |
Security agents including but not limited to antivirus, malware, intrusion detection and prevention, vulnerability scanning are working |
Infrastructure / Dependencies |
Successfully communicate with the expected domain controllers, name servers, and other infrastructure systems |
Tooling able to manage, monitor, and/or provision correctly |
Access to applications, systems, or other dependent services working |
Security agents including but not limited to antivirus, malware, intrusion detection and prevention, vulnerability scanning are working |
Conclusion
Just as a successful move requires careful planning and execution, an AD migration demands meticulous planning, thorough assessment, and strategic execution. By understanding the complexities of AD migrations, and by considering the unique challenges a migration brings, organizations can ensure a smoother transition.
Key steps include assessing the existing AD environment, defining the migration scope, determining the best migration strategies, and identifying key stakeholders. Additionally, a solid communication plan and continuous health and security checks are crucial to avoid potential issues. Choosing the right migration tools and validating each step with a comprehensive checklist further ensures the success of the migration.
An AD migration is not something that needs to be feared. Just as moving to a new house is an opportunity to optimize your living space, an AD migration is an opportunity to optimize, consolidate, and secure your AD infrastructure. For many, there will need to be some form of AD for the foreseeable future, use a well-structured AD migration to pave the way for a robust and future-proof infrastructure.
At Ravenswood Technology Group, we specialize in helping organizations plan and execute a secure and strategic AD migration. If you need help with your AD migration, don’t hesitate to reach out to Ravenswood today.
