Guide

A Google Workspace migration checklist for UK small businesses

Two weeks, four phases: inventory what you have, prepare the new Workspace and lower your DNS TTL, cut over on a quiet evening with the old system still receiving, then verify and tighten your email authentication over the following fortnight.

This is the plan we follow on a real migration, with the two steps people skip marked. Take it and run it yourself if you would rather.

By Lucas Reddington, full-stack developer and AI engineer, Northbytes. Last updated 26 July 2026.

The two steps everybody skips

Almost every migration that goes badly went wrong at one of two points, and neither is technically difficult. They just require patience at a moment when everyone wants to get on with it.

The first is listing every service that sends email using your domain. Your invoicing software, your CRM, your booking system, your marketing tool, the contact form on your website. Each of those has to appear in your SPF record, and each one you forget starts silently landing in spam folders a week later, when nobody connects it to the migration any more.

The second is lowering the TTL on your mail DNS records at least 48 hours before you switch. TTL is how long other mail servers cache your records. At the default of several hours, half the internet is still delivering to your old provider well into the next morning. Dropped to five minutes beforehand, the switch is effectively immediate, and you can put it back up afterwards.

Two weeks out: inventory

Every mailbox, its size, and whether it is a person or a shared address.
Every distribution list, alias and forwarding rule, including the ones nobody remembers setting up.
Calendars, especially shared ones and room resources.
Files: what is on desktops, what is on a shared drive, what is already in the cloud.
Every service that sends email using your domain. Invoicing, CRM, booking system, marketing tool, the website contact form. This is the item people miss, and it is what breaks deliverability afterwards.
Who has admin access to your domain registrar. Nothing can happen without it.

One week out: prepare

Workspace subscription created and the domain verified. Verification alone can take a few hours to propagate.
Users created with a naming convention you have actually agreed, because changing it later means changing it everywhere.
Groups and shared inboxes set up: info@, accounts@, and anything a team answers together.
TTL on your current mail DNS records lowered to five minutes, at least 48 hours before cutover, so the switch propagates fast when you make it.
Two-step verification policy decided and admin accounts secured first.
A pilot: one or two willing mailboxes migrated and used for a few days, so any surprise happens to a volunteer.

Cutover day: switch

Run the bulk data migration while the old system is still live and receiving. Nothing is in flight during the switch itself.
Change the MX records at a quiet hour. Friday afternoon is a bad quiet hour; Tuesday evening is a good one.
Publish SPF listing every legitimate sender you inventoried, then DKIM, then DMARC in monitoring mode only.
Leave the old mailboxes receiving for at least a week. Anything that arrives there is something you missed.
Send and receive a test message from each account, internally and from an outside address.
Tell everyone what changed, in one short message, before they discover it.

First fortnight: verify and tighten

Read the DMARC reports. They will show senders you did not know about; add the legitimate ones to SPF.
Move DMARC from monitoring to quarantine, then to reject, once the reports are clean. Doing this early blocks your own invoices.
Check nothing bounced: search the old system for messages received after cutover.
Confirm shared drives are shared with the right groups, not with individuals who might leave.
Enforce two-step verification for everyone once people have had a few days to enrol.
Decommission the old service only when the mailboxes have been quiet for a full billing period.

If it goes wrong, how you go back

Have this decided before cutover, because deciding it at 8pm while mail is bouncing produces worse decisions. The rollback is changing the MX records back to your old provider, which is why the old service must still be running and paid for.

With the TTL lowered, that takes effect in minutes. Mail already delivered into Workspace stays in Workspace, so you will have a short window of messages in two places, which is untidy but recoverable. Nothing is lost.

What makes rollback impossible is cancelling the old service on cutover day to save a month's fee. Keep it for a full billing period. It is the cheapest insurance in the whole project.

The week after: tighten the admin side

A fresh Workspace is a good moment to set the security defaults you would never get round to changing later. Enforce two-step verification for everyone once people have had a few days to enrol, starting with admin accounts on day one. Limit who holds admin rights to the smallest number that works, which in most small businesses is two people, so nobody is locked out if one is unavailable.

Share Drive folders with groups and not with named individuals, so access follows the role when someone joins or leaves. Write down an offboarding routine now: revoke access, transfer file ownership, delegate the mailbox, and do it the same day someone leaves. Both of those are on our cyber security checklist, which covers the wider picture.

And keep reading the DMARC reports for a month. They are the only way you find out that the payroll system has been sending as your domain from an address nobody documented.

Common questions

How long does a Google Workspace migration take?

For a team of under twenty, about two weeks end to end: a week of preparation and inventory, a cutover evening, and a week of verification. The actual data transfer is usually a few hours and runs in the background while your old system is still receiving mail. What takes the time is the inventory beforehand and the DNS verification afterwards, and skipping either is how migrations go wrong.

Will we lose email during the switch?

Not if it is sequenced properly. Data is copied while the old system is still live, so nothing is in flight when the MX records change. Lowering the DNS TTL 48 hours beforehand means the switch propagates in minutes instead of hours. And the old mailboxes stay receiving for at least a week afterwards, so anything that lands there can be forwarded on. That is the safety net, and it is why the old service is not cancelled on day one.

What is SPF, DKIM and DMARC, and do we need all three?

They are DNS records that prove your email is really from you. SPF lists which servers may send as your domain, DKIM signs each message cryptographically, and DMARC tells receiving servers what to do when a message fails the first two, plus sends you reports. You need all three: without them your mail is more likely to be filtered as spam, and anyone can send convincing email pretending to be your business. Start DMARC in monitoring mode and tighten it only once the reports are clean.

Can we migrate from Microsoft 365?

Yes, and it is one of the more common starting points. Mail, calendars and contacts move with Google's own migration tooling. Files are the part that needs thought: OneDrive and SharePoint content moves, but shared links break and permissions do not always map cleanly, so it is worth deciding what actually needs to come across before moving everything. Documents in Office formats keep working in Google's editors, though heavily formatted spreadsheets with macros will need attention.

What does it cost?

Google's own licence is per user per month. We manage the whole thing, licence included, for £14 per user per month with a minimum of three users, so there is one predictable bill and no separate Google invoice. The migration itself is part of that rather than a separate project fee. If you would rather run it yourself, this checklist is the plan we would follow, and you are welcome to it.

Sources

Figures quoted from outside Northbytes come from these sources, checked on 26 July 2026. Our own prices are our published rates.

Want us to do this for you?Email & Google Workspace

Want us to run it instead?

Tell us your domain and roughly how many people need an inbox. We'll handle the migration and the admin afterwards for one monthly figure, licence included.

Get a free quote