Active Directory Domain Migration: A Practical Plan for Users, Groups, Contacts, and OUs

Key Takeaways

• Selecting an OU isn’t the same as selecting a scope. A department’s users, groups, contacts, and managers don’t necessarily sit in the same organizational unit, so discovery has to follow relationships outside the first branch selected.  
• Default containers need a separate check. Objects in default containers, such as Computer, System, Builtin, and Users, have different migration eligibility, so not everything beneath a selected branch is eligible to migrate.  
• Matching must be deliberate, not just attribute-driven. AvePoint Fly evaluates each attribute in sequence, creating a destination object only when no match is found. If multiple potential matches appear, the migration stops for review instead of making an automatic assumption.
• Group membership and manager relationships have prerequisites. Each member or manager must already exist in the destination and be included in the discovery process for the relationship to migrate correctly.
• Password and SID-history decisions belong in the plan, not after the fact. Newly created destination users are unavailable after migration unless password sync is configured, and SID history needs its own scan, agent, and policy setup.  
• A domain migration connects directly to the wider Microsoft 365 and hybrid identity plan. Destination identities and mappings underpin user-dependent content elements such as memberships, task assignments, file attribution, and permissions in any connected Microsoft 365 or hybrid Entra ID environment.  
• AI and Copilot access inherits whatever the directory migration gets right or wrong. Group membership and manager relationships carried over from Active Directory often feed the same permissions that Microsoft 365 apps and connected AI agents use downstream, so an incomplete migration can misconfigure what those tools can see too. 

An Active Directory (AD) domain migration is not simply an exercise in recreating the same number of accounts in a different directory. You need to decide where objects belong, which existing accounts they should match, and which relationships must work after the move.

Consider a fictional acquisition.  In this example, the engineering team’s users are stored in one organizational unit (OU), their access groups in another, and supplier contacts in a third. Some employees already have destination accounts, which adds another layer of complexity. The team’s manager, meanwhile, sits outside the branch originally chosen for discovery, illustrating why migration planning must capture relationships that extend beyond a single OU.

Selecting the engineering OU is a starting point. It is not the complete migration scope.

AvePoint Fly streamlines Active Directory domain migrations — whether your environment is a standalone domain or part of a hybrid setup connected to Microsoft Entra ID. 

Instead of recreating accounts by count, Fly helps organizations migrate users, groups, contacts, and organizational units with deliberation, ensuring relationships, permissions, and dependencies are mapped correctly across domains.  

This guide walks through every phase of a successful migration, from discovery and directory design to pilot testing, incremental transitions, and final validation.

What Should You Define Before Building Active Directory Migration Mappings?

Start with what the destination directory should look like, not just what exists in the source.

Decide which objects belong in the migration, where they should land, and whether they should be created or matched to existing destination objects. Fly supports mapping users, groups, and contacts into existing or newly created destination OUs.

Validate default containers separately before migration. AvePoint Fly excludes built‑in directories such as Computer and System from Active Directory migration. In Built‑in and Users containers, manually created objects can migrate, while preconfigured system objects cannot. Review your directory branch to confirm which objects are eligible — this step avoids surprises during execution and keeps the migration plan compliant.

This plan focuses on directory objects. Windows device transitions, Microsoft Entra ID identities, and Microsoft 365 content belong in their respective migration workstreams, which AvePoint Fly can support.

How Do You Prepare AD Connections, Agents, and Permissions?

Fly uses source and destination Active Directory agents. Create the corresponding Active Directory Users and Groups connections, generate the connection keys, and configure each agent for its role. Prepare the required certificates, service accounts, and network access before the pilot.

Next, plan the deployment by domain. Each connection is limited to one domain; for a multidomain forest, the migration process recommends multiple agents connecting to the relevant domains. It also recommends installing agents on non-domain-controller machines that can reach the appropriate AD environment. Although installation on domain controllers is technically supported, it is by no means required. Agents can work on any machine that can communicate with the domain controller.

Review the agent-host requirements separately from the supported Active Directory versions. Confirm connectivity to AvePoint Online Services, Fly, and the relevant directories, along with the lightweight directory access protocol LDAP), lightweight directory access protocol secure (LDAPS), and remote procedure call (RPC) requirements applicable to the selected functions.

The destination attribute configuration is another decision to make early. By default, connecting the destination creates an attribute named flymigrationExtensionAttribute. The documented default configuration requires a destination service account with both domain-admin and schema-admin permissions. The documented custom-attribute option requires domain-admin permissions instead. Review that choice with the directory owner before deployment.

These are prerequisites to validate rather than details to discover after a production job has started.

How Do You Make AD Matching and OU Placement Deliberate?

An AD migration policy determines how Fly matches objects, handles conflicts, and configures options such as password synchronization and group membership.

Attribute-matching rules are evaluated in order. If the first rule cannot match an object, Fly tries the next. If none produces a match, Fly creates a destination object. Explicit user mappings override attribute-based mappings, while multiple destination matches cause the source object's migration to fail.

Review the rules against the actual directories. A source account should not become a second destination account simply because the chosen matching attribute differs. Conversely, one matching result is not proof that the account belongs to the intended person.

Fly also saves the globally unique identifier (GUID) after migrating an object and uses that saved identifier in subsequent jobs when source attributes change.  That feature helps ensure consistent matches in later migrations, but it’s still important to manually review the initial results for accuracy.

For conflicts, the AD policy offers Skip, which ignores the conflicting object, and Overwrite, which overwrites its attributes based on the source. Choose the behavior that fits the approved destination design rather than applying it without reviewing existing objects.

Once the connections and policy are ready, create an Active Directory project. Add mappings from scanned objects using tree or search mode, or import project mappings with the Excel template. The template identifies source users and groups by sAMAccountName and contacts by cn, alongside the source OU, destination OU, and object type.

Review destination naming as well as placement. If you specify a destination object in a mapping, Fly uses it to generate the destination user's User Principal Name (UPN), overriding the policy's automated UPN format. That is worth checking before the pilot, especially when the migration includes renamed accounts.

How Do You Find AD Relationships Outside the First OU You Select?

The fictional engineering team illustrates a practical scoping issue: A department's users, groups, contacts, and managers do not necessarily sit together.

For group membership migration, the member must exist in the destination, the member's OU must have been scanned by Fly, and the member must be matched through the configured rules. A successfully created group does not, by itself, establish that its membership is complete.

Manager relationships have a similar prerequisite. To migrate the manager of a user, group, or contact, the manager must have been scanned into Fly and must exist in the destination. Include those dependencies in discovery even when they fall outside the department's initial scan boundary.

For a carve-out, that review also helps identify relationships that should change rather than be recreated. Record the intended destination relationship and have the relevant owner approve it.

How Do You Validate Migrated AD Contacts?

Contacts should be explicit entries in the scope and acceptance plan, not something to investigate only after the employee accounts have moved.

Fly's contact support includes attributes such as display name, email, company, department, and phone information. Review the exact attributes needed by the destination and any dependent applications. Some Exchange-related contact attributes are supported only when creating a new destination object, so creating a contact and updating an existing one are not equivalent cases.

For the engineering example, include a supplier contact in the pilot. Check its destination OU, the required business attributes, and any in-scope group or manager relationship. Where an application relies on the contact, have its owner validate that dependency.

Treat contact validation as part of collaboration readiness. In an Active Directory migration, confirming address‑book visibility and mail flow ensures communication continuity. Use dedicated checks for each system rather than relying on a contact’s presence in the directory as proof both features work.

How Do You Decide Password- and SID-History Requirements Before the First Run?

Password handling depends on how the destination user is created.

For users created by Fly during migration, the Sync user passwords policy option supports synchronizing passwords. If that option is not selected, Fly's AD migration policy documentation states that the newly created destination users will be unavailable after migration. For existing destination users not created by Fly, use the Sync user passwords post-migration job. Make credential readiness part of the pilot rather than equating a newly created account with a usable sign-in.

SID history requires its own preparation. If it is part of the approved access plan, complete the documented SID-history preparation, configure the source scan and destination agent, and enable the corresponding migration-policy option. Password and SID-history scanning require RPC availability.

Do not treat selecting the SID-history checkbox as proof that every resource-access dependency has been addressed. Define the relevant access tests with the application and infrastructure owners.

Password and access history settings should be formalized in your overall domain migration plan, even if identity or security specialists handle implementation. This alignment keeps technical readiness and compliance integrated across every migration stage. 

How to Run a Pilot That Tests the Dependencies?

I would choose a small pilot for variety, not just convenience. A collection of uncomplicated new users will not test the decisions involved in matching existing accounts or completing relationships.

For the fictional engineering migration, the pilot could include:

The following are migration complexity tiers for Active Directory objects: 

This is a suggested test set, not a built-in Fly template.

Review the scanned objects, project mappings, and policy before execution. For the first run of the selected mappings, use Migration → Full migration. Make sure an AD agent is active for the destination connection.

Inspect the result before increasing the scope. Use the pilot to resolve mismatches, missing dependencies, and unexpected attribute behavior — not simply to establish that a job can finish.

How Do You Handle Rescans, Incremental Migration, and Deletions?

A staged migration needs a process for changes between waves.

After completing the initial migration, AvePoint Fly supports incremental runs for newly added or updated directory objects, and for any with prior errors or warnings, to keep destination data synchronized as environments evolve. When source objects are changed, rescan them on the source agent before running the incremental migration.

For example, suppose the engineering team's department value changes after the pilot. Refresh the source scan, run the relevant incremental job, and verify the destination value against the configured conflict behavior.

An OU move or a relationship change may also require an applicable post-migration action. Review new objects against the project's scope and mappings rather than assuming that everything discovered belongs in the current wave.

How Do You Complete the Post-Migration Work and Validate the Destination?

Fly provides four AD post-migration actions: 

1. Sync user passwords.
2. Migrate object managers.
3. Migrate group membership.
4. Sync objects OU changes. 

Use the applicable actions for the selected mappings and approved migration stage.

Membership can be included through the AD migration policy, but its prerequisites still apply. When completing it through a post-migration job, confirm the required members are available and mapped. Likewise, check manager availability before running the manager job.

Treat Sync objects OU changes as a deliberate choice when the source OU structure changes. If the destination has been designed differently, review the intended placement rather than automatically assuming the latest source arrangement is the desired outcome.

For validation, Fly's mapping history shows the actions performed. Property reports can show attribute names with old and new values; membership reporting identifies successful and failed members. Migration and error reports can be viewed within the product or exported in CSV or Excel format.

Use those reports alongside checks in the destination. Confirm that the engineering accounts landed in the intended OUs, existing users were matched correctly, group memberships are complete, contacts retain the required attributes, and managers resolve to the intended destination objects.

Where appropriate, include sign-in and application-access checks agreed with the relevant owners. These are recommended acceptance tests, not a claim that Fly automatically validates every business dependency.

Export the final reports and archive the mappings before closing the directory workstream. Once the migration is complete and the agents are no longer required, follow the documented agent-removal process.

How to Connect the Directory Plan to the Wider Migration?

Finishing the directory migration does not automatically complete a Windows device transition, move Microsoft 365 content, or prepare every cloud identity. Those workstreams need their own configuration and validation. Fly can support your device and content migrations, all within one migration product.

Where they form part of the same project, carry the approved identity decisions into the wider plan. Destination identities and mappings underpin user-dependent content elements such as memberships, task assignments, file attribution, and permissions. That preparation matters beyond the directory itself. AvePoint’s 2026 State of AI research found that nearly nine in 10 organizations delayed AI initiatives by an average of almost six months due to unresolved data security and data management concerns. Establishing accurate identities, permissions, and relationships during directory migration helps create the governance foundation that broader modernization and AI initiatives depend on.
 
The domain migration should therefore leave more than a count of copied objects. It should leave a directory with intentional placement, verified matches, the required relationships, and a record of what was checked.

That is the practical goal: not just objects in a new domain, but a destination directory ready for the next part of the migration.

Planning an AD domain migration? Request an AvePoint demo to discuss your Active Directory migration requirements.

Frequently Asked Questions

What's the difference between migrating an Active Directory user and migrating a security or distribution group? 

A user migration creates or matches one destination account based on attributes, such as sAMAccountName, with Fly saving a GUID after migration to support later matching. A group migration instead depends on its members already existing in the destination and having been scanned by Fly, so a group can be created successfully in the destination while its membership is still incomplete. Both object types follow the same attribute-matching policy, but a group's completeness is a separate check from the group object itself. 

How long does an Active Directory domain migration usually take? 

AvePoint Fly does not set a fixed timeline for an AD domain migration; duration depends on the number of migration waves, how many agents a multidomain forest requires, and how much incremental and rescan work a project's change cadence generates. The practical approach is a pilot that exercises different matching and relationship scenarios before scaling to production waves, rather than planning around one fixed cutover date. 

What does Active Directory domain migration mean for Microsoft 365 and connected cloud identities? 

Destination identities and mappings from an Active Directory migration underpin user-dependent content elements such as memberships, task assignments, file attribution, and permissions in any connected Microsoft 365 or hybrid Entra ID environment. Finishing the directory migration does not automatically complete a Windows device transition, move Microsoft 365 content, or prepare every cloud identity; those workstreams need their own configuration and validation. 

How does Active Directory migration affect what Microsoft Copilot or other AI agents can access after the move?

Group membership and manager relationships carried over from Active Directory often feed the same permissions that Microsoft 365 applications and connected AI agents, including Copilot, use downstream in a hybrid environment. An incomplete group membership or an unresolved manager relationship in the directory migration can therefore misconfigure what those tools can see for a given person, not just what the person can access directly. 

How often should matching rules and OU placement decisions be reviewed as a migration moves from pilot to production? 

Review matching rules and OU placement before each production wave, not only once at project setup. Conditions change between waves: New destination objects get created, source attributes change, and conflict behavior, whether Skip or Overwrite, still needs to fit the approved destination design as more of the directory migrates. 

What's the difference between the Skip and Overwrite conflict-handling options in an AD migration policy? 

Skip ignores the conflicting object and leaves the existing destination object unchanged. Overwrite replaces the destination object's attributes based on the source. Choose the behavior that fits the approved destination design for each wave rather than applying one setting without reviewing what already exists at the destination.

Does Active Directory domain migration also cover Windows device migration or Microsoft 365 content?

No. This workflow covers directory objects: users, security and distribution groups, contacts, and organizational units. Windows device transitions, Microsoft Entra ID identities, and Microsoft 365 content each belong to their own migration workstream, which AvePoint Fly can also support.

Does this Active Directory domain migration process work for a hybrid environment connected to Microsoft Entra ID? 

Yes. AvePoint Fly's AD-to-AD migration workflow supports local-only Active Directory as well as a hybrid setup where Active Directory is connected to Entra ID. This guide covers the directory-object migration itself; migrating the connected cloud identities between Entra ID tenants is a separate workflow, covered in AvePoint's companion guide to Entra ID tenant-to-tenant migration. 

What is SID history, and when is it required in an Active Directory migration? 

SID history preserves a user's prior security identifiers so they keep access to resources that still check against the previous domain after migration. It requires its own preparation: the documented SID-history scan, a destination agent configured for it, and the corresponding migration-policy option enabled. Both password and SID-history scanning require RPC availability. It does not apply to Entra ID tenant-to-tenant migration, which uses cloud-native attribute matching instead, as covered in AvePoint's companion guide to Entra ID migration.

Related Questions

→  Why can't users open files after a tenant-to-tenant migration?
→  How does Entra ID differ from Azure AD and on-premises Active Directory?
→  How do you protect Entra ID identities after migration?
→  When should you choose a SaaS-based migration tool?
→  How can security teams speed up approval for a migration platform?