A Microsoft 365 migration without downtime

The situation

Microsoft 365 had been there since 2018 for the Office apps, but mail still ran on-prem, "for now", for six years. The integrations were hairy: scanners mailing directly to the old system, a phone system talking to Exchange, distribution lists nobody could trace, and a hundred small signature templates baked into a share somewhere.

The fear wasn't the migration itself. It was mail loss, a downtime window the clients would feel, and the hundred small integrations no one fully remembered.

What we did

We always run migrations in phased waves with a real staging phase:

1. Inventory: what comes along, what stays, what doesn't need to (old shared mailboxes nobody had read in two years). 2. Pilot with 8 people, two weeks, in production. Scanner integrations broke here, we had time for that. 3. Cohort migration for the rest in four overnight waves of 15 people, with fallback and checks. 4. Old environment kept warm for 30 days before we unplugged it.

No weekend cowboy migration. No "should work Monday".

What it delivered

Post-migration:

- Zero mail loss, measured across all mailboxes before and after. - Per-user effective downtime between 0 and 25 minutes, scheduled overnight. - 92% of first-line issues solved by the helpdesk in week one, never escalated to the user. - One document describing the post-migration state and where the old environment had been.

The managing partner said he knew it had to be done, just not how calmly it could go.

What this wasn't

Not a lift-and-shift with hope it works. Not leaving a stray Exchange license "running somewhere" active. Not buying a migration tool because we can; we used Microsoft's own tools where they sufficed and ran the complex pieces by hand with scripts published in the runbook.