Migrating twelve people to M365 without breaking lunch
A small migration done by one operator, in one afternoon. The plan, the actual playback, what we'd change next time.
A small migration done by one operator, in one afternoon. The plan, the actual playback, what we'd change next time.
A twelve-person professional-services firm asked us to move them off their inherited Google Workspace tenant onto Microsoft 365. They’d never had a real IT person before. Their previous setup was someone’s nephew, then nobody, then a sequence of “the laptop guy at the place down the street.”
We told them: it’s a one-afternoon migration if we do the prep right. They didn’t believe us. Fair.
This is what happened.
The customer couldn’t lose mail for more than an hour. They couldn’t lose calendar at all. Most of their billable work happens in shared Drive folders that would need to come over. And they refused to spend more than $X on the project itself — a budget that ruled out the “big-bang weekend migration” pattern most MSPs would default to.
Twelve users. One operator. A Tuesday afternoon. Constraints.
We picked the dual-delivery cutover pattern: mail flows to both mailboxes for 72 hours while users gradually switch their daily-driver. Calendars are exported as ICS, imported on the M365 side the day before, then re-confirmed live. Drive content syncs to OneDrive in advance, mounts read-only during the cutover hour, becomes read-write after.
We wrote the cutover runbook the week before — it was 14 steps, each with a “what could go wrong” footnote. That document is now in our corpus, anonymised. Future migrations of this shape take maybe 30% less prep time because the runbook is already there.
The cutover started at 1:00 p.m. on Tuesday. Lunch was over, the team was back at their desks but not yet deep in client work. Here’s roughly what happened:
1:00 p.m. — Switched MX records to the dual-delivery configuration. Both tenants started receiving the same mail. Tested with a known good sender from a third tenant.
1:15 p.m. — Triggered the final OneDrive sync for shared Drive content. The bulk of the data had been syncing in the background for 48 hours; this was the delta.
1:35 p.m. — Calendar import for all twelve users. We’d staged the ICS files the night before, mapped to the new mailboxes. Import was three minutes total.
2:00 p.m. — Walked each user through the new Outlook profile in person (or over Teams for the two remotes). The script was: “open Outlook, sign in with your new password, click yes on every prompt for the next thirty seconds, then come find me if your calendar looks empty.” Two users had calendar issues — both turned out to be a known Outlook quirk where the import takes a few minutes to populate the local cache. Resolved by 2:20.
3:00 p.m. — All twelve users on M365. Mail flowing on both sides. Calendar populated. OneDrive mounted. Nobody had stopped working.
3:30 p.m. — Wrote the post-migration summary, kicked it to the partner who’d signed the engagement. Closed the day with the dual-delivery configuration still active (so any in-flight mail to the old tenant would still arrive).
Following Friday — Cut the dual-delivery. Old tenant is now mail-archive-only. We’ll keep it that way for the contractual data-retention window, then walk away.
A few things, all small:
Pre-load the Outlook profile via Intune the morning of the cutover, not at the moment of the cutover itself. We had Intune in our scope; we just didn’t think to push the profile early. Would have saved ~20 minutes of walking around.
Make the calendar import script idempotent. We hit one user where the import had to be re-run because the first run timed out partway through. The script worked, but it imported some events twice. Cleanup took ten minutes.
Write the user-facing one-pager the day before, not the day of. We did write one — but at 12:55 p.m., which is too late to be useful. Email it the night before, hang a paper copy at every desk.
Skip the “in-person” walk-through for the most technical users. Two of the twelve were perfectly comfortable signing in on their own — we didn’t need to be at their desk. The walk-through is for the users who’d otherwise spiral if something looked weird.
Less than the customer expected. We don’t itemise other people’s invoices here, but: the project came in under budget, lunch wasn’t broken, and we wrote down what we did. The runbook is now in our corpus, ready for the next twelve-person migration that lands.
If you’re sitting in a Google Workspace tenant you’ve outgrown — or an M365 tenant someone else set up badly — this is the kind of work we do. Email us with what you’re running and we’ll come back with a one-page scope before you commit.
If your team could use the same thinking applied to your tenant, email or book a slot.