Why Can’t Users Open Files After a Tenant-to-Tenant Migration?

A Microsoft 365 migration is only complete when an employee can sign in, open their files, and use their applications in the destination environment. That depends on the destination identity being correctly matched, group memberships and licenses being in place, Windows and mobile devices being rejoined, and migrated content being correctly attributed to the right person.

Those workloads are central to a merger, divestiture, tenant consolidation, or modernization project. But getting the content to the destination is not the same as getting people ready to work there.

Key Takeaways

• Content migration has always been an identity problem too. Files can arrive in the destination tenant while the employee’s account, group membership, device, or phone are still misconfigured, and the employee experiences all of that as one unfinished migration, not separate projects. 
• Active Directory (AD) migration moves the directory objects behind the business. In AvePoint Fly, AD-to-AD workflow handles users, groups, contacts, and organizational units (OUs) for local or hybrid AD, with deliberate attribute matching rather than a one-to-one copy. 
• Entra ID migration prepares the identities a Microsoft 365 migration depends on. It covers users and non-mail-enabled security groups between Entra ID tenants, plus the group membership, license, and sign-in decisions that make an account usable. 
• Windows device migration gets the user, not just the data, to the destination. Fly can rejoin devices and translate access control lists (Re-ACL) for profiles, file systems, printers, and local groups across supported AD, Entra ID, and hybrid configurations. 
• Mobile device migration shouldn’t stop the project at the laptop. Fly’s Intune mobile device management (MDM) workflow maps devices, retires source management, and guides users through destination enrollment for supported iOS, iPadOS, and Android devices. 
• Microsoft 365 workloads depend on identity being right first. Destination identities and mappings underpin mailbox ownership, OneDrive ownership, Teams and Microsoft 365 Group membership, and file attribution across the content that migrates. 
• AI tools like Copilot inherit whatever the identity and device migration gets right. Because Copilot and other connected AI agents read from the permissions and group memberships already in place for a signed-in identity, an incomplete identity migration becomes an incomplete AI-governance picture too. 

Why Doesn't Content Migration Alone Deliver a Successful Migration?

Before user-dependent content and permissions can map correctly, the right destination identities (users) need to be in place. A user’s mailbox needs the right destination account. A OneDrive needs an owner. Teams and Microsoft 365 Groups have members and owners. Files carry attribution such as Created By and Modified By. Preserving those relationships depends on connecting the source identity to the correct person in the destination.

That dependency has long been part of AvePoint Fly’s migration planning. It is also a major reason we have invested in expanding what Fly can migrate: dedicated capabilities for Active Directory (AD), Microsoft Entra ID, Windows devices, and Intune-managed mobile devices (iOS and Android), alongside its Microsoft 365 and Google Workspace content workflows.

This is an extension of the migration problem we already help customers solve. A successful migration is not measured only by how many terabytes moved. It is also measured by whether people can get back to work.

Why Is Content Migration Also an Identity Problem?

Consider a tenant-to-tenant migration following an acquisition. An employee might have a mailbox, OneDrive, Teams memberships, SharePoint permissions, a Windows laptop, and an iPhone enrolled in Microsoft Intune.

The emails and documents could arrive in the destination while important parts of the employee’s transition remain unfinished. Their destination account might be matched incorrectly or missing a group membership. Their laptop might still belong to the old directory. Outlook, OneDrive, or Teams might still point at the source environment. Their phone might remain managed by the source tenant.

Those are different technical problems, but the employee does not experience them as separate projects. They do not think, “My content migration succeeded, but my device transition is incomplete.” They think, “I can’t work.”

That is why identity, content, and devices need to be considered together. Not every migration requires every workstream, and they do not all have to happen in one rigid sequence. Content can be staged, users can move in waves, and devices can transition on a coordinated schedule. The important point is to understand the dependencies before the first production wave begins.

That is why identity, content, and devices need to be considered together. Not every migration requires every workstream, and they do not all have to happen in one rigid sequence. Content can be staged, users can move in waves, and devices can transition on a coordinated schedule. The important point is to understand the dependencies before the first production wave begins.

How Does Active Directory Migration Move the Directory Objects Behind the Business? 

For organizations consolidating or restructuring traditional AD environments, AvePoint Fly provides a dedicated AD-to-AD migration workflow, whether it’s pure local AD or hybrid connected to Entra ID using Entra ID Connect for users, groups, contacts, and organizational units (OUs).

The process goes beyond copying an account. Administrators configure source and destination agents, define where objects belong, and decide how existing destination objects should be handled.

Fly can try attribute-matching rules in order and create a destination object when no match is found. Explicit user mappings take precedence, and multiple matches must be resolved rather than guessed. That makes identity matching a deliberate part of the migration plan.

Full and incremental migrations support staged execution. After source objects change, administrators rescan the source before running an incremental migration. Post-migration actions address user password synchronization, managers, group membership, and OU changes.

In an acquisition, those decisions help determine how the acquired organization fits into the destination directory. In a divestiture, they help define which objects belong in the separated environment. Moving the objects is only part of the job. The target directory has to make sense when you get there.

How Does Entra ID Migration Prepare the Identities Your Microsoft 365 Migration Depends On? 

Cloud-to-cloud migrations create a similar challenge. A source account does not automatically become the right destination account simply because both belong to the same person.

AvePoint Fly’s Microsoft Entra ID migration workflow supports users and non-mail-enabled security groups between Entra ID tenants. Administrators can match existing destination identities or create supported destination objects, migrate selected properties and supported assignments, and complete post-migration actions for group membership, managers and sponsors, licenses, and sign-in activation.

This gives identity preparation a defined place in the migration program. It also makes it easier to distinguish account creation from the decisions that make an account usable: which groups it belongs to, which licenses are available, and when the employee should begin signing in.

The connection to content is practical. Once the destination identities are established, carry the source-to-destination mapping decisions into the relevant content projects and validate them there. An identity migration job prepares part of the foundation; it does not replace the configuration and validation of each content workload.

How Does Windows Device Migration Get the User, Not Just the Data, to the Destination? 

Identity migration solves one piece of the transition. The next question is often sitting on the employee’s desk: What happens to the laptop?

Even when the destination identity and cloud content are ready, the migration team still needs to address device join state, Windows profiles, local permissions, application configuration, restarts, and first sign-in.

AvePoint Fly’s Device Migration workflow supports Windows 10 and Windows 11, with supported Windows Server versions limited to AD-to-AD (local or hybrid) migration paths. Available paths and prerequisites depend on the source, destination, operating system, and tenant environment.

Across supported AD, Entra ID, and hybrid identity configurations, Fly can rejoin devices and translate access control lists — known as Re-ACL — for supported areas. These include Windows profiles, file systems, printers, specified registry locations, services, local groups, and user rights.

The workflow also includes options to reconfigure Microsoft applications such as Outlook, OneDrive, and Teams after the device moves. Retaining access to the existing Windows profile and connecting applications to the destination are related tasks, but they are not the same task.

A device transition still includes a restart and destination sign-in. Depending on the configuration, users may need to respond to prompts, provide credentials, and complete multifactor authentication (MFA).

The goal is not to pretend those requirements disappear. It is to automate supported migration tasks around them and give IT a repeatable process to configure, monitor, and validate.

Why Does Mobile Device Migration Matter Beyond the Laptop?

The workplace extends beyond Windows. A phone or tablet may be how an employee reads email, joins Teams meetings, and accesses business applications during the day. Those devices need their own plan when Intune management changes tenants.

AvePoint Fly’s Mobile Device Migration capability is generally available, with a Microsoft Intune mobile device management (MDM) workflow for supported iOS, iPadOS, and Android devices. This is MDM migration, not mobile application management (MAM). Scope the project to supported enrollment scenarios and prepare the destination management environment before retiring source management.

The workflow is different from a Windows transition. In Fly’s mobile process, users participate in destination enrollment and client-side authentication. Administrators map devices and existing destination owners, send retirement notifications, retire source management, and redirect users through Company Portal to initiate destination enrollment.

Fly tracks progress through Mapped, Notified of retirement, Retired, Notified to redirect, and Enrolled. After enrollment, supported post-migration actions can assign devices to destination administrative units and security groups based on source memberships, provided the corresponding destination objects can be found, and the source membership information is available.

A device being retired from the source is not the same as a successful migration. Retired is not migrated. Enrollment is a milestone; the migration team should also verify destination management, compliance, and access to the business resources the employee needs.

What Does One Migration Look Like From a Single Employee's Perspective? 

Imagine a fictional employee named Alex whose company has just been acquired. Alex needs the right destination identity, with the appropriate groups, licenses, and relationships. Alex’s mailbox, OneDrive, Teams memberships, and other migrated content need to map to that identity.

The Windows laptop may need to move to a different directory while retaining access to the existing profile and relevant local resources. Outlook, OneDrive, and Teams need to connect to the destination. Alex’s Intune-managed phone, within the supported migration scope, needs to leave source management and complete destination enrollment.

From an architecture perspective, those are separate workstreams. From Alex’s perspective, they are one migration. That is the thinking behind our investment in Fly: address more of the connected tasks that determine whether the employee can work after the move.

How Do You Move Beyond a Workload-by-Workload View of Migration? 

There will always be reasons to plan by specialty. Exchange administrators need mailbox details. Identity teams need directory detail. Endpoint teams need device and enrollment details.

Migration leaders need a view across those boundaries. These four Fly workflows address different parts of that plan:

Migration Readiness Tiers for an Employee's Full Transition 

Use the workflows your project requires alongside the relevant content migrations. Having them in Fly does not turn the entire program into one automatic job. It lets the migration plan include more of the work around the same people, with explicit mappings, prerequisites, and validation for each workstream.

Plan Your Migration Around the Destination Experience, Not Just the Data

One of the most useful questions to ask early in a migration is: What has to be true for a user to work successfully in the destination?

The answer may include a correctly prepared identity, appropriate memberships and permissions, migrated content, a usable Windows profile, reconnected applications, and an enrolled mobile device.

Those dependencies should not be discovered at the end of the project. They should shape the plan from the beginning.

That is what moving beyond content means for AvePoint Fly: planning around identities, data, and the devices people actually use — not just the objects that need to be copied.

Planning a migration? Request an AvePoint demo to discuss your identity, content, and device requirements.

Frequently Asked Questions

What are the biggest risks to plan for in a Microsoft 365 tenant migration?

The biggest risk is treating identity, content, and device migration as independent projects instead of connected dependencies. A destination account that’s mismatched or missing a group membership, a laptop still joined to the old directory, or a phone still under source management can each leave an otherwise successful content migration unusable for the employee affected.

How much downtime should I expect when identity, content, and device migration all happen together?

AvePoint Fly does not require a single all-at-once downtime window across identity, content, and device migration. Content can be staged, users can move in waves, and devices can transition on a coordinated schedule, so the practical downtime for any one employee depends on how a project sequences these workstreams, not a duration fixed by the tooling.

What’s the difference between Active Directory migration and Entra ID migration?

Active Directory (AD) migration moves on-premises or hybrid directory objects, users, groups, contacts, and organizational units, between AD domains. Entra ID migration moves cloud identities, users and non-mail-enabled security groups, between Entra ID tenants instead. A hybrid environment connected through Entra ID Connect may need both workflows, each covered in its own companion guide.

Does every migration need all four Fly workflows: Active Directory, Entra ID, device, and mobile?

No. Not every migration requires every workstream, and they don’t all have to follow a rigid sequence. A pure cloud-to-cloud tenant consolidation may require only Entra ID and content migration, while an acquisition that absorbs an on-premises environment may need AD, Entra ID, device, and mobile migration together.

What does identity and device migration mean for Microsoft 365 workloads like Teams and SharePoint during a migration?

Destination identities and their mappings are the foundation on which Teams and Microsoft 365 Group memberships, file attribution, task assignments, and permissions depend. A content migration that completes successfully can still leave those workloads misconfigured for a given employee if the identity behind them wasn’t matched and validated first.

How does incomplete identity or device migration affect Microsoft Copilot and other AI agents?

Microsoft Copilot and other connected AI agents read permissions and group memberships already in place for a signed-in identity, not from the content migration status. If an employee’s destination account is missing a group membership or still signing in from the wrong device context, that gap carries directly into what the AI agent can or can’t see on that person’s behalf.

How often should migration teams validate dependencies across identity, content, and devices during a staged migration?

Validate dependencies before each production wave, not only once at the start of the project. Because content can be staged and devices can transition on a coordinated schedule, the set of identities, content, and devices that need to be checked together changes with every wave rather than being fixed at kickoff.

What is Re-ACL, and why does it matter during a Windows device migration?

Re-ACL is Fly’s translation of access control lists, so a rejoined Windows device recognizes the destination identity for its existing profile, file systems, printers, registry locations, services, local groups, and user rights. Without it, a device can technically rejoin the destination directory while still denying the employee access to their own local resources.

Which services can consolidate several Microsoft 365 tenants into one while moving Teams, SharePoint, and OneDrive together?

Tenant consolidation requires the content migration workflows for Teams, SharePoint, and OneDrive to run alongside the identity migration that determines who owns and can access that content afterward. AvePoint Fly covers both halves: the Microsoft 365 and Google Workspace content workflows referenced throughout this guide, and the Entra ID identity workflow covered in the companion guide to Entra ID tenant-to-tenant migration.

Related Questions

→  How do you prepare Microsoft 365 data and permissions before a Copilot rollout?