This free email migration checklist moves a domain’s mail, calendars and contacts between Google Workspace and Microsoft 365, in either direction, or from one Microsoft 365 tenant to another. MSPs and IT teams use it for client switches, mergers and splits. It covers inventory, licensing and identity, staged or cutover approach, TTL and MX changes, SPF, DKIM and DMARC, the final sync, client setup, and keeping the source’s data until retention allows it to go.
The DNS work at the end is the same whichever way you move. The preparation is not: each direction has its own native tool, prerequisites and gaps, so the checklist asks for the direction first.
Prerequisites: a mail-routing subdomain on each side, and every user provisioned as a mail user before the batch runs.
Comes across: mail, rules, calendar and contacts. Rules arrive turned off.
Does not: vacation replies, room bookings, shared calendars and event colours.
Default method: up to 1,000 Exchange Online users at a time on Google’s shared quota.
Advanced method: your own Azure app, batches of up to 5,000 users, delta imports.
Watch for: Outlook rules become Gmail filters, but categories, flags and header conditions do not.
Licence: a Cross Tenant User Data Migration add-on per user, assigned in either tenant.
Domain: verified in one tenant at a time, so it has to be removed from every object in the source first.
Watch for: the domain move is the outage; plan it inside the window.
Two tooling changes matter this autumn. Google Workspace Migrate is no longer available for Exchange Online sources from October 2026, and Google points to its advanced data import instead. Microsoft began switching off Exchange Web Services in Exchange Online tenants in October 2026 unless admins had set an allow list, and retires it completely on 1 April 2027. If a third-party tool uses EWS for Exchange Online, confirm it has moved to Microsoft Graph. Files in Drive or OneDrive are a separate workstream.
Seven phases take a domain from inventory to a retired source. The direction chosen first decides which Phase 3 and 5 tasks appear, the plan approval halts the checklist before data moves, a failed pilot adds a repeat task, and held data gets a retention task.
The Direction dropdown on the first task shows the matching tool tasks in Phase 3. The Yes/No answer on the last task decides whether the retention task appears in Phase 7.
The approver named on the first task records Approved or Not approved on the last task. The checklist halts there, and no data moves until they decide.
The second, third and fourth tasks appear only for the direction chosen in Phase 1.
If the pilot result is recorded as Fail, the last task appears and the bulk copy waits.
The domain move task appears only for tenant to tenant, and the Autodiscover task only when the target is Microsoft 365.
The retention task appears only when Phase 1 recorded a hold or retention requirement in the source.
Most migration outages are DNS mistakes, not copy failures. These are the records Phases 4, 5 and 7 touch. Take exact values from each platform’s admin console.
| Record | Google Workspace target | Microsoft 365 target | When |
|---|---|---|---|
| MX | smtp.google.com at priority 1, the single record for newer setups | The value in the admin center; domains added from July 2026 get a host under mx.microsoft, earlier ones mail.protection.outlook.com | At cutover, with the old MX records removed |
| SPF (TXT) | include:_spf.google.com | include:spf.protection.outlook.com | Add the target before cutover; remove the source’s include at close |
| DKIM | A TXT record at google._domainkey with a 2048-bit key from the Admin console | Two CNAMEs, selector1._domainkey and selector2._domainkey, pointing at the tenant | Before cutover, then turn signing on |
| DMARC (TXT at _dmarc) | Unchanged by the platform; keep the current policy through the move | Review reports after cutover before tightening the policy | |
| Autodiscover | Not used | CNAME to autodiscover.outlook.com | At cutover |
| TTL on the above | Around 300 seconds during the move, restored afterwards | 24 to 48 hours before cutover | |
The authentication records matter more than they used to. Since February 2024, Gmail and Yahoo require anyone sending more than 5,000 messages a day to personal accounts to pass SPF, DKIM and DMARC, with at least a p=none policy aligned to the From domain. Outlook.com has required SPF, DKIM and DMARC from senders of more than 5,000 messages a day since 5 May 2025. A domain that sends invoices or newsletters can cross them, so a day of broken DKIM can put a billing run in spam.
Every include, a, mx and redirect term in an SPF record counts towards a limit of 10 DNS lookups. Adding the new platform while the old one and four marketing tools are still listed is how SPF quietly starts failing.
The direction dropdown on the first task shows the Microsoft batch tasks, the Google data import tasks or the cross-tenant tasks, and hides the rest. Your technicians follow one checklist whichever way a client is moving.
Tables inside the inventory tasks hold one row per mailbox batch and one per third-party sender, with owner and status. A data set keeps each client’s domains in one place, and tags keep every client’s migration separate.
A Yes on the retention question shows the preservation task before decommissioning, assigned and dated. The audit trail shows who approved the move and who confirmed the data was kept.
Email migrations are a staple MSP project. CheckFlow’s MSP process management software shows how to run them per client with tags, data sets and approvals, and the MSP process management guide covers standardising them. The MSP Client Onboarding Checklist covers the rest of a new client’s takeover.
The MX, SPF and DKIM changes follow the DNS Change Checklist. Licences and access for other SaaS tools that leave with the old platform are removed with the SaaS Offboarding Checklist, and what you keep from the source is governed by the Data Retention Review Checklist.
A single cutover over a weekend is simpler for small domains: everyone moves at once and there is no coexistence to manage. Larger organisations usually move in batches, which needs mail routing between the platforms so migrated and unmigrated users can still email each other. Microsoft’s Google Workspace migration uses a routing subdomain on each side for exactly this.
Some of it reaches the old platform until sending servers’ DNS caches expire. So the TTL is lowered a day or two ahead, every mailbox exists on the target before MX changes, and a final incremental sync afterwards copies anything that landed on the source.
SPF and DKIM, yes. SPF has to authorise the new platform, and DKIM needs new keys published and signing turned on before MX moves. DMARC usually stays as it is, but watch its reports after cutover, because a missed third-party sender shows up there first.
A custom domain can be verified in only one tenant at a time. Before the target tenant can verify it, the domain must be removed from every user, group, shared mailbox, resource and alias in the source, usually by resetting addresses to the onmicrosoft.com domain. Mail for the domain cannot be delivered in between, so plan the move inside the cutover window.
Only once retention is dealt with. In Google Workspace, deleting a user also deletes their data held by Vault, so Google recommends Archived User licences for data you must keep. In Microsoft 365, a mailbox becomes inactive and is kept only if a hold was applied before the account was deleted; without one, it is recoverable for 30 days and then gone. Check legal holds and the retention schedule first.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
