Forty-five mailboxes, eleven years of mail history, a shared cPanel server that had been quietly degrading for months, and a business that could not afford to lose a single enquiry. This is how that move was planned and run, and what it is actually like to migrate a mail system that people depend on all day.
Where the client started
A professional-services firm with staff across two offices. Everything ran on a single shared cPanel account: the website, forty-five mailboxes, a handful of shared addresses like info@ and accounts@, and a tangle of forwarders built up over a decade.
The problems that finally forced the move will be familiar:
- Quotes were landing in clients’ junk folders, intermittently, with no pattern anyone could identify.
- Mailboxes were hitting their quota constantly, and staff were deleting old mail to keep working.
- Nothing synced properly across devices, because most accounts had been set up as POP years earlier.
- Nobody knew who owned what. There was no list of addresses, and several forwarders pointed at people who had left.
- There was no backup beyond the host’s own snapshots, which nobody had ever tested.
The constraint was simple and non-negotiable: the firm bills by the hour and lives in its inbox. A morning without email was not an acceptable cost.
Day one: audit before touching anything
Most migration disasters are discovery failures, not technical ones. Something nobody mentioned turns out to be load-bearing, and it only surfaces after the MX records have changed.
So the first day produced no changes at all — only a complete inventory:
- Every mailbox, with its real size on disk rather than its quota.
- Every forwarder and alias, including the ones pointing at former staff.
- Every autoresponder, several of which were still announcing holidays from previous years.
- Every system that sends mail as the domain — the website contact form, the invoicing software, a scheduling tool and a CRM nobody had mentioned in the kick-off call.
- Current DNS, including TTLs, the existing SPF record and whether DKIM had ever been enabled. It had not.
What the audit caught: that fourth item. An invoicing system was sending statements through the cPanel SMTP server using credentials stored years earlier by someone no longer at the firm. Had the move gone ahead without finding it, invoices would have started failing silently on the day of cutover — and nobody would have noticed until customers stopped paying.
The inventory came to 45 mailboxes, 31 forwarders, 9 autoresponders and roughly 380 GB of mail. Eighteen of the forwarders pointed somewhere that no longer existed and were agreed for deletion rather than migration.
Day two: build Workspace alongside the live system
Everything in this phase happened in parallel with the old server, which carried on handling live mail without interruption.
- Workspace tenant provisioned and the domain verified by TXT record. Verification does not touch mail flow.
- All 45 users created with the same local parts as their existing addresses, organised into groups mirroring the firm’s two offices.
- Shared addresses rebuilt as Google Groups rather than mailboxes.
info@andaccounts@had been shared logins with a password three people knew — a group with named members is both safer and easier to hand over. - The 13 surviving forwarders recreated as aliases or group memberships.
- The legacy server added as a routing host, with a rule sending unrecognised addresses back to it. This is what makes a staged cutover possible — see split delivery for how that routing works.
- IMAP sync started for all 45 mailboxes. 380 GB took most of a day and a night, running against the live server at a throttled rate so as not to degrade performance for people still using it.
- MX TTL dropped to 300 seconds, several hours ahead of the switch, so the change would propagate in minutes and could be reversed just as fast.
By the end of day two, every mailbox existed in two places and the firm was still working entirely on the old system, unaware anything had happened.
Day three: the cutover
The actual switch took about four minutes. That is the point of the two days in front of it.
| Time | Action | Effect on users |
|---|---|---|
| 07:00 | Final delta sync begins | None — old server still live |
| 07:40 | MX records switched to Google | None — both systems accept mail |
| 07:45 | cPanel routing set to Remote Mail Exchanger | None |
| 07:50 | SPF updated, DKIM published, DMARC at p=none | None |
| 08:30 | Staff sign in to Workspace as they arrive | Mail already there, full history |
| 11:00 | Second delta sync for late-arriving mail | None |
| 16:00 | Verification pass and sign-off | None |
Staff arrived to a browser tab that already contained their entire mail history, correctly foldered. The only instruction they were given was their new password and a note that their phone would ask them to sign in again.
Why there was no downtime
Because at no point was there a window where mail had nowhere to go. Before the MX switch, the old server accepted everything. After it, Google accepted everything and forwarded anything it did not recognise back to the old server. The two overlapped. Mail sent during the propagation window arrived at one system or the other, and the delta syncs reconciled the difference.
This is the part people get wrong when they attempt it themselves: they delete the old mailboxes too early, or set cPanel to remote routing before the MX change rather than after, and open a gap where messages are refused.
What went wrong
Two things, because something always does.
A mailbox that was not a mailbox
One address in the inventory turned out to be a forwarder to a personal Gmail account that a departing employee had set up and never mentioned. It appeared in the audit as an address with no mail in it, which is exactly what a forwarder looks like from the outside. Because the routing rule was in place, mail to it kept flowing to the old server and nothing was lost — it was simply rebuilt as a proper alias the following week. Without split delivery it would have bounced from the moment the MX changed.
Two SPF records
Adding Google’s include to DNS produced a second v=spf1 record alongside the host’s original. More than one SPF record is invalid, and authentication fails outright rather than falling back. It showed up within the hour in the first DMARC reports and took two minutes to fix — merge into one record, never two. Covered properly in the SPF, DKIM and DMARC guide.
The verification pass
A migration is not finished when mail arrives. It is finished when it has been proven to arrive from every source, to every destination.
- Mailbox counts compared against the source for all 45 accounts, folder by folder.
- Headers checked on real outbound mail — SPF, DKIM and DMARC all passing, to an external address.
- Every sending system tested separately: the contact form, the invoicing software, the scheduling tool and the CRM found in the audit.
- Each group and alias sent to and confirmed to reach the right people.
- Mobile devices reconfigured for the handful of staff who had POP accounts.
- DMARC reports monitored for two weeks before tightening the policy from
p=noneto quarantine.
What changed for the business
- Quotas stopped being a daily concern. Business Standard brings 2 TB pooled per user against the 2 GB some accounts had been fighting with.
- Deliverability recovered, because outbound mail now leaves on Google’s reputation rather than a shared host’s, correctly signed.
- Shared addresses became accountable. Groups with named members replaced three people sharing one password.
- Mail syncs properly across desktop, web and phone, which POP had never done.
- The website never moved and never went down. Only the MX and mail-related TXT records changed.
What I would tell anyone planning the same move
- Spend the time on the audit. Every genuinely painful migration failure traces back to something nobody listed. The technical work is routine; the discovery is not.
- Use split delivery even if you intend to move everyone at once. It costs one routing rule and turns a cliff edge into a ramp.
- Never start DMARC at reject. Begin at
p=none, read the reports, find the forgotten senders, then tighten. - Drop your TTL a day early. It is free, and it is what lets you undo a mistake in minutes instead of hours.
- Keep the old mailboxes for a month. Storage is cheap; a missing archive is not.
Frequently asked questions
Does mailbox count change how long a migration takes?
Less than people expect. The sync runs in parallel across accounts, so total data volume matters more than the number of mailboxes. Forty-five accounts holding 380 GB took about as long as a handful of very large archives would.
Can staff keep working during the sync?
Yes. The sync is a read operation against the old server while it continues to receive and deliver normally. Users notice nothing until they are asked to sign in to Workspace.
What happens to mail that arrives mid-cutover?
It lands on whichever system the sender’s DNS resolved to at that moment. Both are live and accepting, so nothing bounces, and the delta sync afterwards brings across anything that reached the old server.
What does a migration like this cost?
It depends on mailbox count, data volume and how tangled the existing setup is — which is why the audit comes first and the quote comes after. Licence costs are separate and published on the Google Workspace pricing section, below Google’s own rates.
Planning a move of your own?
Tell me how many mailboxes you have and where they live now, and I will come back with a fixed quote and a migration window — audit first, cutover only once everything is already in place.
See Google Workspace plans →