Email Migration Checklist Template for Google Workspace & Microsoft 365

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.

• Open the migration record, choose the direction and name the lead, client contact and approver — Google Workspace to Microsoft 365, the reverse, or tenant to tenant
• Export every mailbox with size and item count — the largest set the timeline
• List shared mailboxes, resource calendars, groups and aliases — and decide what each becomes on the other side, since the platforms model them differently
• Record delegates, send-as rights, forwarding and mail-flow rules — permissions rarely migrate cleanly
• Find every system that sends as your domain — CRM, invoicing, marketing tools, scanners and web forms
• Record retention policies, legal holds and archives in the source — Yes or No; before anything is deleted, someone has to know they exist

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.

• Buy and assign licences on the target — plus migration licences for tenant to tenant; Microsoft 365 shared mailboxes need no licence up to 50 GB
• Decide identity and sign-in — which platform is the identity provider afterwards, SSO, and how users enrol MFA on day one
• Choose staged or cutover — a single weekend suits small domains; larger ones move in batches with mail routing between platforms
• Plan coexistence for a staged move — mail routing subdomains, and how people check availability across two calendars in the meantime
• Agree the cutover date and the user communications — what changes, what users must do on the first morning and where to get help
• Approve the migration plan — the approver records the decision, with the inventory and schedule attached

The second, third and fourth tasks appear only for the direction chosen in Phase 1.

• Add and verify the domain on the target and create the users — without touching MX, so mail keeps flowing to the source
• Google Workspace to Microsoft 365: create both routing subdomains and provision mail users — Microsoft’s documented prerequisites before a migration batch
• Microsoft 365 to Google Workspace: set up data import — the advanced method needs an Azure app registration and gives you delta imports
• Tenant to tenant: set up cross-tenant migration and plan the domain move — list every object that uses the domain in the source, because each must be changed first
• Pause retention or archive policies that move items during the copy — Microsoft warns they make items show as missing in migration reports
• Confirm any third-party tool uses supported APIs — Microsoft Graph rather than EWS for Exchange Online

If the pilot result is recorded as Fail, the last task appears and the bulk copy waits.

• Migrate a pilot group that includes a shared mailbox and a delegate — the awkward cases, not just IT staff
• Check the pilot in detail — item counts per folder, calendar series, contacts and rules, compared against the source
• Run the bulk copy for all mailboxes days before cutover — so the final sync only has to catch recent changes
• Publish SPF and DKIM for the target before MX changes — turn on DKIM signing once the records resolve
• Lower the TTL on MX and related records — to around 300 seconds, 24 to 48 hours before cutover
• Record the pilot result — Pass, or Fail with the cause
• Fix the cause and repeat the pilot — the bulk copy waits until a pilot passes

The domain move task appears only for tenant to tenant, and the Autodiscover task only when the target is Microsoft 365.

• Freeze changes to mailboxes, groups and rules on the source — anything changed after this point has to be changed twice
• Tenant to tenant: move the domain — reset addresses in the source to the onmicrosoft.com domain, remove the domain, then verify it in the target
• Switch MX to the target and remove the old MX records — a leftover record with a lower priority keeps delivering to the old platform
• Update SPF to cover the target and every third-party sender — and stay within the 10 DNS lookups SPF allows
• Point Autodiscover at the target when moving to Microsoft 365 — a CNAME to autodiscover.outlook.com
• Run the final incremental sync after the MX switch — it picks up mail delivered to the source while DNS caches expired
• Watch DMARC reports for new failures — usually a third-party sender missed in the inventory

• Set up desktop mail clients against the target — a new Outlook profile rather than editing the old one
• Remove and re-add accounts on phones and tablets — including the native mail apps people forget they use
• Recreate delegates, shared mailbox access and send-as rights — from the Phase 1 list, then ask the people affected to test
• Re-point scanners and apps that send mail — new SMTP host, port and authentication
• Have users check rules, signatures and out-of-office settings — rules migrated to Microsoft 365 arrive turned off
• Run a hypercare desk for the first week — with its own ticket category

The retention task appears only when Phase 1 recorded a hold or retention requirement in the source.

• Keep the source read-only for an agreed period — 30 days is common, for late delta syncs and missing-email queries
• Preserve held data before removing anything — in Microsoft 365, apply the hold before deleting the account; in Google Workspace, deleting a user deletes their Vault data, so use Archived User licences
• Export and store anything the retention schedule still requires — with the location recorded on the task
• Cancel source licences at the right point in the billing cycle — after retention is settled, not before
• Remove the source’s DNS records — old DKIM keys, the old SPF include and verification records
• Sign off and close the migration — the approver confirms the result, with the final sync report and retention evidence attached