Migration Mapper
Moving your email? Get the map first.
Enter your domain and the tool detects where your email lives today, straight from DNS. Answer five questions, pick where you're going, and get a step-by-step migration plan, the traps specific to your route, and a written summary you can hand to any developer.
Where are you moving to?
How many mailboxes?
Shared mailboxes or group addresses (info@, sales@)?
Does old email need to come along?
Calendars and contacts too?
Do you have admin access to the current system?
Not sure what shape your email is in first? Run the Mail Rx checkup.
The traps that bite every migration
These do not depend on which platforms you are moving between. They are what turns a one-evening cutover into a two-week support incident.
DNS and cutover
| The trap | Why it bites | What to do instead |
|---|---|---|
| MX record still has a long TTL | The internet caches your old mail route for as long as the TTL says, so mail keeps arriving at the old system for hours after you switch. | Lower the TTL to five minutes at least two days before cutover, then raise it again once the move settles. |
| The autodiscover record still points at the old provider | Outlook finds its settings through autodiscover, so it keeps reconnecting to the system you just left and users see password prompts that never end. | Remove or repoint the autodiscover CNAME and any SRV record at the same time as the MX change, not after. |
| SPF was never updated for the new platform | Your new provider is not on the old permitted-sender list, so mail that leaves fine starts landing in spam. | Publish the new provider's SPF include before cutover, and keep the old one until the old system stops sending. |
| DKIM was never enabled at the destination | Signing has to be switched on at the new provider and published in DNS, and it is not automatic on most platforms. | Enable DKIM in the new tenant and confirm the public key resolves before you move the MX. |
| DMARC is set to quarantine or reject during the move | A strict policy plus a half-updated SPF record rejects your own legitimate mail at the worst possible moment. | Drop to p=none for the migration window, then tighten once the new setup reports clean. |
| The domain cannot be verified in the new tenant | A domain can usually only be claimed in one tenant at a time, and the old one has to release it first. | Confirm who controls the old tenant before scheduling anything. This single issue delays more migrations than any technical step. |
| Nobody has access to the DNS host | Verification and cutover both need TXT and MX changes, and the login often sits with a former web developer. | Prove you can edit DNS on day one by making a harmless change, not on cutover night. |
What does not come along by itself
| The trap | Why it bites | What to do instead |
|---|---|---|
| Shared mailboxes get migrated as regular user mailboxes | They then consume paid licences, or they lose the shared access everyone relied on. | Inventory which addresses are shared, which are groups, and which are aliases before the move, because the three behave differently on every platform. |
| Groups and distribution lists do not map one to one | Google Groups and Microsoft distribution lists have different membership, permission, and external-sender rules. | Rebuild them deliberately at the destination and test one external message to each. |
| Calendar delegates and permissions vanish | Most migration tools move calendar items, not the permission model around them. | Write down who manages whose calendar before cutover, then re-grant it after and have those pairs test it. |
| Recurring meetings and room bookings break | Long recurring series and resource mailboxes are the hardest objects to move cleanly, and they duplicate or lose organizers. | Expect to fix recurring series by hand, and re-create room and equipment resources at the destination. |
| Out-of-office replies and mail rules stay behind | Rules generally live with the mailbox on the old system and are not part of the data export. | Screenshot the rules for anyone who depends on them, especially auto-forwards that route mail to a second person. |
| Signatures disappear | Signatures are stored on the client machine or in the old web interface, not in the mail data. | Have people save their own signature to a document beforehand, or push a standard one centrally afterward. |
| Retention, journaling, or legal hold is silently dropped | Compliance settings are configuration, not data, and no migration tool carries them across. | If you are in a regulated business, write down every retention and hold setting first and re-apply it as a named step. |
Everything else that sends as you
| The trap | Why it bites | What to do instead |
|---|---|---|
| The copier and the scanner stop emailing | Office equipment authenticates with a saved mailbox credential or relays through the old server, and nothing tells it the world changed. | Inventory every device that sends mail and reconfigure each one during the cutover window, not after somebody complains. |
| Your CRM, invoicing, or booking tool starts bouncing | Those tools send as your domain and were authorized against the old setup. | List every application that sends mail as you, then add each one to SPF and enable its DKIM at the new provider. |
| An alarm, backup, or line-of-business app quietly fails | Machine-generated notifications fail silently, so nobody notices until the day the alert actually mattered. | Test every automated notification after cutover the same way you test human mailboxes. |
People and money
| The trap | Why it bites | What to do instead |
|---|---|---|
| Both platforms are being paid for at once | You need the old system alive while mail drains and users settle, which overlaps billing. | Budget for one to two months of overlap. Cancelling the old system early is the most expensive way to save money here. |
| Cutover lands on month-end or the busy season | The support load arrives on the days the business can least absorb it. | Pick the quietest window you have and tell everyone twice, including what will look broken and for how long. |
| There is no written rollback plan | When something goes wrong at 9pm, nobody agrees on what to revert or who decides. | Write down what gets reverted, in what order, and who makes the call, before you touch the first record. |
The ten habits that prevent most of it
- Inventory before you touch anything: mailboxes, shared addresses, groups, aliases, devices that send mail, and applications that send mail. The inventory is the migration; the rest is typing.
- Lower DNS TTLs at least 48 hours ahead so cutover is fast and reversible.
- Pre-stage everything you can: create the users, verify the domain, and sync the mail data days before the MX changes. Cutover night should be a switch, not a project.
- Sync the data more than once. A first pass days ahead and a final delta pass at cutover is the difference between a quiet night and a long one.
- Keep the old mailboxes receiving for at least two weeks. Mail that was already in flight has to land somewhere.
- Relax DMARC to p=none for the window, then tighten it once reports come back clean.
- Re-add accounts on phones and laptops rather than repairing them. Repair takes longer and works less often.
- Collect PST files from desktops before any machine gets rebuilt, because that data exists in exactly one place.
- Keep the old tenant alive and readable for 30 days. It is your only undo.
- Test after cutover the way a user works: send out, receive in, share a calendar, print from the copier, and trigger one automated notification.
After cutover: what users will report
Most post-migration tickets are the client on the desk, not the server. These six account for the bulk of them.
| What they report | What is actually happening | The fix |
|---|---|---|
| Outlook asks for a password over and over after cutover | Older Outlook builds only speak basic authentication, which modern mail platforms have turned off. The prompt loop is the client failing to authenticate a way the server still accepts. | Update Outlook to a current build, or confirm modern authentication is enabled for that account. Retyping the password will never fix it. |
| New Outlook and classic Outlook behave differently | They are separate applications with different feature support, and the toggle is easy to flip by accident. | Establish which one a person is running before troubleshooting, because the steps are not interchangeable. |
| Mail looks missing after the move | Cached Exchange Mode may only be syncing a recent window of mail, commonly a year, so older mail is on the server but not on the laptop. | Widen the sync slider or use the web interface to confirm the mail is actually present before anyone declares data loss. |
| A rebuilt profile appears to have deleted everything | The local OST cache was discarded and has to download again, which looks identical to loss while it runs. | Let it finish syncing before diagnosing. On a large mailbox this takes hours, not minutes. |
| Phones stop syncing after cutover | The device still holds the old server's settings, and management profiles can push them back. | Remove and re-add the account, and check any device-management profile that might be re-applying old settings. |
| Autodiscover prompts users to accept a redirect | The client asks permission to follow the new provider's configuration, and a confused user clicking no leaves themselves broken. | Warn people that the prompt is expected and tell them to accept it, ideally with a screenshot sent before cutover. |
PST, OST, and cache: the three words that cause the confusion
| Name | What it is | Why it matters in a migration |
|---|---|---|
| OST | A local cache of a mailbox that lives on the server. Outlook builds it automatically so the app works offline and feels fast. | Disposable. Deleting it loses nothing permanently, because the server holds the real copy and Outlook rebuilds it. Never treat an OST as a backup, and never try to migrate one. |
| PST | A standalone file holding mail that is not on the server, usually created by an archive or an export years ago. | This is the one that gets lost. A PST sitting on a desktop is invisible to every server-side migration tool and to your backups. Find them before machines get rebuilt. |
| Cached Exchange Mode | The setting controlling how much of the server mailbox is copied to the machine, often defaulted to the last twelve months. | It explains most reports of missing mail after a migration. The mail is on the server; the laptop was only ever told to hold part of it. |
Adding the account versus attaching a PST
- Add the account: Adding the account signs the client into the mailbox on the server. Mail syncs both directions, it is backed up by the provider, it appears on every device, and anything filed into it stays reachable from a phone. This is what you want in almost every case.
- Attach a PST: Attaching a PST opens an old file in the sidebar. It is local only. It never syncs, it is not backed up by the provider, it is invisible on the person's phone, and if that laptop dies the contents are gone.
- The rule: The mistake to avoid is attaching a PST and treating it as the migration. If old mail needs to be kept, import the PST into the server mailbox so it becomes real mail, then retire the file. Attach a PST only for read-only reference to something you have deliberately decided not to migrate.
This is planning guidance built from your DNS records and answers. It is not a substitute for a professional reviewing your specific environment before cutover. Nothing is stored after your session. Changes you make to your own systems are your responsibility, and a migration is the one time that is worth saying plainly: write down every value before you change it, and keep the old system alive until you are certain.