Migrating a Microsoft 365 Entra Tenant to a New Domain

When a company is acquired, merged with another organisation, or separated from a parent company, one of the most technically challenging tasks facing the IT team is the migration of identity infrastructure. In most Microsoft-based environments, Active Directory (AD) forms the foundation of authentication and access control. It governs how users log in to computers, how devices join the network, how permissions are granted to file systems, and how identities synchronise with cloud platforms such as Microsoft 365.

Because of this central role, moving an Active Directory environment is not simply a matter of copying data. It requires careful planning, staged migrations, and a deep understanding of how identity, applications, and cloud services interact. When a company sale occurs, the goal is typically to separate the acquired or divested business unit from the original IT infrastructure and rebuild it under a new organisational structure.

In most modern environments, Active Directory is closely integrated with Microsoft Entra ID, which synchronises identities to the cloud and enables services such as Exchange Online, Microsoft Teams, SharePoint, and OneDrive. As a result, an AD domain migration usually involves a wider programme of work that includes tenant separation, mailbox migrations, Teams data migration, and device reconfiguration.

This article provides a practical and detailed guide to migrating an Active Directory domain after a company sale. It focuses on best practices used by enterprise IT teams and consultants when moving users, computers, and services from one domain to another while maintaining access to Microsoft 365 services and minimising disruption to staff.

Understanding the Typical Migration Scenario

When organisations go through mergers, acquisitions, or divestitures, identity environments rarely align perfectly. Most companies have built their IT infrastructure over many years, often combining on-premises Active Directory with cloud services such as Microsoft 365. Because of this, a company sale almost always leads to a need for identity restructuring.

There are several common scenarios in which an Active Directory migration becomes necessary. One of the most frequent is a divestiture, where a business unit is sold to another company. In this case, the newly independent organisation must separate its users, devices, and data from the original parent company’s IT environment. The new company may wish to establish its own identity platform, cloud tenant, and security policies.

Another common situation occurs during a full acquisition, where a smaller organisation is absorbed into a larger enterprise environment. In these cases, the acquiring company typically migrates the acquired organisation’s identities into its existing domain and Microsoft 365 tenant.

A third scenario involves tenant separation, where organisations need to move users from one Microsoft 365 tenant to another. This may happen when companies restructure or when divisions are sold off to new owners.

In most real-world environments, the starting architecture looks something like this:

Source environment:

• Active Directory domain (for example oldcorp.local)

• Microsoft 365 tenant (oldcorp.com)

• Entra ID synchronisation using Azure AD Connect

Target environment:

• New Active Directory domain (newcorp.local)

• New Microsoft 365 tenant (newcorp.com)

• New Entra ID tenant for identity synchronisation

The objective of the migration project is to move users, devices, and data from the source environment into the target environment without significantly disrupting business operations.

This process must be handled carefully because authentication services affect nearly every aspect of the organisation’s IT infrastructure. If identity systems fail during migration, users may lose access to their computers, email systems, file shares, and business applications.

Core Migration Principles and Best Practices

Successful identity migrations depend less on individual technical tools and more on following proven design principles. Organisations that attempt rushed migrations without a clear strategy often encounter authentication failures, permission issues, and extended downtime.

One of the most important principles is avoiding direct movement of domain controllers between organisations. Domain controllers are deeply integrated with the security structure of their original domain. Attempting to move them into a new organisation’s environment can introduce security vulnerabilities and configuration conflicts. Instead, the recommended approach is to build a fresh Active Directory environment and migrate identities into it.

Another important principle is maintaining identity continuity for end users. Ideally, staff should experience minimal change during the migration. This means preserving email addresses, usernames, and if possible passwords. When users are forced to change credentials unexpectedly, helpdesk requests tend to increase dramatically.

Separating identity migration from data migration is also considered best practice. Moving Active Directory accounts, migrating mailboxes, and transferring Teams data are all complex operations. Treating them as separate workstreams allows each stage to be tested and validated before moving on to the next.

Staged migration strategies are also critical. Rather than moving the entire organisation in one step, migrations should occur in batches. This allows the IT team to test processes, identify problems, and refine procedures before scaling up.

Finally, temporary domain trusts can provide a smooth transition between environments. Trust relationships allow users in the new domain to access resources in the old domain while the migration process is underway.

Preparing the Source Active Directory Environment

Before any migration begins, the existing environment must be carefully analysed and cleaned. Many organisations underestimate the importance of this stage, but it is often one of the most valuable parts of the project.

Over time, Active Directory environments accumulate large numbers of unused accounts, outdated computer objects, and legacy security groups. Migrating these objects into a new environment simply recreates the same problems in the new domain.

A thorough audit of the source environment should therefore be conducted. Administrators should identify disabled user accounts, dormant service accounts, and computer objects that have not been active for several months. These can usually be removed from the migration scope.

Group structures should also be reviewed carefully. Many organisations accumulate hundreds of security groups that are no longer required. Cleaning these up before migration reduces complexity and simplifies permission management in the new environment.

Another important part of preparation involves documenting application dependencies. Many enterprise applications rely on Active Directory authentication. These may include internal websites, databases, VPN gateways, or line-of-business systems.

Understanding these dependencies ensures that applications continue functioning once users are moved to the new domain.

Designing the Target Active Directory Environment

Once the existing environment has been analysed, the next step is designing the new domain structure. Rather than copying the old environment exactly, organisations should take this opportunity to build a cleaner and more modern identity platform.

The naming strategy for the new domain is an important decision. In many cases, organisations choose an internal domain name that is separate from their public internet domain. For example, the internal Active Directory domain might be corp.newcompany.local, while the public domain used for email and websites is newcompany.com.

Separating these namespaces helps avoid certificate and authentication conflicts.

Domain controller deployment must also be carefully planned. At least two domain controllers should be deployed to ensure redundancy. If the environment is hosted in a virtualised infrastructure or cloud platform, the controllers should be placed on separate hosts or availability zones.

This ensures that authentication services remain available even if a server fails.

The design of Group Policy should also be revisited during the migration process. Many organisations accumulate large numbers of policies over time, some of which may conflict with one another. Instead of copying every policy from the original environment, administrators should review them carefully and recreate only those that are still relevant.

Modern management technologies such as Microsoft Intune and device compliance policies may replace many legacy Group Policy settings.

Establishing a Trust Between the Domains

During the migration period, it is often beneficial to establish a temporary trust relationship between the source and target domains. A domain trust allows authentication requests to pass between environments and enables migration tools to translate permissions correctly.

The most common configuration used in migration projects is a two-way trust. This allows both domains to recognise each other’s users and resources. With this trust in place, users who have already been migrated to the new domain can still access resources located in the old domain.

Trust relationships also allow migration tools to preserve security identifier (SID) history, which plays a crucial role in maintaining access to existing file systems and applications.

Once the migration process is complete and all resources have been transferred to the new environment, the trust relationship can be removed.

Migrating Users, Groups, and Computer Accounts

One of the most widely used tools for Active Directory migrations is the Active Directory Migration Tool (ADMT). This Microsoft tool has been used for many years to support domain consolidation and separation projects.

ADMT can migrate users, groups, and computers from one domain to another while preserving important security information. It also supports password migration when configured with the appropriate components.

The migration process typically begins with group migration. Security groups are migrated first because they define the permission structure used throughout the organisation. Once groups exist in the target domain, users can be migrated and added to those groups.

User migration involves copying account information such as usernames, display names, group memberships, and profile attributes into the new domain. When SID history is preserved, the new user accounts can continue accessing resources that rely on the original domain’s permissions.

Testing is critical during this stage. Small batches of users should be migrated first to verify that login processes work correctly and that permissions behave as expected.

Preserving User Passwords

Password migration is one of the most sensitive parts of an Active Directory migration project. If passwords cannot be transferred successfully, every user must reset their credentials when they first log in to the new domain.

While this is technically possible, it often creates significant disruption and increases the workload for support teams.

To avoid this problem, organisations typically use a Password Export Server (PES) installed on the source domain controller. This service works with ADMT to securely transfer password hashes into the new domain.

The process involves generating an encryption key that protects password data during migration. When configured correctly, users can continue using their existing passwords without noticing any change.

Migrating Workstations and Servers

After users have been migrated successfully, their computers must also be moved into the new domain. This process can be automated using migration tools or scripted processes.

When a workstation is migrated, the computer object is first created in the new domain. The device then reboots and joins the new domain environment. During this process, administrators must ensure that the user’s existing profile is preserved.

Without proper profile migration, users may lose access to their desktop files, application settings, and cached credentials. Tools such as User Profile Wizard or enterprise migration platforms can transfer user profiles from the old domain to the new one.

Servers require additional care because they often host critical services such as databases, application platforms, and file storage.

Domain Controller Strategy

In most migration scenarios, domain controllers themselves are not moved between environments. Instead, new domain controllers are deployed in the target domain, and services are gradually transferred.

This approach reduces security risk and ensures the new environment starts with a clean configuration. Once all identities and systems have been migrated, the original domain controllers can be safely decommissioned.

Attempting to reuse domain controllers across organisational boundaries can create trust issues, lingering configuration data, and security concerns.

Integrating the New Domain with Microsoft Entra ID

Modern identity environments typically integrate on-premises Active Directory with cloud services through Microsoft Entra ID. This integration allows users to authenticate to Microsoft 365 services using the same credentials they use on their computers.

To enable this integration, organisations deploy Entra Connect Sync (previously Azure AD Connect). This synchronisation service copies user accounts, groups, and attributes from Active Directory into the Entra ID tenant.

Several authentication models are available. The most widely used model is Password Hash Synchronisation, which securely replicates password hashes to the cloud. This allows users to authenticate directly with Microsoft 365 services even if the on-premises infrastructure is temporarily unavailable.

Other models include Pass-Through Authentication and federated authentication using ADFS, although many organisations now prefer the simplicity of password hash synchronisation.

Preparing the Microsoft 365 Environment

Before mailboxes and collaboration data can be migrated, the target Microsoft 365 tenant must be prepared. This includes creating user accounts, assigning licences, and verifying domain ownership.

Each user in the new tenant must have a corresponding identity that matches the account being migrated from the original environment. Proper mapping between source and target accounts is essential for ensuring mailboxes and Teams data are transferred correctly.

Licensing must also be configured before migration begins. Users require appropriate Microsoft 365 licences to host mailboxes and access Teams or SharePoint services.

Migrating Exchange Online Mailboxes

Email is one of the most visible services in any organisation, so mailbox migration must be handled carefully. Cross-tenant migrations typically occur in stages to minimise downtime.

Migration tools perform an initial pre-stage sync, which copies most mailbox data into the target tenant while users continue working in the source environment. When the final cutover occurs, only recent changes need to be synchronised.

Once mailbox migration is complete, DNS records such as MX and Autodiscover are updated to direct incoming mail to the new tenant.

Migrating Microsoft Teams Data

Microsoft Teams environments consist of several interconnected services, including SharePoint document libraries, Exchange mailboxes, and OneDrive storage. Because of this architecture, migrating Teams data is more complex than migrating email.

Specialised migration tools are often required to move Teams channels, conversation history, and associated files between tenants. The process usually involves recreating the Teams structure in the new tenant before copying data.

Users should be informed that some historical chat data may not migrate perfectly, depending on the capabilities of the migration tool used.

Migrating SharePoint and OneDrive Content

SharePoint and OneDrive migrations often occur alongside Teams migrations because these platforms share the same underlying storage architecture.

Administrators should begin by identifying all active SharePoint sites and their owners. Document libraries can then be migrated using specialised tools that preserve file versions and permissions where possible.

OneDrive migrations involve transferring personal file storage for each user. Careful mapping of user accounts ensures that files appear in the correct locations once the migration is complete.

Handling Service Accounts and Applications

Service accounts require careful planning during migration projects. These accounts often run automated processes such as backups, monitoring systems, or scheduled scripts.

Rather than migrating these accounts directly, it is usually safer to recreate them in the new domain and update application credentials accordingly. This approach ensures that legacy security configurations are not carried into the new environment.

Applications that depend on Active Directory authentication should also be tested carefully after migration.

Security and Compliance Considerations

Identity migrations create temporary security risks because administrators often require elevated permissions in both environments. Proper security monitoring should therefore be implemented during the project.

Multi-factor authentication should be enforced for administrative accounts, and access logs should be reviewed regularly. Temporary migration accounts should be removed once the project is complete.

Conditional access policies can also help ensure that users authenticate securely during the transition.

Communication and User Preparation

Technical planning alone does not guarantee a successful migration. Users must be informed about upcoming changes and given clear instructions on what to expect.

Communication plans should include migration schedules, login instructions, and information about any changes to email access or Teams functionality. Providing clear guidance reduces confusion and prevents unnecessary support calls.

Many organisations also provide temporary support teams during migration weekends to assist users with login issues.

Running a Pilot Migration

Before migrating the entire organisation, a pilot group should be selected. This group should include technically confident users who can provide feedback on the migration experience.

Pilot migrations allow administrators to test identity synchronisation, email access, and Teams functionality in a controlled environment. Any issues discovered during the pilot can be corrected before the full migration begins.

Final Cutover and Migration Weekend

Most organisations schedule the final migration during a weekend or other low-activity period. During this time, mailbox synchronisation is completed, DNS records are updated, and users are transitioned to the new environment.

Extensive testing should occur before the start of the next business day to ensure that email, Teams, and authentication services function correctly.

Decommissioning the Legacy Environment

Once the migration is complete and users have successfully transitioned to the new environment, the legacy domain can be decommissioned. This involves removing domain trusts, shutting down old domain controllers, and disabling synchronisation services.

Old systems should remain archived for a short period in case historical data needs to be retrieved.

Conclusion

Moving an Active Directory domain following a company sale is a complex project that affects nearly every aspect of an organisation’s IT infrastructure. However, by following structured migration practices, organisations can transition smoothly to a new identity environment.

The most successful projects focus on careful planning, staged migrations, and thorough testing. By separating identity migration from data migration and maintaining clear communication with users, IT teams can minimise disruption while modernising their infrastructure.

Ultimately, domain migration projects also present an opportunity to improve security, adopt modern identity technologies, and build a cleaner, more scalable environment for the future.