Skip to content
Sunrise Digital Labs

Migration risks

What can go wrong during a Microsoft 365 migration?

Moving mailbox data is usually the easy part. The complexity is everything connected to it: identities, domains, mail routing, permissions, applications, security policies, devices, collaboration workloads, and the transition between environments.

Most migration failures are not caused by the migration tool. They are caused by dependencies that were not found before the migration began.

The migration is more than the data

A mailbox can migrate successfully while the user still cannot work.

Email may be present in the target tenant while Outlook points at the old tenant. A domain may be ready to move while one forgotten group still prevents Microsoft from releasing it. A user may have all of their files while the permissions around those files no longer point to the right identity.

That is why we plan a tenant migration across several connected areas rather than treating it as a data-copy project.

  • Identity

    Users, groups, MFA, Conditional Access, guest accounts, directory synchronization and the source of authority for each identity.

  • Messaging

    Mailboxes, aliases, shared mailboxes, distribution groups, delegates, mail flow, connectors and SMTP relay.

  • Collaboration

    Teams, SharePoint, OneDrive, permissions, sharing relationships, calendars and meetings.

  • Applications

    Enterprise applications, OAuth applications, service accounts, scripts, workflows and systems that authenticate against the tenant.

  • Domains

    Custom domains, MX, SPF, DKIM, DMARC, Autodiscover, routing domains and anything else using the company namespace.

  • Endpoints

    Outlook profiles, OneDrive sync, Teams sign-in, mobile clients, Office activation, Intune enrollment and device compliance.

The migration tool moves part of this. The migration plan has to account for all of it — and what the two migration methods actually move is a separate question with its own answer.

Domain and mail flow

Mail is where a migration becomes visible to everyone at once. These are the failures a whole company notices in the same hour.

The domain will not release

What people see
The cutover window starts, but the company domain cannot be removed from the source tenant. The target tenant cannot use the production addresses until the domain is released.
What caused it
Something in the source tenant still references the domain. It may be a user, alias, shared mailbox, room mailbox, distribution group, Microsoft 365 Group, or another object that did not appear on the obvious user list.
How it is planned for
The domain is scanned for dependencies before the cutover window. Those references are removed or replaced in a controlled sequence, and domain release is treated as a go/no-go condition rather than something to discover during cutover.

Mail starts routing in circles

What people see
Messages are delayed, rejected, or eventually fail because they are being passed between the source and target environments instead of reaching the mailbox that actually owns them.
What caused it
Forwarding, connectors, coexistence routing, or accepted-domain settings disagree about where the recipient lives.A simple example is the source forwarding a user to the target while the target has another rule that sends the same address back toward the source.
How it is planned for
Every migration wave has a defined mailbox location and mail-routing state. A recipient is treated as source or target, and the forwarding and connector configuration has to agree with that state.
Where a message is supposed to landBoth tenants are live during a migration. The message reaches a mailbox when both of them agree which tenant owns the address — and circles when they do not.

When they disagree

The message never lands

Source
Still accepts the address, and forwards it to the target.
Target
Does not consider the mailbox its own yet, and sends it back.

Each side is doing what it was configured to do. Neither one delivers, and the sender sees a delay or a bounce rather than an error anybody can point at.

When the wave defines it

One tenant owns the address

Source
Forwards, and does not keep a copy it will later hand to a migration pass.
Target
Owns the mailbox for this wave, accepts the message and delivers it.

The mailbox has a stated location for this wave, and the forwarding and connector configuration is set to match it. There is no second opinion for a message to bounce off.

Users receive duplicate messages

What people see
A user opens the destination mailbox and finds two copies of the same messages.
What caused it
One common cause is forwarding new mail to the destination while also keeping a copy in the source mailbox. A later migration pass then moves the retained source copy into a destination that already received the forwarded message.
How it is planned for
The coexistence design defines one authoritative mailbox location and makes a deliberate decision about whether source copies are retained. Migration passes and forwarding behavior are designed together rather than independently.

The email gateway still sends mail to the old tenant

What people see
Internal testing looks good, but internet mail is delayed or never reaches the new environment.
What caused it
MX may not point directly to Microsoft 365. The organization may use Proofpoint, Mimecast, Barracuda, Cisco, or another secure email gateway that still has the source tenant configured as its delivery destination.
How it is planned for
Discovery identifies where inbound and outbound mail actually travels. Gateway routes, connectors, TLS settings, allowlists, SPF, DKIM and DMARC are treated as part of mail-flow cutover rather than assuming an MX record tells the whole story.

The ERP, scanner, website, or monitoring system stops sending mail

What people see
Users can send mail, but invoices, alerts, scan-to-email messages, application notifications, or automated reports stop arriving.
What caused it
An application was authenticating to the source tenant, using an Exchange Online connector, relying on an IP allowlist, or sending through an account whose credentials or tenant context changed during the move.
How it is planned for
SMTP relay and application mail are inventoried during discovery. Each sender is assigned a target-state method and tested independently of ordinary user email.

Identity and Exchange

These are the failures where the data arrived and the identity behind it did not. Nothing about them looks like a migration error, which is what makes them hard to see coming.

Old messages cannot be replied to

What people see
The user's new email address works, but replying to an older message or using an old Outlook autocomplete entry produces an NDR.
What caused it
Exchange does not rely only on the visible SMTP address. Historical messages can contain the mailbox's older Exchange identity, commonly represented by LegacyExchangeDN. If that identity is not preserved in the target as an X500 address, Exchange may no longer know where to deliver the reply.
How it is planned for
Legacy Exchange addresses are preserved and mapped to the target recipient so old messages and cached recipient entries continue resolving after the move.

The target mailbox was created too early

What people see
A Microsoft-native cross-tenant mailbox move fails even though the user exists in both tenants.
What caused it
The destination user was licensed early and Exchange provisioned a new mailbox with its own ExchangeGUID. The migration expected the destination object to represent the source mailbox, but the identifiers no longer match.
How it is planned for
The destination objects are prepared in the correct order. Identity mapping and Exchange attributes are validated before Exchange is allowed to provision something that conflicts with the mailbox being moved — why the mapping has to complete first.

Directory synchronization changes the object back

What people see
An administrator fixes an address, attribute, or identity in Microsoft 365 and later finds that the change disappeared or a duplicate object appeared.
What caused it
The object is synchronized from on-premises Active Directory. The cloud tenant is not the source of authority, so Entra Connect or Cloud Sync applies the authoritative value from the directory again.
How it is planned for
The identity source of authority is established before changes begin. In hybrid environments, Exchange and directory attributes are changed at the layer that actually owns them rather than fighting directory synchronization from the cloud.

The CEO moves but the assistant does not

What people see
The mailbox migration succeeds, but delegation stops working. An assistant cannot open the executive mailbox, a manager loses Send As, or a shared calendar stops behaving the way it did before.
What caused it
The users were migrated as independent accounts even though their mailboxes had relationships between them. Delegation, Full Access, Send As, Send on Behalf, folder permissions, and automapping are not the same thing as mailbox content.
How it is planned for
Migration waves are built around business dependencies rather than an alphabetical list of users. Executives and assistants, departments and their shared mailboxes, and other heavily delegated relationships are tested and moved together where practical.

Everyone migrated successfully and nobody can sign in

What people see
The data is in the target tenant, but users are blocked when they try to open Outlook, Teams, OneDrive, or Microsoft 365.
What caused it
The target tenant may require MFA, a compliant device, an approved authentication method, a trusted location, or another Conditional Access requirement the user's current device does not satisfy.
How it is planned for
Authentication and Conditional Access are tested with real pilot users and devices before the production wave. MFA registration, device state, emergency access accounts, and the Day-1 sign-in path are part of cutover testing.

Collaboration and endpoints

The content arrives and the thing around it does not. These are met one user at a time, at their own desk, after everyone has been told the migration went well.

Mail works, but Outlook does not

What people see
The mailbox exists in the target and Outlook on the web works, but the desktop Outlook client continues trying to open the old tenant or asks the user to authenticate repeatedly.
What caused it
The mailbox moved. The local Outlook profile did not.Cached profiles, tokens and OST files can still be associated with the previous tenant and identity.
How it is planned for
Client transition is part of the migration plan. The team decides whether Outlook profiles are recreated, automated, or manually remediated, and accounts for the network load created when large OST files have to synchronize again.

OneDrive files arrive but access does not

What people see
The files are present, but users cannot open something they used to have access to, or an old sharing relationship no longer works.
What caused it
Content and identity are different problems. Source permissions point to source identities. Those identities do not automatically become the same directory objects in the destination tenant.External sharing links can also have their own migration limitations.
How it is planned for
Identity mapping, permissions and external sharing are reviewed separately from file transfer. Validation checks whether the right people can still reach the content, not merely whether the file count matches.

Old Teams meetings still belong to the old tenant

What people see
A user's calendar migrated, but an existing Teams meeting still points at the old tenant or behaves differently from a meeting created after the move.
What caused it
A calendar event and the Teams meeting service behind its join URL are not the same object. Moving the mailbox does not necessarily recreate every service relationship around the meeting — what neither migration method moves covers the wider scope this sits inside.
How it is planned for
Meeting behavior is tested before cutover. Where meetings need to be recreated, the user communication and remediation process is defined before the migration wave instead of being discovered by users afterwards.

A business application stops authenticating

What people see
The Microsoft 365 migration is complete, but a SaaS platform, workflow, script, Power Platform process, or internal application can no longer sign in or reach Microsoft Graph.
What caused it
Applications can depend on the tenant ID, enterprise application object, app registration, service principal, client secret, certificate, API permission, consent, or service account that existed in the source tenant.Those objects do not become target-tenant objects because the user's mailbox moved.
How it is planned for
Enterprise applications, app registrations, service accounts and automations are included in discovery. The plan identifies what must be recreated, reconsented, reconfigured, or retired before the source tenant is decommissioned.

Governance and cutover

The two that are not technical problems at all. They are decisions, and they are expensive when they are made late.

The rollback plan works until new data exists in the target

What people see
A team wants to “just move everything back” after cutover, but users have already received new email, created meetings, edited files, or started working in the target tenant.
What caused it
Before cutover, the source can still be the clear system of record. After production work starts in the target, both sides can contain data that matters.Rollback is no longer only a configuration change. It may become a data-reconciliation problem.
How it is planned for
Every cutover has an explicit go/no-go gate and a stated rollback position. The team knows which steps are reversible, which steps are expensive to reverse, and when the project has crossed the point where recovery means fixing forward rather than simply restoring the previous state.

Why doing this repeatedly matters

A capable internal IT team may run a major tenant migration once every several years.

A migration specialist sees the same classes of problems repeatedly: domain dependencies, identity collisions, routing mistakes, delegate relationships, applications nobody remembered, devices still joined to the old tenant, and workloads that do not move together just because they are sold under the Microsoft 365 name.

The advantage is not access to a secret migration tool. It is knowing what to look for before the production window begins.

That pattern recognition changes the questions asked during discovery, the way pilot users are selected, how migration waves are grouped, where rollback points are placed, and what gets validated before the next wave starts.

The goal is not to react faster when something breaks. It is to find the condition while it can still change the plan.

This is what migration readiness is for

The Migration Readiness Assessment exists to find these conditions before a cutover date is treated as a commitment.

It looks at the estate as it actually exists: identities, licensing, mail flow, domains, devices, applications, integrations, security configuration and the systems that still depend on the source tenant.

The output is not a generic readiness score. It is the information needed to decide:

  • what has to be fixed before migration
  • which users and systems have to move together
  • whether coexistence is required
  • how the domain transition should work
  • which migration method fits the environment
  • what has to be tested in the pilot
  • where the rollback position sits
  • what must remain in the source tenant after the first wave
  • what has to be true before the source tenant can be retired

The failures are predictable. That is what makes them findable.

Every scenario on this page has a condition behind it that existed before the migration started. Finding those conditions is discovery, and it is the work that decides whether a cutover date is a plan or a hope.