Moving your email to Microsoft 365 or Google Workspace without losing anything

Most moves happen for dull reasons. A hosting provider puts the price up, an old POP setup finally becomes indefensible, two companies merge and end up with two systems, or somebody wants Teams and shared files and realises the email has to move first. Whatever the reason, the fear is always the same: that a decade of history disappears on a Sunday and nobody notices until Tuesday.

In our experience the mail itself is rarely the hard part. Copying messages between platforms is a solved problem and the tooling is decent. What goes wrong is everything hanging off the mailboxes: the shared inbox the whole office answers from, the rule that quietly forwards invoices to the accountant, the scanner in the corridor that emails PDFs, and the DNS records that decide whether any of it arrives at all.

If you have heard a horror story about an email move, it will almost certainly be one of these. None of them are exotic. They are all things that were never written down before the move started.

This is the least interesting hour of the project and the one that decides how it goes. Before anybody picks a cutover weekend, write down what actually exists. Not what you think exists.

A shared mailbox is the thing small teams build their whole day around, and it is the thing that most often arrives on the other side subtly wrong. In Microsoft 365 a shared mailbox is a distinct object with its own permissions, and it does not need a licence up to a size limit set by Microsoft. In Google Workspace the equivalent is normally a group with collaborative inbox turned on, or a delegated account, and the two behave differently in ways your team will feel immediately.

The specific things to check after the move, on the day, are these: can everyone who used it still open it, does sending as the shared address still work, and does a reply land back in the shared mailbox rather than in the individual's own sent items. That last one is the classic. It looks fine for a week, then somebody notices that half the outgoing replies to customers are invisible to the rest of the team.

If your business runs on a shared inbox, tell whoever is doing the migration that before they quote. It changes the plan and it should change the testing.

Every email migration ends with a DNS change, and DNS is where the whole thing becomes real. Up until that point you are copying data with a safety net. The moment you change the MX record, live mail starts arriving at the new system and the old one stops being the truth.

Two problems recur. The first is access: nobody currently at the company can log into the domain registrar, because the domain was bought years ago by a web designer who has since moved on, or on a personal account belonging to someone who left. Sorting that out can take days or weeks depending on the registrar, and it cannot be rushed on the night. Check it in week one, not on the Friday.

The second is the records themselves. It is not only the MX record. SPF has to list the new platform, DKIM has to be published and turned on, and DMARC has to be sensible rather than copied from a blog post. Get these wrong and mail does not bounce loudly. It goes to junk at the recipient's end, quietly, and you find out because a customer says they never got your quote. That is a much worse failure than an outage, because nobody tells you it is happening.

One practical trick: lower the time to live on the MX record a day or two before the cutover. It tells the rest of the internet to check back sooner, so the switch propagates in minutes rather than hanging around for hours with mail split between two systems.

There is no single correct plan, but there is a shape that tends to work and a shape that tends to hurt. The safe shape keeps the old system alive and reachable until the new one has proven itself.

The week after a move is when the small things surface. A rule that did not come across, an alias nobody listed, a phone that keeps prompting for a password because the mail profile on it is still pointed at the old server. Budget attention for that week rather than treating the cutover as the finish line.

On cost, our email and mailbox migration work is usually priced between £40 and £75 a mailbox, depending on the platforms involved and how much of the surrounding mess needs untangling. Tenant to tenant moves after an acquisition sit at the higher end because there are two of everything. What we will not do is quote a per mailbox price without asking about shared mailboxes and devices first, because that is exactly where the honest number lives.

If you are weighing up a move, the useful thing to send us is not a mailbox count. It is a sentence about what your team would notice first if it went wrong.