Your email works, in the way a rusty gate works. One mailbox lives on the internet provider's server, two more sit on the web host you signed up with in 2014, and the owner's mail is a POP3 account that exists only on one elderly desktop. Nobody is quite sure where info@ actually delivers, and everyone has an opinion about whose fault the missing quote was.
Moving the lot to Microsoft 365 or Google Workspace fixes most of this in one stroke — if it's done in the right order. Done in the wrong order, it's how a business loses a week of mail and a decade of archive in the same afternoon. The right order isn't complicated — it's mostly a list.
Why businesses finally move
The trigger is usually one of three things. A POP3 mailbox — the kind that downloads mail to a single computer and, depending on a checkbox nobody remembers, deletes it from the server — meets a dying hard drive, and years of correspondence are suddenly at the mercy of one machine. Or the web host that threw email in with the hosting plan has an outage, and it becomes clear email was never really their business. Or five people share the password for info@ and nobody can say who answered the customer, or whether anyone did.
Microsoft 365 and Google Workspace fix the structural problems: every mailbox syncs to every device, aliases and shared inboxes are managed from one admin screen, and your mail lives on infrastructure whose whole job is mail. Which of the two suits you is a separate decision — Microsoft 365 vs Google Workspace walks through it — but the mechanics of the move are nearly identical.
First, find out what you actually have
Most migration disasters are discovery failures. The plan covered the five mailboxes everyone knew about and missed the sixth — the one that receives the orders. Before anything is touched, write down:
- Every real mailbox — a login with its own stored mail — and roughly how much each one holds.
- Every alias and forward — addresses like sales@ that exist only as a redirect into someone else's inbox. They cost nothing to recreate — if you know they exist.
- Auto-replies and server-side rules — the out-of-office still running on a retired partner's address, the rule that files invoices into a folder.
- Where each person reads mail — Outlook on a desktop, an iPhone, webmail. Every one of those needs reconfiguring on the day.
- Any POP3 account — flag these in red. Its mail may exist only on one computer, in one file, and must be exported before that machine has an excuse to fail.
Your old host's control panel and your DNS records will confirm the list. And if you've lost track of where the domain itself is registered, stop and fix that first — an expired domain takes email and website down together, and the rescue is messier than any migration.
Cutover or staged, in plain words
A cutover migration moves everyone at once: old mail is copied across ahead of time, then one weekend you point the domain at the new service, and on Monday the whole company is on it. A staged migration moves people in batches over weeks, with both systems running and forwarding to each other in the meantime.
For a business with a few dozen mailboxes or fewer, cutover is almost always the right call. Staged migrations exist for organisations too large to move in one weekend, and their coexistence period is where the fiddly failures live. If someone proposes running two email systems in parallel for a ten-person company, ask them why.
MX day, explained calmly
The heart of the project is one DNS record. The MX record is a signpost in your domain's public settings telling every mail server on earth where to deliver your mail. Migration day is the day you repaint the signpost.
Two facts take most of the fear out of it. First, copying the old mail is a separate job from switching delivery — the copy runs quietly in the background days beforehand and can be re-synced right up to the switch, so nothing is left behind. Second, mail in transit doesn't fall into a void. If a sending server hits confusion while the DNS change spreads, it queues the message and retries — email was designed in an era of unreliable connections, and it is patient.
The sequence: set up the new service, create the users and aliases from your audit, start the mail copy, and change the MX record once the copy has caught up. Immediately after — the same sitting, not the next morning — publish SPF, DKIM and DMARC records so the new service is authorised to send for your domain. Skip that and your first week of outbound mail lands in spam folders; the trio has its own guide.
The things that break on Monday
Mailboxes get all the attention, but machines use your domain's email too, and a forgotten machine does not announce itself. Check these before your staff find them:
- The office copier. Scan-to-email almost always sends through the old host's mail server, and it will fail silently after the switch. Both Microsoft and Google are stricter about authentication than the old host ever was, so this is a reconfigure, not a copy-paste.
- The website contact form. Many send through the old mail service, or from the web server in a way the new spam filtering distrusts. Submit a test yourself and confirm it arrives.
- Everything else that emails you. The backup job's nightly report, the alarm system, the point-of-sale end-of-day summary, the accounting package that emails invoices. If it sends mail, it belongs on the audit list.
The archive question
What happens to fifteen years of old mail? Mostly, it comes along. The migration tools copy folders and their structure into the new mailboxes, and current business plans have generous storage. Three exceptions deserve a decision. POP3 mail sitting in a local file on one computer is invisible to a server-to-server copy — it has to be exported and imported by hand. Mailboxes of long-departed staff don't each need a paid licence; they can be parked in a shared or archive mailbox instead. And if your industry has retention rules, decide where the archive lives before the move, not after.
And don't cancel the old email service the same week. Leave it idle for a few weeks, so anything the copy missed can still be fetched — cheap insurance against the folder nobody remembered.
The weekend ritual
Friday after close: run the final sync, change the MX record, publish SPF, DKIM and DMARC, and send yourself a test from an outside address. Saturday: reconfigure every computer and phone on the audit list — this is the labour, so budget the hours honestly. Sunday: the copier, the contact form, and the quiet machines. Monday morning: have someone reachable for password questions, because there will be password questions. If the destination is Microsoft 365, the wider setup decisions — licensing, security defaults, file storage — are covered in our Microsoft 365 setup guide.
If you'd rather keep your weekend
Email migration is a named Koadi service: Koadi moves businesses onto Microsoft 365 or Google Workspace without losing mail — the audit, the copy, the MX switch, the copier and the contact form included — then supports it afterwards. Or post the job free on the marketplace, where vetted, identity-verified technicians pick it up: you set a fixed price or take bids, escrow holds the payment until you confirm everything arrived, and remote help covers every US state, with on-site visits where hands are needed. Either way, Monday's mail just arrives.