Office 365 Migration Best Practices: 1.4M Users Later

We've migrated over 1.4 million users to Microsoft 365 — from Exchange 2010 boxes wheezing in server closets to 40,000-seat Google Workspace tenants. Every practice below exists because we watched a migration go wrong without it. This isn't theory. These are the rules we run every project by, with the failure that taught us each one.

Before you move anything

1. Inventory every mailbox — including shared, room, and equipment

DIY inventories count user mailboxes and stop. Then Monday morning arrives and nobody can book the boardroom, the accounts@ shared mailbox is missing, and the scanner-to-email address bounces. Shared, room, and equipment mailboxes don't appear in a casual look at the user list, and they're exactly the objects the business grinds to a halt without. Pull the full recipient list from the source — Get-Mailbox -ResultSize Unlimited plus Get-Recipient for distribution groups, mail contacts, and mail-enabled public folders — and reconcile it line by line against your migration plan. Our Microsoft 365 migration checklist has the full inventory worksheet.

2. Audit license SKUs before migrating, not after

A mailbox with no license lands in a 30-day grace period and then gets disconnected. We took over a project where the previous team migrated 340 users onto 300 Business Standard licenses — the last 40 batches sat in a queue for two weeks while procurement argued about budget, and MX had already flipped. Match every mailbox to a specific SKU before you create the first batch: archive mailboxes over 50 GB need a plan that supports them, shared mailboxes over 50 GB need a license, and litigation hold requires the right tier. License gaps discovered mid-migration become emergency purchases at whatever price Microsoft quotes that day.

3. Find the PSTs — they're on desktops and old file shares

Server-side migration moves the server mailbox. It does not move the eleven years of email a user dragged into a PST on their C: drive because IT enforced a 2 GB quota in 2013. In almost every legacy Exchange environment we assess, 20–40% of the organization's actual email lives in PST files scattered across desktops, laptops, and a file share named \\old-server\archive that nobody admits owning. Sweep for them before cutover — a login script or endpoint tool that reports .pst paths and sizes — and plan the import (network upload or drive shipping). The user who "lost all my email" three weeks after a flawless migration almost always lost a PST nobody found.

4. Map permissions and delegates — 60% of DIY users lose shared-mailbox access day one

Full Access, Send As, Send on Behalf, folder-level delegate rights, calendar publishing — none of it is visible in a mailbox list, and most of it doesn't survive a migration untouched. In DIY cutovers we've been called in to rescue, roughly 60% of users who relied on a shared mailbox or a delegated calendar lost that access on day one, because nobody exported the permission map before the move. Export it: Get-MailboxPermission, Get-RecipientPermission, and Get-MailboxFolderPermission on every mailbox, saved to CSV, reapplied and verified post-migration. Cross-premises permissions also don't work mid-hybrid — mailboxes that share access must move in the same batch, which you can only plan if you have the map.

5. Fix source data first — corrupted items fail batches

The Mailbox Replication Service is unforgiving about bad items: corrupted messages, malformed calendar entries, orphaned dumpster data. Hit the bad-item limit and the whole move request fails — usually at 2 a.m. on cutover night, usually on the CEO's 80 GB mailbox. Run New-MailboxRepairRequest on suspect mailboxes, clear oversized items above the 150 MB message cap, and empty recoverable-items folders that are near quota, all before you create batches. Cranking BadItemLimit to 500 to force a batch through isn't a fix — it's silently agreeing to lose 500 items. The full catalogue of these failures is in our post on Office 365 migration issues.

Security baseline before cutover

6. Turn on MFA and Conditional Access before users arrive, not after

A new tenant full of freshly synced passwords and zero MFA is the most attackable it will ever be — and attackers know migration windows are chaos. We've seen a tenant compromised eleven days after cutover because MFA was on the "phase 2" list; the attacker registered their own authenticator on a dormant account before the real user ever signed in. Enforce MFA registration and baseline Conditional Access policies while the tenant is empty, so every first sign-in happens inside the fence. Retrofitting MFA onto 500 already-working users generates ten times the helpdesk tickets of enrolling them at first logon.

7. Harden the tenant: disable legacy authentication

Legacy auth (basic auth for IMAP, POP, SMTP AUTH, older ActiveSync) bypasses MFA entirely — which makes practice #6 decorative if you skip this one. Password-spray campaigns target legacy endpoints specifically because they answer with a simple yes/no on credentials. Block it with Conditional Access before cutover, then watch sign-in logs for the two or three appliances — the scanner, the ERP notifier, the ancient CRM — that were quietly using SMTP AUTH. Finding them during a planned window is a config change; finding them post-cutover is an outage ticket.

8. Plan Intune enrolment as part of the migration, not a later project

Cutover is the one moment every user is already reconfiguring their devices. If Intune enrolment rides along with mailbox re-provisioning, you get managed devices for free; if you defer it "until things settle," you'll be asking users to touch their phones a second time six months later, and compliance-based Conditional Access stays theoretical until then. Decide the enrolment path (company portal, Windows Autopilot, ABM/Android Enterprise), pilot it with the same pilot group as the mailboxes, and ship it in the same communications.

The migration itself

9. Pilot with 10–20 real users, not the IT department

IT staff are the worst possible pilot group: they tolerate broken things, fix their own problems silently, and use email nothing like the business does. A pilot of sysadmins told us everything was fine; the first real batch surfaced a delegate-calendar chain in the finance team that the tooling flattened, and a legal team whose retention tags didn't map. Pick 10–20 users across departments — include the executive assistant with four delegated calendars and the sales rep who lives on mobile — and migrate them a full week before wave one. What breaks for them breaks for everyone; you just get to fix it quietly first.

10. Pre-stage 95% of the data before the cutover weekend

Migration bandwidth is not under your control — Microsoft throttles ingestion, sources throttle export, and no vendor tool changes the arithmetic. A 2 TB tenant does not move in a weekend, ever. The pattern that works: start initial sync one to three weeks early, let mail trickle across while users keep working in the source, and reserve the cutover window for the final delta pass only — which is typically 2–5% of total volume. Teams that try to move everything on the weekend are the ones sending the "migration extended into Monday" email.

11. Verify with hashes — we use SHA-256 per item

"The batch completed" is not the same as "the data arrived." Move reports show counts, and counts hide truncated attachments and silently skipped items. On regulated projects we compute SHA-256 hashes per item on source and destination and compare — it's how we caught a third-party tool that was quietly re-encoding attachments over 25 MB and changing their content. At minimum, compare item counts and folder sizes per mailbox against a pre-migration snapshot, and open a sample of large attachments by hand. If you can't demonstrate the data is intact, you haven't finished migrating; you've finished copying.

12. Keep the cutover window small: DNS changes in 2–4 hours, off-hours

The MX flip is the only genuinely irreversible-feeling moment, so make it short and quiet. Lower DNS TTLs to 300 seconds at least 48 hours ahead (the old 3600–86400 values are why "DNS takes 24–48 hours" folklore persists), then change MX, Autodiscover, and SPF in one 2–4 hour off-hours window — Friday 9 p.m. or Saturday morning, never mid-week. A tight window also means a tight rollback: if the delta sync or mail flow test fails, you flip MX back and users are on the source again before anyone notices. A cutover that sprawls across a business day has no clean rollback point.

13. Never delete the source until validation is complete

The most expensive sentence in this business is "we decommissioned the old server last week." Keep the source environment running, mail-flow-disabled but intact, for a minimum of 30 days after cutover — through at least one month-end close, because that's when finance discovers the report that only lived in a public folder. Deleting the source is the step that converts every small oversight (a missed shared mailbox, an unfound PST, a skipped archive) from a ten-minute fix into permanent data loss. Storage for one more month costs nothing against that.

After cutover

14. Run hypercare for 30 days

Most teams declare victory Monday afternoon and disband. The real failure curve says otherwise: mobile and delegate issues surface in week one, the missed shared mailbox in week two, and calendar and permission edge cases trickle in through week four. Staff a named hypercare channel — faster SLA, a dedicated queue, daily triage — for 30 days. It's also your validation backstop for practice #13: every hypercare ticket that traces to source data is a reason you kept the source alive.

15. Have an Autodiscover and mobile re-provisioning plan

Outlook profiles usually repair themselves once Autodiscover points at Exchange Online — but "usually" is doing heavy lifting. Stale local XML, an internal DNS zone still answering for the old server, or a forgotten SCP record in Active Directory will keep a subset of clients pointed at a dead Exchange box for days. Mobile is worse: most ActiveSync profiles will not silently re-home and need to be deleted and re-added. Write the per-platform instructions (iOS Mail, Outlook mobile, Android) before cutover, send them with the cutover notice, and expect 10–15% of users to need hands-on help anyway. That number is your Monday staffing plan.

16. Train users on what actually changed

Half of post-migration ticket volume isn't breakage — it's disorientation. Gmail users ask where their labels went; legacy Outlook users ask why the Focused Inbox is hiding mail; everyone asks what OneDrive is for. A one-page "what changed" note per source platform and a 30-minute recorded walkthrough cut our ticket volume measurably on every project we've tracked it. Skip training and your hypercare team spends 30 days answering the same six questions instead of fixing real problems.

17. Decommission properly — it's a project, not a power button

When validation is done and hypercare is quiet, the old environment comes out — in the right order. For Exchange hybrid that means keeping (or correctly removing) the last Exchange server for recipient management, cleaning up Autodiscover SCPs, retiring certificates, and updating firewall rules, not just powering off a VM. Do it wrong and directory sync keeps writing attributes you can no longer edit. We wrote the full sequence up separately: how to decommission Exchange after an Office 365 migration.

DIY or managed?

Honest answer: some migrations should absolutely be DIY, and vendors who pretend otherwise are selling fear.

DIY is genuinely fine when all four are true: fewer than 25 users; one source platform (a single Gmail tenant or one small Exchange server, not a merger's worth of both); no compliance or litigation-hold requirements; and one named person who owns the project end to end and has the hours to run practices 1–17 above. Under those conditions the native tools — Exchange admin center batches, Migration Manager for files — are free and adequate.

DIY stops being fine when any of those flip. In the projects we've been called to rescue, the pattern is consistent: roughly 45% of DIY cutovers miss their weekend window (usually practices 10 and 12 — no pre-staging, sprawling cutover), and about 30% lose data somewhere — a shared mailbox, a PST, delegate permissions — and most don't discover it until the source is gone (practices 1, 3, 4, 13). The failure isn't the tooling; it's that a first-time migrator is running a process an experienced team has run hundreds of times, and every practice on this list was learned by someone the hard way.

What managed actually buys you is not button-pushing — the buttons are free. It's the inventory that catches the room mailboxes, the permission map, the throttling math that sets a realistic timeline, hash-level validation, a rollback plan that has been executed before, and a team on hypercare that has seen your Monday-morning ticket a thousand times. You're paying for the absence of surprises, priced per user, against the cost of a business week without email.

FAQ

What are the most important Office 365 migration best practices?

Complete inventory (including shared, room, and equipment mailboxes), permission mapping before the move, pre-staging 95% of data before cutover, MFA and legacy-auth hardening before users arrive, and never deleting the source until validation is complete. Most migration disasters trace back to skipping one of those five.

How long should a Microsoft 365 migration take?

Small tenants (under 25 users): one to two weeks of prep, one weekend cutover. Mid-size (100–500 users): two to four weeks of pre-staging before cutover, plus 30 days of hypercare. The bottleneck is almost always source export throttling and data volume, not the tools.

Is a DIY Office 365 migration safe?

For under 25 users on one platform with no compliance requirements and a named owner — yes, with the practices above. Beyond that, the DIY failure rates we see (missed windows, lost shared-mailbox access, unfound PSTs) make managed migration cheaper than the recovery.