Monday after a migration weekend, the mail is there. Then the front desk can't open the info@ inbox, the conference room stopped taking bookings, invoices from the accounting system are landing in customers' spam, and the owner's phone is still pointed at the old server. None of that is about copying mail. It's about the things an email migration checklist should have caught a week earlier.
This applies whichever direction you're going: Google Workspace to Microsoft 365, the reverse, or off an old hosting provider onto either.
DNS, MX records and timing
Find out who controls your DNS before anything else. It's often a registrar account in the name of someone who left, or the web designer's login. You can't cut over without it.
Then lower the TTL on your MX records, to something like 300 seconds. Do it well ahead of cutover: the lower value only matters once the old TTL has expired everywhere, so if the current TTL is a day, change it at least a day before. After cutover, when everything is stable, raise it again.
Pick a cutover time when mail volume is low, and plan to run a final sync of anything that arrived at the old system during the switch. Some mail will keep trickling into the old platform for a few hours. That's normal, as long as someone is collecting it.
SPF, DKIM and DMARC
This is where most of the spam-folder complaints come from. Your domain is allowed to send only from the places your SPF record lists, and the new platform has to be on that list.
- SPF: add the new platform's include and keep the old one until the old system stops sending. A domain must have exactly one SPF record, and SPF allows at most ten DNS lookups, so merging includes carefully matters.
- DKIM: generate a signing key in the new platform's admin console and publish it in DNS. Turn signing on once the record has propagated.
- DMARC: if your policy is quarantine or reject, check that mail from the new platform passes alignment before cutover. Otherwise your own mail gets rejected by the people you're sending it to.
Then make a list of everything else that sends as your domain. The website contact form. The CRM. QuickBooks or whatever sends invoices. The copier that scans to email. A marketing tool. Each one either authenticates through your mail platform, in which case its settings need changing, or sends on its own, in which case it needs to stay in SPF and ideally sign with DKIM.
Shared mailboxes, calendars and delegated access
Shared mailboxes
The shared inbox called info@, billing@, support@. The two platforms handle these differently. Microsoft 365 has shared mailboxes that several people open alongside their own. Google Workspace has no exact equivalent; you use a Google Group set up as a collaborative inbox, or a licensed account that others are delegated into. Decide which model you're using for each one before you migrate, because it changes how the mail is moved and who sees what.
Calendars and room resources
Conference rooms, pool cars and shared equipment are resource calendars, and they need to be recreated on the new platform with their booking rules. Existing meetings carry their old video links, so a recurring Teams meeting moved into Google still points at Teams, and the reverse. Tell organizers of standing meetings to reissue them.
Delegated access
The assistant who manages the managing partner's inbox and calendar. The bookkeeper with access to the owner's mail. These permissions rarely migrate cleanly. List every delegation in advance and re-grant them on the new side the same day.
Phones and other devices
Every phone and tablet with company mail on it has to be reconnected. Some people will remove the old account and add the new one without help. Many won't, and their phone will keep showing old mail that never updates, or ask for a password every few minutes.
If you use device management, decide whether phones are enrolled in the new platform's version before or after cutover. If you don't, this is a reasonable time to start. Either way, write one page of instructions per phone type and have someone available that first morning.
Archives, retention and departed staff
Retention rules and legal holds don't move with the mail. A hold in Google Vault or a retention policy in Microsoft Purview belongs to that platform. If any mailbox is under a legal hold, talk to whoever placed it before you change anything, set up the equivalent on the new side, and don't close the old account until that's confirmed.
Look for archives outside the platform too. PST files on laptops, a mailbox export on a shared drive, an old archiving service someone still pays for. Decide whether each one comes along or gets retired, on purpose.
Then the accounts for people who left. We usually find a few still licensed. For each one, decide: migrate the mail, export and archive it, or let it go. Don't pay to migrate a mailbox nobody will open. On Microsoft 365, converting a former employee's mailbox to a shared mailbox is a common way to keep it reachable without a license.
Telling staff what's happening
People cope with change much better when they know about it. Send a short note a week out and another the day before. Keep it practical:
- When the switch happens, and what will look different on Monday
- What each person has to do themselves, such as reconnecting their phone
- What won't come across, if anything, so nobody goes looking for it
- Who to call, by name, if something is wrong
If you're still deciding which platform to move to, start with Google Workspace vs Microsoft 365. And if the move is partly about tightening security, it's a good moment to turn on MFA for everyone at once; see what cyber insurers look for.
If you'd rather not do this yourself
We run these migrations in both directions, including the DNS, the shared inboxes and the Monday morning. If you'd like a second pair of eyes on your plan, or someone to own the whole thing, book a free 30-minute call. Details on our Google Workspace and Microsoft 365 work.