There is a phrase heard in almost every conversation about changing email provider: "yes, we know we should switch, but it's very complicated".
Behind that phrase lies a concrete and perfectly rational fear. Email is the nervous system of an organisation. If it fails for half a day, invoices stop, proposals stop, replies to clients stop. No one wants to be the person who decided to touch it.
This article will not say that migration is simple. It will say exactly what can go wrong, why it goes wrong, and how to avoid each case. Anyone who does this every day knows that trust is not earned by playing down risks, it is earned by naming them.
The seven real problems
1. Losing old messages. It is fear number one, and it is legitimate. A badly run migration can copy the history only partially and leave out entire folders, typically the oldest or the largest ones.
2. Not receiving email during the switch. There is a moment, when the domain's routing records are changed, when part of the world already knows about the new server and another part still points to the old one. Badly managed, that window produces lost or bounced messages.
3. Finding out too late that a mailbox was missing. Department accounts, addresses used by automated systems, mailboxes of an employee who has left but still receives client communications. They always turn up, and they are rarely on the initial list.
4. Leaving out forwarding and rules. Many organisations have years of accumulated rules: invoices that go to accounting, website forms that land in a shared mailbox, alerts sent to whoever is on shift. If these rules are not mapped beforehand, they are discovered by their absence, and always at the worst moment.
5. Emails starting to go to spam after the switch. Changing server means changing the technical origin of the messages. If the domain's sending authorisations are not updated at the same time, the company's legitimate email starts being treated as suspicious by the receiving systems.
6. Calendars and contacts being left behind. Many people treat migration as being about messages only. Then they discover that the appointments for the next six months and the team's contact list did not come across.
7. Each person's devices stopping working. The server has changed, but each employee's phone is still configured for the old one. Without a plan for this part, the result is a week of calls to support.
How to do it without scares
A well-run migration rests on one principle that solves half of the problems above: the source is never deleted.
The data is copied, not moved. While copying is under way, the old service keeps working exactly as it always has. If something fails, there is nothing to recover, because nothing was destroyed. This is the first question to ask any provider, and the answer should be immediate and straightforward.
From there, the work is organised in three phases.
Phase one: inventory. Before copying a single email, everything is listed. All mailboxes, including the ones nobody remembers. All aliases and forwarding. All relevant filtering rules. All external systems that send on behalf of the domain, from the invoicing software to the website form. It is the most tedious phase and the one that determines the success of everything else.
Phase two: parallel copy. Messages, folders, calendars and contacts are copied to the new infrastructure while the old service remains active. The team notices nothing. At the end of this phase, there are two complete copies, and the new one can be validated calmly.
Phase three: routing switch. Only once validation is done is the domain's routing changed to the new server. The change propagates across the internet over a few hours, and during that period both infrastructures receive email. That is why the old service stays active for a few more days: to catch whatever still arrives there.
A note on the timing of this phase. It is best done outside peak hours, and never on the eve of a financial close, a court deadline or a campaign. Not because of technical risk, but because any surprise is easier to handle on a Tuesday morning than on a Friday afternoon.
The client's part
There are three things no provider can do alone, and it is worth knowing this from the outset.
Decide what gets migrated. Not all history needs to come across. Some organisations bring everything, others bring the last three years and archive the rest. It is a business decision, not a technical one.
Give access to the domain. The routing change is made where the domain is registered. If no one in the company knows where that is, or who has the credentials, that is the first problem to solve. It happens more often than you might think.
Tell the team. An internal message, two days before, explaining what is going to happen and what each person will need to do on their phone, saves dozens of interruptions.
The questions to ask before signing
- Is the source data deleted at any point in the process? The correct answer is no.
- Does the current service keep working during the migration? And for how long afterwards?
- What is included: only messages, or also calendars, contacts, aliases and rules?
- Who updates the domain's sending authorisations, and when?
- Who supports the team in reconfiguring their devices?
- What is the plan if something goes wrong halfway through?
A provider that answers these six clearly has already shown more than any sales pitch.
And when migrating is not worth it
In all honesty, the reverse is worth noting. If the organisation is in the middle of a merger, a domain change or a deep restructuring of its teams, it makes sense to wait. Migrating twice is worse than migrating late.
Otherwise, postponing usually has a silent cost: more years of a service that no longer fits, more dependence on a configuration no one fully understands, and an ever larger history to move when the decision finally comes.
Migration is not the moment of risk. The moment of risk is the day the current system fails and there was no plan at all.