In this guide · 8 sections
- 01How an email migration works: cut-over vs staged
- 02What can go wrong during an email migration
- 03MX records and timing the switch
- 04Mailbox sizes, shared mailboxes and aliases
- 05What a provider should test before and after
- 06Rollback: what happens if it goes wrong
- 07Do it yourself or get help?
- 08Frequently asked questions
Short answer
A good migration copies old mail before the switch, changes the MX records at a quiet time with a low TTL, runs a final sync afterwards, and checks calendars, contacts, shared mailboxes and sending. The most common failures are IMAP tools that skip calendars and forgotten addresses.
How an email migration works: cut-over vs staged
There are two broad ways to move mailboxes. For most Singapore SMEs with under 50 users, a cut-over with pre-copying is the norm.
Cut-over with pre-copy
Most SMEs- Copy old mail to the new system while staff keep working
- Switch MX records once, usually Friday evening
- Run a final sync for mail that arrived during the switch
- Everyone moves on the same day
Best for: Companies of up to a few dozen users on one old system.
Staged migration
- Move users in batches over days or weeks
- Old and new systems run side by side
- Needs mail routing between the two systems
- More complex DNS and testing
Best for: Larger firms, or when departments must move at different times.
Microsoft's mailbox migration overview describes cut-over migration from Exchange Server for up to 2,000 mailboxes, but says 150 users or fewer is more reasonable. From cPanel or other hosting, the usual route is an IMAP migration.
What can go wrong during an email migration
Each failure below is common and preventable. Ask any provider how they handle each one.
| Problem | Why it happens | How to prevent it |
|---|---|---|
| Calendars and contacts left behind | IMAP migration copies only mail folders | Export and import them separately, or use a tool that moves them |
| Large emails missing | Microsoft's IMAP tool skips messages over 35 MB | Report skipped items and move them by hand |
| Mail lost during the switch | MX changed before the new mailboxes were ready | Create and test mailboxes first, then change MX |
| accounts@ or sales@ stops working | Shared addresses and aliases not listed | Inventory every address before starting |
| Sent mail lands in spam | SPF, DKIM and DMARC not updated | Publish new records on cut-over day and test |
| Phones still show old mail | Old account left on mobile devices | Give staff a short set-up guide and remove old accounts |
Microsoft's IMAP migration article states that this method does not migrate contacts, calendar items or tasks, migrates up to 500,000 items per mailbox from newest to oldest, and cannot move emails larger than 35 MB. Google's data migration service can import calendar events and contacts from Exchange Online, but from an IMAP source it moves email only.
MX records and timing the switch
The MX record tells the internet where to deliver your email. Changing it is the moment of the switch. Google's MX set-up guide warns that new MX records can take up to 72 hours to be recognised, so for a while some senders deliver to the old server and some to the new one.
Lower the TTL a few days ahead
Set the MX record's TTL (time to live) to a short value, such as 300 seconds, at least a day before, so the change spreads faster.
Verify the domain in the new system
Add the TXT verification record so Microsoft 365 or Google Workspace confirms you own the domain, as in Microsoft's add a domain guide.
Change MX at a quiet time
Friday evening or before a public holiday gives the weekend for the change to settle and the final sync to run.
Keep the old mailboxes open
Mail that still arrives at the old server during the switch is picked up by a final sync a day or two later.
Update SPF, DKIM and DMARC
Replace the old provider in SPF, turn on DKIM signing in the new system, and check DMARC reports for failures.
What a provider should test before and after
A provider should give you a written test plan, not just a 'done' message. These checks catch nearly every problem on the Monday after a weekend cut-over.
Post-migration test plan
Rollback: what happens if it goes wrong
A rollback plan is simple if the old system is left untouched. If a serious problem appears on day one, the MX record is pointed back to the old server and staff use the old accounts while it is fixed. That only works if the old mailboxes were not deleted, emptied or switched to forwarding.
Ask the provider three questions: how long they keep the old system running, who changes DNS back and how fast, and how mail received in the new system during the failed attempt is copied back. A provider who has no answer has not planned for failure.
Do it yourself or get help?
A sole proprietor or two-person firm with small mailboxes can follow our step-by-step guides: moving from cPanel email to Microsoft 365 and migrating between Google Workspace and Microsoft 365. If you are setting up a new domain from scratch, start with setting up business email in Singapore.
For larger mailboxes, shared addresses or a tight deadline, our Email Migration (S$390, up to 5 mailboxes, S$49 for each extra) moves mail, calendars and contacts where the source allows, switches DNS at a quiet time and runs the post-migration checks. New set-ups without old mail to move fit Business Email Setup (S$249).
Frequently asked questions
Not if it is planned. Old mail is copied before the switch, the MX record is changed at a quiet time, and a final sync picks up mail that reached the old server while DNS updated. Losses usually happen when the old hosting is cancelled too early or large emails are skipped without anyone checking.
With pre-copying, staff can usually keep sending and receiving throughout. The risk window is DNS propagation, which Google says can take up to 72 hours. During that time some mail may arrive at the old server, which is why the old mailboxes stay open until a final sync has run.
It depends on the source and tool. Microsoft's IMAP migration moves only email folders, not contacts, calendar items or tasks. Google's data migration service can import calendars and contacts from Exchange Online but only email from IMAP sources. Ask your provider exactly which data types their method covers.
An inventory of every mailbox, alias and shared address, a data size estimate, pre-copying, a planned MX change, a final sync, updated SPF, DKIM and DMARC, device set-up help, a written test plan and a rollback plan. It should also report any skipped items, such as emails over the size limit.
Only after the final sync has run and staff have worked on the new system for at least a week without missing mail. Many businesses keep the old hosting for a month. Cancelling early removes your rollback option and anything the migration missed.