8 min readWhy 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 Security Risks 

Once identity is stable, the next dependency hits immediately: 

Can those identities sign in safely, without locking everyone out? 

Conditional Access and MFA are where migrations feel calm, right up until they aren’t. 

At cutover, you typically see one of two outcomes: 

• Users can’t sign in (lockouts everywhere) 

• Users can sign in, but not under the controls you promised (a security gap at the worst moment) 

Why it happens is straightforward: Conditional Access policies and MFA registrations are tenant bound. They don’t move with the user during tenant to tenant migration. 

You can recreate/export CA policies, but the user-side state doesn’t transfer that includes MFA registrations, remembered devices, trusted sessions, authentication tokens 

And there’s another trap: if devices are still joined to the source tenant, they may fail device-based Conditional Access requirements in the target M365 tenant. 

So, Day 1 hits fast, usually on a morning bridge call: 

• Users must re-register authentication methods 

• Trusted sessions disappear 

• “Remember my device” is gone 

• Helpdesk tickets spike unless you front-run it 

What a clean MSP plan looks like 

Successful teams treat Conditional Access + MFA as a rebuild workstream, not a checkbox: 

• Document current policies, then align them to the security baseline the customer actually wants in the new tenant. 

• Rebuild and test with pilot users (sign-in flows, MFA prompts, device compliance behavior). 

• Plan MFA registration using staged rollouts, campaigns, or Temporary Access Pass to reduce helpdesk load. 

The goal is simple: make Day 1 sign-in boring. 

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. 

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

Here’s the mental model you can use with clients (and your own team): 

• Identity mapping determines whether users, groups, and permissions resolve correctly 

• Conditional Access + MFA determines whether users can sign in securely (without Day 1 lockouts) 

• Device re-enrollment determines whether endpoints stay usable and compliant 

• App registrations determine whether business-critical systems keep authenticating and running 

Treat these as first-class workstreams, with design, pilots, automation where possible, and wave-by-wave validation, and Office 365 tenant to tenant migrations stop being unpredictable. 

And here’s the MSP lesson: if you don’t scope these tracks separately, you’ll end up delivering them anyway, after cutover, under pressure. 

You’re not just moving data. 

You’re rebuilding the trust relationships that make Microsoft 365 usable on Day 1.