Moving email providers is not risky because it is technically hard. It is risky because your business does not stop while it happens, and mail that bounces during a cutover is a customer you never hear from.
An email migration is moving existing mailboxes from one provider to another with the history intact and no gap in delivery. That is a different job from setting up new email: there is data to carry across, a live service that must not stop, and a moment where mail delivery changes hands.
Done properly it is dull. The mail is copied while the old system is still running, the switch happens at a time you chose, and a second pass sweeps up anything that arrived in between. Done as a single dramatic evening of flipping records, it is how businesses lose quotes they never knew arrived.
The technical steps are not exotic. The sequence is what separates a boring migration from a bad one.
Mail gets copied to the new provider before anything about delivery changes. The old mailboxes carry on receiving throughout. Nothing is at stake yet, because if the copy stalls or the tooling misbehaves, your business has not noticed: mail is still arriving where it always did.
This is the opposite of how it goes wrong. The wrong way is to point the MX records at the new provider first and then start moving data, which means every problem from that moment on is happening to live mail.
Your DNS records have a TTL: how long other servers may cache them before asking again. Leave it high and mail servers all over the world will keep delivering to your old provider well after you switched, because they are working from a remembered answer.
So the TTL comes down ahead of the cutover, giving the old value time to expire everywhere. Then the change propagates quickly instead of dribbling out over days with mail landing in two places. Afterwards it goes back up. It costs nothing and it is skipped constantly.
The MX records change and new mail starts arriving at the new provider. Then a second copy pass catches everything that landed in the old mailboxes between the first copy and the switch. That delta pass is what makes the difference between "we moved your email" and "we moved most of your email".
The old mailboxes stay, with their data, until the new setup has been running long enough to trust. That is your rollback. A migration without one is a leap of faith with your business correspondence.
Moving delivery is only half of it. The other half is whether the rest of the internet accepts mail from your new provider as genuinely yours.
Your SPF record lists who may send as your domain. Change providers and that record has to change too: otherwise you are sending from somewhere your own domain does not vouch for, and receiving servers act accordingly. DKIM has to be re-established at the new provider so your mail is signed. DMARC has to be consistent with both, or you can end up instructing the world to reject your own mail.
This is the classic post-migration complaint. The move went fine, everyone is on the new system, and a week later half the invoices are landing in spam. Nobody connects the two events, because the mail is technically arriving, just not where anyone looks. It is authentication, every time. There is more at business email going to spam, and the records themselves live in DNS: see Cloudflare and DNS management.
How many mailboxes, how much history, what is a real account and what is an alias pretending to be one, and whether the old provider will hand the data over cleanly. This is discovery, and it changes the plan more often than not.
The current zone written down as it stands, so there is something to compare against and something to restore from. This is the rollback path, created before it is needed rather than during a panic.
Done early so the old cached value has expired everywhere by the time the switch happens. Ignore this step and the move has a long tail with mail arriving in two places.
Mailboxes, folders, contacts and calendars copied across in the background. Everyone keeps working. Nothing is at risk yet, which is exactly the point.
MX records switched when it is quiet for your business, not when it is convenient for us. New mail starts arriving at the new provider.
A second sweep for everything that arrived after the first copy and before the switch. This is what makes it a complete migration rather than a mostly complete one.
SPF, DKIM and DMARC corrected for the new provider, then real mail sent to real destinations to see where it lands. Assuming it works is not testing it.
Nothing is torn down on the day. The old mailboxes stay until the new setup has proved itself in normal use.
We would rather talk you out of this than take the work and hand you a problem.
We administer both Microsoft 365 and Google Workspace, so we move businesses in both directions and have no reason to steer you. The plan exists before anything moves, and the rollback exists before it is needed.
Not if the sequence is right. The way it is done: copy the mail across while the old system is still live and receiving, so nothing depends on the copy finishing. Then switch delivery. Then copy again to sweep up anything that arrived during the changeover.
Mail is only ever lost when someone flips the MX records first and hopes. There is no reason to work that way, and every reason not to.
It depends on how many mailboxes there are, how much history each one holds, and how cooperative the old provider is about letting the data out. The copying happens in the background while everyone keeps working, so the part that affects your day is the cutover itself, which is short.
The honest planning answer: the copying takes as long as it takes and does not disrupt you. The cutover is scheduled for when it suits you, and that is the only bit anyone notices.
That is the point of doing a migration rather than just creating new mailboxes. Mail, folder structure, contacts and calendars come across. Exactly how completely depends on what you are moving from and what it will hand over, which is something we establish before quoting rather than after.
If you did not need the history, you would not need a migration: you would need a fresh setup, which is a smaller job.
TTL is how long other mail servers are allowed to remember your DNS records before checking again. If it is set high, servers around the world keep sending to your old provider long after you have changed the record, because as far as they know nothing has changed.
So you lower the TTL well ahead of the move. Then when the switch happens, the world picks it up quickly instead of trickling over for days. Once things have settled, it goes back up. Skipping this is why some migrations have a long, messy tail where mail arrives in two places.
Yes, if it was planned that way, and that is a condition of doing it rather than a bonus. The old mailboxes stay in place and keep their data until the new system has been running long enough to trust. The DNS records are documented before any change, so reverting is a known step and not an improvisation.
A migration with no rollback path is not a migration, it is a leap.
Those are the two we most often move businesses onto, in both directions, because they are where most small businesses end up. But the reason to move should be a real problem you are having, not a logo. We would rather tell you your current setup is fine than migrate you for the sake of it.
Business email, files and calendars on your own domain.
DNS, SSL, caching and protection, configured properly.
Authentication, reputation, and the fixes that actually move the needle.
Straight advice on the systems your business runs on.
Certificates, hardening, and protection against the common attacks.
Tell us what you need and we will map out the simplest path.
Tell us where your email lives now and where it needs to go. We will map the cutover before anything moves.