A national group was buying independently run locations across the country. Every new site arrived with its own email: some on their own Microsoft 365 tenant, many on Google Workspace, a few tied to a local server. Leadership wanted every location on one enterprise tenant with the same sign-in, security and naming, and they wanted it on a schedule that kept pace with the acquisitions.
- ~200Source environments consolidated
- 6–10Locations cut over every two weeks
- 2 weeksLead time per location, discovery to cutover
- 100%Delivered remotely
What success meant here: a location manager with no IT background could hand us a staff list, follow a short checklist, and have the whole site working in the new tenant the next morning, every two weeks, without the schedule slipping.
The situation
Each location was a small business in its own right, run by a site manager rather than an IT team. Its mail, files and calendars lived wherever the previous owner had set them up. The group already ran a central Microsoft 365 tenant with an email security gateway, security awareness training and on-premises Active Directory synced to Entra ID. Every location had to land inside that standard.
The pipeline did not pause. While one wave was cutting over, the next was in discovery and the one after that was waiting on staff lists.
What made it hard
- Mixed sources: Google Workspace, standalone Microsoft 365 tenants and the odd local server, often several patterns in the same wave
- No IT on site: site managers supplied staff lists and access, and those lists were often incomplete
- Shared front-desk workstations that needed a different license to run full Office apps
- Scanners, printers and line-of-business devices that sent mail directly and broke the moment MX records moved
- Domains everywhere: each site brought its own domain, DNS host and old SPF and DMARC records
- A fixed cadence: 6 to 10 locations every two weeks, across US time zones, all handled remotely
How we approached it
1. One runbook, counted back from cutover night
Every location followed the same two-week runbook with a named step for each day that mattered. Engineers didn't have to improvise, and site managers always knew what was coming next.
| When | What happened |
|---|---|
| 3–4 weeks out | Expectations call with the location manager: phases, schedule, what we need from them |
| ~30 days out | Automated scans of the source environment and data matching |
| ~25 days out | Staff list requested from and returned by the site manager |
| ~16 days out | Staff list ingested; accounts created, licensed and given shared mailbox access |
| ~14 days out | Site manager introduced to their support lead; migration projects built; devices and printers reviewed |
| ~12 days out | Pre-stage pass migrates the last 30 days of mail and files |
| 7 days out | One-week notice, on-site signage, login reminders; scanners and printers moved to an SMTP relay |
| 5 days out | Second pre-stage pass; MX record TTL lowered |
| 2 days out | Site readiness checklist and go/no-go with the site manager |
| Night before | Off-hours domain cutover and full migration pass |
| Day one | Morning check-in call with every site; bookable remote sessions for anyone stuck |
| After the wave | Post-mortem: what went well, what to fix, who owns it |
2. Prep driven by data, not by hand
Each wave had a master workbook. Staff lists went in, were cleaned against naming standards, and came out as the PowerShell that created accounts, assigned licenses and granted shared mailbox permissions. Repeatable inputs meant repeatable results, and a new engineer could shadow one wave and run the next.
3. A cutover checklist that held up at 7 PM the night before
Cutover night ran the same ordered checklist every time: clean the source tenant and release the domain, set a single MX record with a short TTL, replace SPF and DMARC, onboard the domain to the email security gateway, verify it in the target tenant, add it to the outbound connector, run the directory sync scripts, then start full passes for mailboxes, groups, Teams and OneDrive with BitTitan and SharePoint with ShareGate. Nobody called it done until inbound and outbound mail flow and the directory sync logs were checked.
4. Day-one support that didn't need anyone on site
The first call every cutover morning went to the site manager, not the other way round. Staff could book a short remote session to fix sign-in, Outlook profiles or mobile mail. Printers and scanners were already on the relay, so the front desk kept working.
5. Every wave made the next one easier
Post-mortems fed straight back into the runbook: fuller staff list templates, earlier shared-mailbox permissions so credentials and mailboxes arrived together, and clearer escalation rules for when the pace got tight.
Results
- About 200 source environments consolidated into one enterprise tenant
- A steady cadence of 6 to 10 locations every two weeks, delivered entirely remotely
- Every location landed on the same identity, naming, email security and licensing standard
- Devices that send mail kept working through cutover because they moved to the relay first
- The group kept a documented runbook and checklist set it could keep using for future acquisitions
What we'd tell a peer in the same spot
At this scale the hard part isn't any single migration. It's running the same migration well 200 times. Fix the runbook before you fix the tools, count every step back from cutover night, and make the site manager's job as small and as clear as possible.
Rolling up acquired locations?
We’ll look at what you’re bringing in, call out the real risks, and give you a written plan with sequencing and pricing.
Book a free consultation