Microsoft Entra ID Tenant-to-Tenant Migration: How to Move Users and Security Groups

Key Takeaways

• Account creation isn’t account readiness. A destination account can exist and still be missing the group membership, license, or relationship that makes it usable.
• Identity matching must be deliberate, not automatic. AvePoint Fly evaluates attribute rules in order and fails a migration rather than guessing when a source object matches more than one destination candidate.
• Security groups need their own verification. Membership type, dynamic rules, role-assignable settings, owners, and members are separate checks, not one pass or fail per group name.
• Guest invitations and guest objects are different milestones. A guest can be migrated without being invited, and a later job can send the invitation without duplicating the object.
• Sign-in activation is a separate decision from account creation. Fly can block sign-in for newly created destination users and unblock specific mapped users once their dependencies are ready.
• Group and license accuracy carries into Microsoft 365 and Copilot. Whatever groups and licenses land on a destination account are what Microsoft 365 apps, and any connected AI agent such as Copilot, use to determine what that person can see.
• Validation means checking the destination, not just the job status. Mapping-level reports confirm what changed, but a completed job and a correctly configured identity are not automatically the same thing.

Creating a destination account is a milestone in a Microsoft 365 migration. It is not the same as making that account ready to use.

The employee may exist in the destination, but they may still be missing a security group membership, a license, or the relationships that connect them to the organization. An existing destination account may be the right match — or belong to someone else with a similar name.

This is where identity migration becomes more than account creation.

AvePoint Fly provides a dedicated Microsoft Entra ID tenant-to-tenant migration workflow for users and non-mail-enabled security groups. It brings source-to-destination matching, supported properties and assignments, and post-migration actions into a defined migration process.

The practical goal is to answer three different questions:

• Have we identified the right destination account? 
• Have we configured the intended access? 
• And is the user ready to sign in?

Here is how to plan those decisions in Fly.

What Belongs in a Microsoft Entra ID Tenant-to-Tenant Migration Project?

“Entra ID migration” can describe several different projects. This article focuses on migrating supported cloud identities between Entra ID tenants.

Within that scope, object types matter. A security group, a Microsoft 365 group, and a distribution list do not all use the same Fly workflow.

For users, the supported scope includes properties such as display name, user principal name (UPN), department, job title, and usage location. Security-group support includes owners, members, membership type, dynamic membership rules, and supported roles. User extension attributes are not supported in this workflow, so identify any dependencies on them during scoping.

Build the inventory around what the destination needs, rather than assuming every source object or assignment should be reproduced unchanged.

How Do You Prepare Entra ID Connections and the Destination Tenant?

Before migration begins, establish secure connections between source and destination tenants; this sets the foundation for a successful Microsoft Entra ID transfer. Fly uses app profiles to connect to the source and destination Entra tenants. You can use the applicable Fly app profiles or custom app profiles with the required permissions for each side.

Connect the tenants in AvePoint Online Services, prepare the app profiles, and create the source and destination Entra ID Users and Groups connections in Fly. Review the permission requirements against the migration functions you intend to use.

Destination preparation should also resolve which identities already exist, which need to be created, which domains will be used for matching, and whether the required Microsoft licenses are available.

Create a Microsoft Entra ID migration project using the prepared connections and a migration policy, then add its mappings.

If you use Auto map, configure Scan Profiles and scan the source objects in AvePoint Online Services first. Select the appropriate source and destination domains when generating mappings. For supported destination objects that are missing, the Auto map workflow presents an alert that you can use to approve creation or return to configure a different destination.

Review that creation decision carefully before allowing it to become the foundation for dependent migration work.

How Do You Match Source Identities to the Right Destination Accounts?

Consider a fictional acquisition involving three employees. The acquiring company has already created some destination accounts, but not all of them.

Fly’s policy can evaluate attribute-matching rules in order. If the first rule does not produce a match, it tries the next. Explicit user mappings take precedence over attribute-based mappings. If a source object matches multiple destination objects under the configured attribute rules, its migration fails rather than selecting a candidate arbitrarily.

That failure is useful information, but it's not the only matching risk. A rule that returns one account can still reflect the wrong business decision. The administrator must confirm that the selected destination identity actually represents the intended person.

For Morgan, rerunning the same ambiguous rule does not settle that question. Review the candidates, confirm the intended destination account, and correct the mapping before proceeding.

Fly supports manually added mappings, Excel imports, and Auto map. Choose the method that fits the project, then review the result. Automation can generate the mapping; it does not replace the decision about where an identity belongs.

What Should Change in Existing Destination Accounts?

A new destination account and an existing one need different consideration.

An existing account may already have a department, group memberships, licenses, and administrative access. Decide which source values should update it and which destination values should remain.

The useful question isn’t “Did we copy the source?” but “Does the destination now reflect the access we approved?”

Groups, Guests, and Assignments — The Relationships That Make an Account Useful

Account creation is easier to evaluate when it is separated from the relationships that make the account useful.

How Do You Verify Security Group Migration Beyond the Group Name?

Fly supports security-group properties, including membership type, dynamic membership rules, the role-assignable setting, owners, and members. Verify each property separately rather than assuming a group is complete just because its name appears in the destination.

Where the associated users already exist in the destination, you can include group membership through the migration policy. Otherwise, run the Migrate group membership post-migration action once the required identities exist in the destination.

For dynamic groups, include a review of the destination rule and resulting membership in the pilot. Migrating a rule is not the same as confirming that the right people have the right access.

How Do You Plan Guest User Invitations During Migration?

Fly supports guest-user migration and provides an Invite guest user option, with configurable invitation content and a redirect URL. If a guest was migrated previously without an invitation, a later job with invitations enabled can send the invitation to the existing destination account without duplicating it. Use that distinction to plan communication deliberately.

Treat guest creation and invitations as related steps in one process, rather than as as interchangeable milestones.

What Should You check Before Migrating Roles, Licenses, and Application Assignments?

Fly can migrate supported directory-role assignments and assign Microsoft licenses based on the source user’s assignments. The corresponding licenses must exist and have available capacity in the destination. This is destination license assignment, not a transfer of the source tenant’s purchased licenses.

Role support has qualifications. For example, the user support list excludes built-in role start and end times and lists Directory, Group, and User as the supported custom-role types. Check the specific roles you need rather than assuming every privileged-access configuration will be reproduced.

The policy also includes enterprise-application single sign-on (SSO) assignments. Keep that capability scoped to assignments: Application configuration and sign-in validation need their own place in the plan.

Fly also offers an option to assign custom security attributes to destination users based on the source user’s assignments. Custom security attributes are distinct from the extension attributes excluded earlier. Before using this option, confirm the destination attribute definitions and required permissions; do not assume that assignment migration also recreates those definitions.

How Do You Pilot an Entra ID Tenant-to-Tenant Migration?

Once the project’s connections, policy, and mappings are configured, review its scope before execution.

On the project’s mappings page, Pre-migration → Verify mapping checks whether the source and destination objects in the mappings are available for migration. It is an optional step in Fly, but one recommended before a production run. It does not replace the business-identity review or an access test.

A useful pilot should exercise different decisions: a newly created user, an existing destination user, a guest, and a security group with relevant relationships. Include a supported role or application assignment when those are part of the production scope. This is a suggested test set, not a required Fly template.

For the initial execution, use Migration → Full migration. The full job can migrate properties, group memberships, supported roles, and license assignments according to the configured options.

The following are migration complexity tiers for Entra ID objects:

Afterward, complete the applicable post-migration work:

• Managers and sponsors. These are not included in the full migration job. Run Migrate object managers to migrate those relationships.
• Group membership. Run the separate membership action when it was deferred or needs to be completed after destination identities are ready.
• Microsoft licenses. Use Assign Microsoft license where needed, and resolve destination availability or capacity issues reported by the job.
• Sign-in activation. Use Unblock user sign-in for the mapped users whose activation is approved for that stage of the migration.

Post-migration jobs can run independently of the full migration. Review the objects selected for each action; do not assume the full-migration policy’s selections will govern the post-migration jobs. Identity matching still matters: The membership post-migration action uses the attribute-mapping rules defined in the policy.

How Do You Separate Account Preparation From First Sign-In?

AvePoint Fly can block sign-in for destination users it creates, then unblock mapped users through a post-migration action. That lets account preparation and activation be separate decisions. It does not make unblocking an account equivalent to delivering credentials or completing every access requirement.

Coordinate activation with the content-migration team rather than making “unblock everybody at the very end” a universal rule. For example, Fly’s Teams membership support notes state that a source member cannot be migrated when the corresponding destination user is blocked from signing in.

The practical sequence therefore depends on the workload and migration wave. Know when each destination identity must exist, when dependent memberships can be migrated, and when the employee should begin using the destination.

Communications should explain which account to use, when to switch, how destination credentials will be provided, and where to get help. That is part of the migration plan, not an announcement to improvise after the jobs finish.

How Do You Validate an Entra ID Migration Beyond Job Status?

Fly provides mapping-level history and reports covering property updates, user metadata, role assignments, memberships, and licenses. Property reports can show old and new values, while exceptions and comments help identify what needs attention. That distinction between reporting and validation matters. In AvePoint's State of AI Report 2026, 62% of organizations that reported the highest confidence in preventing unauthorized data access still experienced at least one AI-related unauthorized-access incident, demonstrating that confidence alone is not proof that controls are working as intended.

Use that evidence to investigate specific problems. If a destination object is missing, review its mapping and provisioning configuration. An unavailable license calls for checking the destination’s license type and remaining capacity. Rerunning a job without addressing its cause is not a resolution.

For the pilot, combine report review with a destination check. In the fictional acquisition example, you would then need to confirm that Alex maps to the intended account, Dana’s new account has the expected properties, Morgan’s ambiguity is resolved, and the selected groups and assignments match the approved design. Check manager and sponsor relationships after their post-migration job.

When activation is appropriate, test the user’s destination sign-in and access to the resources included in the pilot. These are recommended acceptance checks — not a claim that Fly automatically tests the entire employee experience.

Export the final reports and retain the mappings as part of the project handoff.

Give Your Microsoft 365 Migration an Identity Foundation It Can Trust

Destination identities and user mappings support dependent content elements such as Teams and Microsoft 365 group memberships, file attribution, task assignments, and permissions. Those dependencies are why the identity project belongs in the broader Microsoft 365 migration plan.

Carry the approved mapping decisions into the relevant content projects and validate them there. Do not assume that completing an Entra job automatically configures every mailbox, collaboration, or device migration that follows.

The goal is more useful than “all users created.” It is that the right destination accounts exist, their supported properties and assignments reflect the approved plan, and the team knows what must happen before each person begins working in the destination.

That is the role of Entra ID migration in AvePoint Fly: to prepare the identities, make access decisions explicit, and give the rest of the migration a foundation it can use.

Planning an Entra ID tenant-to-tenant migration? Request an AvePoint demo to discuss your user, group, and access requirements.

Frequently Asked Questions

What's the difference between migrating a user and migrating a security group in Entra ID tenant-to-tenant migration?

A user migration creates or matches one destination identity and its supported properties, such as display name, UPN, department, job title, and usage location. A security-group migration instead carries over membership type, dynamic membership rules, the role-assignable setting, owners, and members, and depends on each member already existing and being matched in the destination. Both follow the same attribute-matching policy, but a group's completeness depends on its members' identities being ready first.

Does Entra ID tenant-to-tenant migration include mail flow, shared mailboxes, or distribution lists?

No. Entra ID migration in AvePoint Fly covers Microsoft 365 users, guest users, and non-mail-enabled security groups only. Distribution lists, shared mailboxes, and mail-enabled security groups move through the separate Exchange Online migration workflow, and Teams or Microsoft 365 Groups move through the Microsoft Teams or Microsoft 365 Groups migration workflow instead.

How much downtime should organizations expect during an Entra ID tenant-to-tenant migration?

AvePoint Fly's Entra ID workflow is built around staged account preparation rather than a single cutover window. Fly can block sign-in for newly created destination users and then unblock specific mapped users once their dependencies are ready, which lets a migration proceed in waves instead of taking every identity offline at once. The practical length of any downtime depends on the workload sequencing a project chooses, not a fixed duration set by the tool.

Does the same Entra ID migration process apply to a company rebrand or divestiture, not just an acquisition?

Yes. The identity-matching, mapping, and validation process described in this guide applies regardless of why the destination tenant exists, whether that's an acquisition, a divestiture, or a rebrand to a new domain and tenant. What changes between scenarios is the scope of what's in or out of the migration project, not the underlying Fly workflow.

What does Entra ID migration mean for Microsoft 365 workloads like Teams and SharePoint after the identities move?

Destination identities and their mappings are the foundation that Teams and Microsoft 365 Group memberships, file attribution, task assignments, and permissions depend on. Completing an Entra ID migration job does not automatically configure those content workloads; the approved mapping decisions need to carry into each content migration project and be validated there separately.

How does Entra ID migration affect what Microsoft Copilot or other AI agents can access after a tenant move?

Microsoft Copilot and other AI agents connected to Microsoft 365 read from the permissions and group memberships already in place for a signed-in identity. If a destination account's group membership, license, or role assignment is incomplete after migration, that gap carries directly into what the AI agent can or can't see on that person's behalf. Validating group and license accuracy during migration is therefore also a data-access-governance step, not only an identity-readiness one.

If a migration runs in multiple waves over several weeks, how often should the project's mappings be rechecked?

Review mappings before each wave's execution, not only once at the start of the project. Fly's Pre-migration → Verify mapping check confirms source and destination objects in the mappings are available for migration, and it is worth running before every production run rather than only the first one, since destination conditions such as new licenses or newly created accounts can change between waves.

What happens to Teams and Microsoft 365 group memberships if the destination user account is still blocked from sign-in?

A blocked destination account can still be matched and hold properties, but Fly's Teams membership support notes state that a source member cannot be migrated into a team when the corresponding destination user is blocked from signing in. That makes sign-in activation a prerequisite for completing certain membership migrations, not an independent, later-stage decision. Sequence the unblock action before the dependent membership migration runs.

What is SID history, and does it apply to an Entra ID tenant-to-tenant migration?

SID history is an Active Directory concept that preserves a user's old security identifiers so they keep access to resources that still check against the previous domain. It does not apply to Entra ID tenant-to-tenant migration, which uses cloud-native attribute matching and explicit mappings instead of SID-based resource access. Organizations migrating an on-premises Active Directory domain alongside their Entra ID tenant should plan SID history separately.