A migration without downtime means that every message sent to your domain lands in a mailbox, and that every employee can write to their contacts on cutover day. It does not mean that the history, the mobile devices and people’s habits change without anyone lifting a finger.
Two platforms run in parallel.
The classic gap comes from an MX switched while a copy is incomplete, or from a copier, a website or a CRM that still sends with the old credentials.
The MX is a DNS record: it tells sending servers where to deliver mail for your domain. Changing email services means, first of all, changing this delivery address. Everything else (accounts, history, devices) is prepared around it.
The SMTP protocol copes well with short incidents. A sending server that receives a temporary error keeps the message in its queue and retries later. A server that is briefly unreachable therefore does not cause mail to be lost. A permanent error (unknown mailbox, message refused), on the other hand, returns the message to its sender, and that message will never arrive on its own. The main risk of a cutover is not an outage; it is the new platform refusing a recipient because an alias or a list was not recreated.
The TTL (time to live) sets how long a DNS resolver may keep an answer in memory. During that period, some senders still deliver to the old platform. This is normal, and it is why the old platform must remain able to receive during the transition.
Two weeks before. Inventory of mailboxes, aliases, lists, shared mailboxes, and all the applications that send mail. Lowering of the MX DNS TTL to a short value (often 300 seconds), so that cutover day propagates quickly. Creation of the target accounts. First copy of the history.
The TTL is lowered early because a resolver that has read the old value keeps it until it expires: the short TTL only takes effect once the old cache has run out. The first copy, for its part, is the longest; starting it early leaves time to discover the problem mailboxes.
A few days before. Check of a sample: number of messages, folders or labels, appointments, contacts. Correction of the method if the sample fails. Preparation of the mobile and Outlook instructions. Test send from the target to Gmail and Outlook.com, with SPF, DKIM and DMARC already valid on the new platform. These records can be published before the MX.
In practice: a single SPF record that authorises both platforms during the transition (two separate SPF records cause the check to fail), a DKIM key for the new platform published under its own selector, alongside the old one, and a reviewed DMARC policy. DMARC requires the message to be authenticated by SPF or by DKIM on behalf of the sender’s domain; if your policy is strict and the target is not yet authorised, your contacts reject your messages.
The day before. Second pass: copy only what has arrived since the first copy. Freeze changes to aliases and lists.
Cutover day. Switch of the MX. Immediate external check: an email sent from an outside personal mailbox must arrive on the new platform within the TTL. Monitoring of the queue. Reconfiguration of the sending applications. An identified internal hotline, with the authority to roll the MX back if a critical flow fails.
Change the autodiscover record at the same time if there is one: it is what Outlook queries to find its server. Also remove any secondary MX records that would still point to the old platform: a sender that cannot reach the primary MX tries the next ones.
The following days. The old platform in read-only mode. Reporting of discrepancies (a missing folder, a shared mailbox). A targeted third pass if needed. Then sending is shut off on the old platform, so that no employee replies from two places any more.
This last point has a technical reason. The old platform still considers itself responsible for your domain: a message sent from it to a colleague is delivered locally there, without consulting the MX. The colleague will never see it in their new mailbox.
| Risk | What happens | Countermeasure |
|---|---|---|
| MX switched too early | New mail arrives, the history is missing | Switch after checking the sample and running the second pass |
| Forgotten alias or list | The target permanently refuses these messages | Inventory, alias freeze the day before, test of shared addresses |
| Incomplete SPF, DKIM or DMARC | Your messages are rejected or marked as spam by your contacts | Publish before cutover day, check on a real message |
| Application sending with the old account | Invoices, alerts or scans no longer go out | List of applications, new SMTP server configured on cutover day |
| Sending left open on the old platform | Internal messages stay in the old system | Shut off sending as soon as the sample is validated |
| Rollback not prepared | The MX is rolled back, but the messages received in the meantime remain on the target | Written plan, including the recovery of these messages |
Take, by way of illustration, a 40-person firm. It chooses to switch on a Thursday at the end of the day rather than on a Friday: the next day, the team is present to deal with discrepancies, and the internal hotline has a full working day ahead of it. The reception copier, which scans to email, is reconfigured that same evening. If two shared mailboxes report a missing folder, a targeted pass fills the gap. In this scenario, no message is lost, but several employees have to set up their account again on their phone: that is the visible part that must be announced.
They change server in Outlook or on their mobile. The first load of a large mailbox takes time. Messages already cached on the phone may be duplicated if the profile is not recreated cleanly. Plan for the “delete the account and recreate it” procedure rather than patching the server settings.
The reason is the same for Outlook: the profile keeps a local cache tied to the old server. A new profile starts from a clean state; a modified old profile mixes the two worlds. On mobile, the protocol used (Exchange ActiveSync or IMAP depending on the target) sometimes changes with the platform, which is one more reason to recreate the account.
Server-side rules, centralised signatures and delegation rights have to be set up again. Announce it. This is not an interruption of mail. It is administration work.
This forwarding requires an explicit setting: the old platform, which still believes it hosts the mailboxes, must be configured to relay to the new one instead of delivering locally. Failing that, a targeted catch-up pass does the same job.
The specifics of each starting point are described in migrating from Microsoft 365 and migrating from Google Workspace.
Long enough to check that no flow still uses the old one, and that the reported discrepancies have been dealt with. This depends on the number of mailboxes, the applications that send mail and the pace at which workstations are reconfigured. Closing too early prevents corrections; closing too late leaves employees working in two systems.
No, if it is prepared. During the TTL period, some senders still deliver to the old platform, others to the new one. Both receive, and the next pass brings the two together. Mail is only lost if it is refused, hence the importance of aliases and lists.
Generally not: the addresses do not change. Do, however, notify partners who strictly filter your messages or who have assigned you a specific rule, and those who exchange encrypted mail with you, if the keys change.
Yes, by restoring the old MX, provided the old platform is still active. The messages received by the new one in the meantime must then be copied back or remain accessible. The rollback plan states who decides, how quickly, and how these messages are recovered.
Ask the operator what it guarantees: the arrival of messages, the transfer of the history, or both. These are different commitments. Also ask for the rollback plan, in writing, with the person who has the authority to activate it.
A guarantee on the arrival of messages covers cutover day and the following days. A guarantee on the history covers the copy and its verification. A provider can honour one without the other; the quote must state which one it takes on and how it is verified.
At Klytic, advice and suggestions for preparing the email migration are free, and no email is lost. A migration carried out by Klytic is priced on a quote basis. Subscriptions are on the Pricing page and are invoiced separately. The breakdown of cost items is in how much a Microsoft 365 migration costs, and the control list in the checklist. To compare targets, see choosing a European email service.
This page describes a method. The actual process depends on your flows, your volumes and the platform you are leaving.
Accessed in October 2026.
Free advice, no email lost. A migration carried out by Klytic is quoted after an inventory.
Welcome offer
No-commitment trial. An advisor calls you back to understand your needs and prepare your Klytic workspace.
