Why Identity, MFA, Devices, and Apps Decide Migration Success 

Every Microsoft 365 tenant to tenant migration has four workstreams that decide whether Day 1 is calm or chaos: 

• Identity 
• Security & access 
• Device re-enrollment 
• Applications 

If you treat these as side tasks, you can complete the move and still inherit a crisis. 

Because Day 1 is what the client remembers. The morning after cutover, leadership is watching, users are trying to work, and your helpdesk queue spikes with: 

• People who can’t sign in 
• Teams access and ownership problems 
• OneDrive and Outlook issues on laptops 
• Business apps that suddenly stop working 

That’s where MSP time and margin disappear. Not because the move failed, but because the trust layer underneath Microsoft 365 wasn’t rebuilt in sync. 

Run these four workstreams in parallel, validate them wave-by-wave, and cutover becomes controlled. Miss one, and the MSP absorbs the chaos. 

1. Identity Mapping: Where Small Mistakes Become Big Outages 

Before you move a single workload, you’re really doing one job: 

Make sure the person in the source tenant becomes the exact same/right person in the target tenant, every time. 

In real projects, mapping is rarely clean: 

• UPNs change mid-project 

• SMTP domains shift 

• Users don’t exist yet in the target tenant 

• The target tenant isn’t fully built, and attributes don’t line up the way the plan assumes 

And when those details drift, the business doesn’t see “identity mismatch.” They just see “things randomly broke.” 

When identity mapping slips, the breakage spreads fast: 

• Mail routing issues appear 

• Teams membership and ownership don’t resolve 

• SharePoint permissions break 

• Delegated access disappears  

Here’s the uncomfortable truth: Microsoft’s migration engines move data, not identities. 

So, if you haven’t created and aligned identities in the target tenant first, you’re copying content into an environment where the “people layer” doesn’t match. 

How you keep identity from ruining cutover 

• Maintain one authoritative mapping file (users, groups, shared/resource mailboxes). Version it. Protect it. Don’t let it drift. 

• Validate mapping before every wave, not just once at kickoff. 

• Surface edge cases early, guest users, service accounts, consolidations, and assign ownership. These are the items that wreck cutover weekends. 

2. Conditional Access & MFA: Day 1 Login Failures And Modern Auth Blockers

Once identity is stable, the next dependency hits immediately:

Can those identities sign in safely, and can your migration tooling authenticate reliably with modern auth and EWS?

Conditional Access and multi factor authentication are where migrations feel calm right up until they are not. At the same time, modern authentication, EWS and MFA alignment for migration accounts and tools has become the number one blocker for tenant to tenant projects.

At cutover you typically see two sets of problems:

• Users cannot sign in, with lockouts and repeated MFA prompts
• Migration tools fail modern auth checks, with 401 or “you must use multi factor authentication” errors

Conditional Access policies and MFA registrations are tenant bound. They do not move with the user. User‑side state like MFA methods, trusted sessions and auth tokens must be rebuilt in the new tenant.

Modern authentication is also required for Microsoft 365 and Exchange Online now. Basic auth is deprecated, so EWS access for migration must use OAuth with correctly scoped app registrations and consent.

If you do not align Conditional Access, MFA and modern auth:

• Users are forced to re‑register MFA under pressure
• Devices fail compliance checks in the target tenant
• Migration jobs stall because service accounts cannot pass silent modern auth and EWS validation

What a clean MSP plan looks like

Successful teams treat Conditional Access, MFA and modern auth as one design track:

• Capture current policies, then rebuild them to match the agreed security baseline in the new tenant.
• Pilot sign‑in flows, MFA prompts and device compliance with a small group before broad rollout.
• Plan MFA registration using staged rollout or Temporary Access Pass to reduce helpdesk impact.

For migration tooling they also:

• Use dedicated migration accounts and apply Office365 turn-off MFA only to these accounts, never tenant wide.
• Exclude migration accounts from MFA enforcement policies while constraining them with IP ranges and strong governance.
• Register apps in Entra ID with the right EWS permissions, consent and modern auth configuration before large‑scale migrations.

The goal is simple: Make Day 1 sign‑in boring and make modern auth/EWS checks equally boring. When users can log in under the right policies and migration tools authenticate cleanly, Conditional Access and MFA stop being the primary source of migration delays.

3. Microsoft Intune & Devices: The Day 1 Device Management Challenge 

Once sign-in is stable, users stop complaining about access and start complaining about something more personal: 

Their device doesn’t behave like it did yesterday. 

Because Intune doesn’t “transfer” devices across tenants. A device enrolled in one tenant must be unenrolled and re-enrolled into the new tenant. That’s not a tooling preference; it’s how tenant boundaries work. 

Re-enrollment creates user-visible fallout that everyone blames on the migration: 

• Entra ID registration needs to be re-established 

• Office may prompt reactivation 

• OneDrive sync relationships break 

• Outlook profiles need resets (often) 

Even if you didn’t rebuild the machine, the experience can feel like you did. And if you don’t have a runbook, you’ll spend cutover week remote-controlling endpoints. 

Autopilot adds another layer. Registrations are tenant scoped and moving them can involve export/remove/import plus waiting for deletions to propagate. That in-between window, when devices are partially managed or unmanaged, is exactly when confusion and risk spike. 

What reduces endpoint pain more than any script 

This is less about scripting and more about execution discipline: 

• Treat device work as a user experience program, not a background task. 

• Build runbooks for real scenarios (corporate laptops, shared devices, kiosks, mobile, not just the happy path). 

• Pilot early, then move in staged waves with clear user comms. 

Once devices are functioning, there’s one failure mode left that can quietly wreck the project: 

“Everything looks fine, except our apps.” 

4. Applications: App Registrations Are the Silent Cutover Killer 

A migration is “successful” until the client’s business apps stop working. 

In Microsoft 365 environments, this often comes down to one root cause: app registrations, consent, and secrets/certs are tenant-scoped, none of it migrates. 

So if an app is using SSO (Single Sign-On) against the source tenant, or a custom integration is calling Microsoft Graph with client credentials, it must be rebuilt and reconfigured to trust the target tenant. 

When this gets missed, it hits hard, often outside business hours (the classic 10 PM “SSO is down” call): 

•  breaks for HR, CRM, and ITSM 

• Automations stop running 

• Background services throw auth errors with little warning 

And now you’re troubleshooting “the app,” even though the real issue is the trust boundary changed. 

Rebuilding isn’t just recreating an object. It usually means: 

• new client IDs and service principals 

• new secrets/certs 

• updating references across code/config, Key Vault, and CI/CD pipelines 

That’s why “we’ll fix apps later” almost never works. Apps don’t wait. They fail the moment the trust boundary changes. 

How you avoid the “apps are down” call 

• Inventory app registrations early: purpose, permissions, where credentials live, and who owns it. 

• Rebuild in a controlled way, with validation and rollback per critical system. 

• Align app cutovers to migration waves, not as post-cutover cleanup. 

Now the four pillars finally connect.

To make these risks easier to manage in practice, MSPs need supporting controls around migration accounts, EWS authentication, OWA MFA timing and governance, so security exceptions stay controlled instead of becoming Day 1 blockers.

Designing Migration Accounts Around MFA And Conditional Access

Migration accounts should be designed as secure exceptions, not as permanent bypasses. You need a clear pattern to have Office365 turn-off MFA on those accounts during non‑interactive migration, while keeping the tenant compliant.

Principles for secure migration accounts

Build migration accounts with these principles:

• Dedicated service accounts used only for migration and automation
• Scoped admin roles for Exchange, SharePoint or Teams, not broad global admin whenever possible
• Conditional Access policies tuned specifically for migration, with limited IP ranges and time windows

Steps to temporarily allow non‑interactive auth

The practical steps to allow non‑interactive modern auth while keeping risk bounded are:

• Disable per‑user MFA on the dedicated migration accounts in the Microsoft 365 admin center.
• Exclude those accounts from Conditional Access policies enforcing MFA, device compliance or location‑based restrictions.
• Confirm the accounts can sign in to the admin center without MFA prompts, then restrict sign‑ins via IP ranges and strong passwords.

If you cannot turn off MFA on migration accounts for policy reasons, you should use Azure app registrations with certificate‑based authentication to bypass user‑based MFA entirely.

EWS Multi-Factor Authentication Patterns For Tenant Migrations

Many migration tools still rely on EWS for mailbox migration, public folders and coexistence. To keep EWS multi-factor authentication compatible with non‑interactive migration, you must shift from user‑based auth to application‑based auth.

App registration and EWS permissions

The standard pattern uses a registered app in Microsoft Entra ID with EWS permissions:

• Create an app registration in the source and target tenants for Exchange Online.
• Assign delegated EWS permissions such as EWS.AccessAsUser.All where needed.
• Assign application permissions such as full_access_as_app to allow service‑principal access to mailboxes in scope.

Admin consent is required before the migration tool can use these permissions. Administrators must grant consent and ensure the app has the right scopes for the project.

You then configure your migration tool with:

• Client ID and Tenant ID from the app registration
• Client secret or certificate for authentication
• A management scope or security group that defines which mailboxes the app can access

Keeping EWS aligned with MFA and security controls

EWS application permissions do not use user‑based MFA. Instead, they rely on app credentials that can be managed, rotated and monitored. This is usually the best way to keep MFA enforcement for regular accounts while avoiding Office365 turn-off MFA requirements for migration.

To keep this secure you should:

• Limit EWS application permissions using management scopes so that only in‑scope mailboxes are accessible.
• Store client secrets or certificates in secure locations such as Key Vault, with rotation policies.
• Use audit logs and service principal authorization tests to confirm which mailboxes are in scope.

This pattern lets you work within Microsoft’s modern auth model and avoid risky patterns like app passwords or legacy basic auth for migration accounts.

OWA MFA, User Experience And Migration Timing

OWA MFA and user‑facing MFA prompts are often where migration projects feel painful to users. Even if backend auth and EWS scopes are configured correctly, poor timing on MFA changes can create perceived outages.

How OWA MFA changes interact with tenant migration

MFA enforcement and user access to Outlook on the web, Teams, SharePoint and OneDrive depend on:

• Conditional Access rules for browser and mobile access
• Device compliance and sign‑in risk checks
• MFA methods that users have registered

During migration, users may:

• Lose remembered devices and trusted browser sessions
• Be required to set up MFA methods again in the target tenant
• See new OWA MFA prompts when they sign in to their mailbox in the new tenant

If you do not prepare users, they perceive these prompts as outages or regressions, even when the system is working as designed.

Making OWA MFA and sign‑in changes predictable

To make OWA MFA predictable for users:

• Communicate clearly that MFA and sign‑in experience will change at cutover, including Outlook and browser access.
• Use staged rollouts, pilot groups and Temporary Access Pass where appropriate to smooth the experience.
• Align OWA MFA timing with mail routing cutover, so users see a single, understandable change rather than weeks of confusion.

When users know what to expect, they are less likely to overload the helpdesk or escalate to leadership on Day 1.

Governance Checklist For Modern Auth And MFA During M365 Migrations

For MSPs, governance is the safety rail that keeps temporary migration exceptions from turning into long‑term risk.

During Microsoft 365 migrations you often relax controls around modern auth, EWS and MFA so tools and service accounts can work. Without a clear checklist, those exceptions can quietly remain after cutover.

Pre-migration checks for MSP teams

Before cutover, MSPs should confirm:

• All migration tools use modern authentication, not legacy basic auth
• EWS app registrations, permissions and consent are documented
• Every migration account and app has a clear owner and purpose

You should also identify:

• Which accounts need Office365 turn-off MFA for non‑interactive migration
• Which Conditional Access policies must temporarily exclude those accounts or apps
• How those exceptions are constrained by scope, time and sign‑in location

Controls MSPs should enforce during migration

During the project, avoid broad tenant‑wide exceptions. Use tight, migration‑only paths instead.

Practical controls include:

• Dedicated migration accounts used only for tooling
• MFA disabled only on approved migration accounts, never on standard users
• Restricted sign‑ins (IP ranges, roles, schedules) for migration accounts
• Ongoing sign‑in and admin activity monitoring during the migration window

Post-migration cleanup MSPs must not skip

After migrations finish, temporary flex must be removed quickly.

Post‑migration cleanup should include:

• Re‑enabling MFA on migration accounts
• Removing Conditional Access exclusions created for migration
• Disabling unused app registrations, secrets and certificates
• Reviewing audit logs for unexpected sign‑ins or privilege use

For MSPs, this checklist is part of delivery quality. It proves you can move tenants quickly without leaving security debt behind.

The Reality: Tenant Migration Is Rebuilding Trust, Not Moving Files

At this point the pattern is clear: tenant migration is not a data copy exercise. It is a full rebuild of the trust relationships that make Microsoft 365 usable on Day 1.

You are rebuilding four layers at the same time:

• Identity mapping, so users, groups and permissions resolve correctly in the new tenant.
• Conditional Access, MFA and modern auth/EWS, so both users and migration tools can authenticate securely without constant failures.
• Device re‑enrolment and Intune, so endpoints stay compliant and familiar instead of feeling “broken” after cutover.
• App registrations and integrations, so line‑of‑business systems keep authenticating and talking to Microsoft 365 without hidden outages.

For MSPs, these trust layers carry most project risk. Treat them as first‑class workstreams aligned to governance, and Microsoft 365 tenant migrations become repeatable instead of reactive firefights.