Migrate Business Email: How to Move Without Losing Messages

How do you migrate business email without losing messages?

To migrate business email means to copy the mailboxes, aliases, and old messages of your domain to a new provider, then point the MX record at the new system. The safe order is simple: create the new accounts, copy the old mail, switch the MX record, watch both sides, run a final sync, and rebuild the email clients.

The order matters because a mailbox keeps moving while you copy it. New messages arrive during the move, so you prepare the new mailboxes first, copy the history next, and change the routing last. Then a short final sync catches whatever slipped through. That keeps the risk of loss low, although no method gives you a guarantee.

1. Inventory: First, list the accounts, aliases, forwards, email clients, and connected systems.
2. New accounts: Next, verify the domain and create the users and aliases at the new provider.
3. Copy: Then run the official migration tool or an IMAP copy (IMAP keeps mail on the server), while the MX record still points to the old system.
4. MX record: This DNS record tells senders where to deliver mail. Lower its TTL (how long DNS answers stay cached) ahead of time, then enter your new provider's values.
5. Watching: While the change spreads, check whether new mail still lands in the old mailboxes, because both sides receive mail for a while.
6. Final sync: Run the tool again and pull the last messages from the old server.
7. Clients: Finally, connect Outlook, phones, and other apps to the new accounts and test them.

The sections below walk through these steps in order. In addition, each one names a frequent problem and what to check first.

When do you need to migrate business email?

You usually need to migrate business email in one of four situations. Each one has a different weak spot, so decide early which one fits you.

• Hosting mail to Google Workspace or Microsoft 365: The mailboxes sit on the hosting server, and the website usually stays there. For example, watch the forms your site sends, because they must reach the new system.
• Changing hosting: The site and the mail move to a new server together. We cover the general process in our hosting change checklist, so this guide looks only at email.
• Provider to provider: You move from one cloud mail service to another. Calendars and contacts also come into play.
• Taking mail back from an agency: The mailboxes sit in the agency's hosting or in the agency's account. Therefore you first clarify your right of access.

The logic stays the same in every case: prepare the new place first, copy second, and redirect last. If you have not chosen a target yet, read our comparison of Google Workspace and Microsoft 365 for business email.

What should you inventory before you start?

An inventory is the cheapest insurance when you migrate business email. A missing alias or a forgotten printer can turn into days of "email is not arriving" complaints. So open a simple list and write down the following:

• Mailboxes: address, owner, last use, and rough size. For unused mailboxes, decide whether to move, archive, or delete them.
• Aliases and forwards: For example, write down which mailbox info@ or sales@ reaches.
• Auto replies and filters: Note any server side auto reply, filter, or rule, because an IMAP copy moves messages only.
• Shared mailboxes: If several people read one, decide who gets access, because permission confusion is a common complaint on day one.
• Total size: The sum must fit the storage of the target plan. However, check the current plan on the provider's official page.
• Email clients: Outlook, Apple Mail, Thunderbird, phone apps, and webmail. Note which ones use IMAP and which use POP.
• Connected systems: Website forms, a CRM, an invoicing tool, a newsletter service, printers, and scanners may all send mail from your address.
• DNS records: MX, SPF, DKIM, DMARC, and any other mail records. Also note where your DNS lives.

To see your current records, use our free DNS lookup tool. Our Whois lookup tool shows which registrar holds the domain and who owns it. Finally, back up the mailboxes before you start. A backup from the hosting panel, or a file you export from the client, is your way back if something goes wrong.

Is your mail stored on the server or on devices?

A common cause of data loss in a move is assuming that mail sits on the server when it actually sits on one computer. Luckily, the protocol tells you.

• IMAP: The master copy stays on the server. The client works like a window, so migration tools copy the server version.
• POP: The client downloads mail and, depending on its settings, deletes it from the server. In that case, the only copy may sit on one computer.
• Local folders and archive files: Outlook data files, Thunderbird local folders, and mail you moved onto your Mac in Apple Mail never show up on the server.

To settle this, ask every user two questions. Which app do you use on which device? Did you ever archive or export your mail into a file? If the answer is "POP" or "archive file," you must move that data to the new account separately, because a server-side copy tool cannot see it.

Moreover, the old computers of former employees often hold the most valuable archives. Back up their mail files before anyone wipes those machines.

How do you move aliases, forwards, and shared mailboxes?

An alias is a second address that reaches the same mailbox. A forward, on the other hand, sends a copy of incoming mail to another address. Migration tools do not carry either of them over automatically, so you recreate them at the new provider by hand or with a bulk import.

For every alias in your inventory, create a match at the new provider. Otherwise, mail to that address bounces with an "address not found" error the moment the MX record changes. In other words, your customer sees the error and you do not.

Be careful with forwards, because a forwarded message can break SPF and DMARC checks. Our email forwarding guide explains the cause and the fix. If you run a catch-all address that collects mistyped recipients, read our article on catch-all email addresses to see whether you should keep one.

Which methods can you use to migrate business email, and which one fits?

No single method wins everywhere. The number of mailboxes, the source system, and your access decide the choice. The table below compares the options, when each one fits, and the risk.

The rule of thumb: pick a tool for many mailboxes, a client for a few, and an export file for archives that live on devices. Do not treat forwarding alone as a migration, because it leaves the history behind. Whichever method you pick, test it on one mailbox first. That way you measure the time, see how folders map, and catch surprises early.

What does Google's official tool migrate, and what does it skip?

Google offers two products for pulling email from IMAP servers into Google Workspace. The first is the data import tool in the admin console, which Google's documentation also calls the data migration service. The second is Google Workspace Migration for Microsoft Exchange, or GWMME for short.

According to Google's IMAP page, your server decides the choice. For example, if the server has a trusted TLS certificate and Google services can reach it, you use the data import tool. If the certificate is not trusted, the server sits on an internal network, or login needs a plain username instead of an email address, GWMME comes into play. Both products require a super admin.

However, there is a hard limit. The page says both tools move email and label data only. Calendar events, contacts, and Drive files stay out of this migration. In practice, your folder structure turns into Gmail labels. For the full steps, see Google's guide to migrating from IMAP servers. Menu names change over time, so we do not list them here.

How does Microsoft 365 IMAP migration work?

Microsoft offers IMAP migration for moving mailboxes from any source that supports IMAP into Microsoft 365. The general flow on Microsoft Learn looks like this:

1. Create the users in Microsoft 365 and assign licenses, because the mailboxes must exist first.
2. Verify with your registrar that you own the domain.
3. Tell your users how the move affects them, so nobody gets a surprise.
4. Prepare admin credentials or each mailbox password, and list the mailboxes in a CSV file.
5. Create a migration endpoint that connects Microsoft 365 to the source system.
6. Create a migration batch and start it, then verify the result.
7. Point the MX record at Microsoft 365.
8. After you confirm that routing works, delete the migration batch to stop the sync.

The documentation stresses three details. The method moves items in mail folders only, so contacts, calendar items, and tasks stay behind. It also moves messages from newest to oldest, which means users see their latest mail first. Finally, there are upper limits for items per mailbox and for the size of a single message. Check the current values on the Microsoft Learn IMAP migration page.

If your source is an Exchange server, Microsoft has separate methods. This guide covers the general IMAP case, so read the official documentation for Exchange sources.

What access do you need to prepare, and what about privacy?

Every tool needs credentials to reach the source server. With admin access you may not need each mailbox password. Without it, you must reset the mailbox passwords. Microsoft's documentation says so directly and warns that users who do not know the new password cannot open their old mailbox. Therefore, share the schedule with your users.

• IMAP details: Take the server name and port from the mail settings your hosting provider gives you.
• Valid certificate: Some tools cannot connect to a server with a certificate warning, which is why Google points to GWMME in that case.
• Connection limits: Microsoft recommends that you relax connection limits on the source to speed things up.
• Retention policies: Microsoft recommends that you turn off records management and archive policies during the move. Otherwise, messages that those policies delete or archive look "missing."
• Admin account: Prepare the admin account at the target provider with a recovery address and two-step verification.

Mailboxes hold personal data, so never send passwords by email. Hand out temporary passwords and make people change them after the move. Give admin rights only to the people who do the work, and take them back afterward. Also check the data location and your contract against the data protection rules that apply to you, such as GDPR in Europe or KVKK in Turkey. This guide is not legal advice, so ask a lawyer about contract questions.

What is TTL, and why lower it before the MX change?

TTL, short for time to live, tells resolvers how long they may cache a DNS record, measured in seconds. If the value is high, some mail servers keep using the old MX information until that time runs out, even after you change the record.

So you lower the TTL before you change the MX record. However, timing matters. The lower value only takes effect once the old cached value expires. Therefore, note the current TTL and lower it at least that long before the move. We give no number here, because the lowest value your registrar allows and your current setting may differ.

Finally, once everything runs smoothly for a few days after the move, set the TTL back to its normal value. A low value makes resolvers query your DNS more often than necessary. Put both dates, lowering and restoring, into your plan to migrate business email from the start.

What actually happens on the day you change the MX record?

The MX record tells the world which server receives mail for your domain. A sending server looks up this record first and then connects to that address. Also, RFC 5321 treats a lower MX number as the more preferred one.

Not everyone switches at the same moment. Senders whose cache has expired deliver to the new address, and the others still deliver to the old one. In other words, you see mail in both places for a while. This is normal, and it is the reason you keep the old system running.

The standard also expects a sending server to retry after a temporary failure. It says the give-up time generally needs to be at least four to five days. Still, not every sender follows this, so schedule the change for a quiet hour. See RFC 5321 for the details.

1. Export your full set of DNS records or take a screenshot, because those values are your way back.
2. Open your new provider's admin help and copy the MX values exactly.
3. Delete the old MX records or replace them with the new ones.
4. Save the change and confirm the new value with a DNS lookup.
5. Send a test message from a personal Gmail or Outlook.com address.

If you leave old and new records at the same priority, senders choose between them and your mail splits across two systems. Microsoft's guide to creating DNS records at any DNS host explains the general idea of entering MX records at a registrar.

Why do website forms go missing, and why does cPanel Email Routing matter?

If your site stays on hosting while the mailboxes move to Google Workspace or Microsoft 365, the sneakiest problem when you migrate business email is that contact form messages vanish. The form sends mail from the same server to an address like info@example.com. If the server still treats your domain as its own, the message never leaves and lands in an old local mailbox.

According to the cPanel documentation, the Email Routing screen offers four options: Automatically Detect Configuration, Local Mail Exchanger, Backup Mail Exchanger, and Remote Mail Exchanger. With Remote, the server does not accept mail for the domain and sends everything to the lowest numbered mail exchanger. Automatic detection only reads the local zone file and does not run a real DNS lookup.

As a result, the server can decide wrongly if you manage DNS outside the hosting account or if the local record is stale. Talk to your hosting provider before you change the setting, because a wrong choice can stop your domain from receiving mail. For the option definitions, read cPanel's Email Routing documentation.

The second trap is on the sending side. If the form mail leaves the hosting server and your SPF record does not include that server, the message may land in spam. The lasting fix is to send forms through your mailbox's SMTP details or a sending service. For example, our WP Mail SMTP guide covers WordPress. Also update the mail settings of printers and scanners the same way.

How do you check both sides while DNS changes spread?

While the change spreads, mail can land in the old and the new mailboxes. So you have to watch both. A small daily routine is enough:

• Open the old mailboxes through webmail or the old server's IMAP details and look for new mail.
• Check the new mailboxes for the test messages you sent to the same addresses.
• If you find new mail in an old mailbox, note it, because the final sync will pull it into the new one.
• Also ask an important partner to send a short test message to the new address.

You can also read the MX value on the command line:

dig +short MX example.com
nslookup -type=MX example.com

If you prefer not to use commands, the DNS lookup tool we mentioned earlier shows the same result in your browser. Query from your own network and from a different one, so you notice cache differences. Do not delete the old mailboxes until new mail stops arriving there completely.

How do you run the final sync, and when can you shut down the old mailboxes?

The final sync pulls the last messages that reached the old server after the MX change into the new mailbox. Many tools copy only new messages when you run them again. In Microsoft's IMAP migration, the sync continues until you delete the migration batch.

1. First, confirm that the MX value has spread and that no new mail reaches the old mailboxes.
2. Then run the copy tool one last time, or wait for its scheduled run to finish.
3. Compare folder counts and the newest message dates on a few mailboxes.
4. If everything matches, stop the sync. In Microsoft's case, that means deleting the migration batch.
5. Do not delete the old mailboxes right away. Keep them read only or back them up.

Ask users not to rename folders before the final sync, because most tools map folders by name. A renamed folder can get copied a second time.

Do not rush to cancel the old provider. Download the backup and open it to check it, then cancel. Your retention needs decide how long you wait. In particular, if your website lives on the same hosting, make sure you cancel only the email part, or you may take the site offline too.

How do you set up Outlook, phones, and Mac Mail again?

Telling users in advance is half the job when you migrate business email. Write one short message with the cutover day, the new sign-in address, and what they need to do on each device. After the move, clients keep pointing at the old server, ask for passwords, or report that they cannot connect. The fix is usually to rebuild the account, not to repair it.

1. Confirm that you can sign in to the new mailbox through webmail.
2. Remove the old account from the client. If Outlook keeps failing, create a new profile instead of patching the broken one.
3. Add the new account with the settings your provider gives you, or use automatic setup.
4. Wait for the first sync to finish. Large mailboxes take a while, so do not rush.
5. Check the inbox, sent, and drafts folders, and enter signatures and rules again.
6. On phones, delete the old account and add the new one.

Outlook rebuilds its local cache file for the new account, so do not count that as a loss. For setup details, read our Outlook IMAP and SMTP setup guide. Also, if an old program holds a local archive, move that file into the new account before you remove the client.

Why are calendars and contacts missing, and how do you move them?

IMAP based migrations move mail only. Both Microsoft and Google say so in their documentation: contacts, calendar items, and tasks stay behind. Therefore users ask "where are my meetings?" right after the move.

• Calendar: Export from the old client as an .ics file and import it into the new one. For example, spot check recurring events and time zones.
• Contacts: Move them with a .vcf or CSV file. If duplicates appear, merge them.
• Shared calendars: Share them again at the new provider and grant the permissions from scratch.
• Exchange source: Providers have separate methods that also cover calendars and contacts. However, check the scope in the official documentation.

Copy calendars and contacts before the cutover day, then check them once more afterward. That way, new invitations do not land in an empty calendar.

How do you update SPF, DKIM, and DMARC after the move?

Update the sender identity records so mail from the new provider does not land in spam. For the full setup, read our SPF, DKIM, and DMARC guide. Here we cover only the points specific to a move.

• SPF: A domain should have a single SPF record. Add the new provider to the existing record and remove the old provider if you no longer send through it. A second SPF record counts as an error.
• DKIM: Generate the DKIM key in the new provider's admin console and publish it in DNS. If you no longer send from the old provider, remove its old key later.
• DMARC: If your policy is already strict, meaning quarantine or reject, watch the reports closely during the move. If the new sender fails alignment, receivers reject the mail.
• Other senders: Also list services such as a newsletter tool, a CRM, and an invoicing system, and add them to the records.

Verify the result with our free SPF, DKIM, and DMARC checker. If you see rejection codes, recheck the records, because most rejections come from missing authentication.

Which problems appear most often when you migrate business email, and what do you check first?

If you work through symptoms in order, you solve most problems quickly. First, ask whether the MX record is right and whether the target address really exists, because that is the most common cause.

This order saves time: routing first, then content, then clients. After all, if routing is broken, no client setting or copied folder brings the mail back.

What should you do if you take email back from an agency or old provider?

If your email sits in an agency's hosting or in an agency's Google Workspace account, first find out who owns the account. The domain, the email service, and the website are often registered to different people. You can check the domain record with the Whois tool we mentioned earlier. We described the full inventory in our guide on how to take back your website and domain from an agency.

Keep the rules clear: never break into an agency's or anyone else's account, and never guess a former employee's password. That is legally risky and violates provider terms. The right path is to ask the authorized person in writing for admin access, a mailbox export, or an account transfer.

1. First, make sure the domain and its DNS are under your control.
2. Create the new provider account in your own name.
3. Ask the agency for the mailbox list, the aliases, and any exported data.
4. Run the copy with that data.
5. Finally, after you switch the MX record, close the agency's access.

This guide is not legal advice. If your contract says who owns the email data, ask a lawyer.

What belongs on your post-migration checklist?

The list below is the last check before you call the project to migrate business email finished. Print it and tick every item.

• Send an outside test message to every mailbox and reply to it.
• Test each alias and group address one by one, because a missing alias is a frequent problem.
• Send mail to Gmail and Outlook.com addresses and read the SPF, DKIM, and DMARC results in the headers.
• Fill in the website form and confirm the message arrives in the target mailbox.
• Compare folder counts and newest message dates on a few mailboxes against the old system.
• Confirm that Outlook, phones, and scanners work with the new account.
• Watch the old mailboxes for a while to confirm that no new mail arrives.
• Restore the TTL to its normal value.
• Write down the new DNS records, admin accounts, and recovery details in one place.
• Send users a short note with the new sign-in address and the two-step verification steps.
• Finally, add the cancellation date of the old provider and the backup deletion date to your calendar.

Do not call the move finished until the whole list is done. If an item stays open, make it the first task of next week.

Should you migrate business email yourself or hand it to a team?

If you have a few mailboxes, a simple DNS setup, and admin access, you can do the job yourself with the official tools. However, getting help is safer in these cases:

• You have many mailboxes, aliases, and group addresses.
• Mail sits on devices through POP or in local archives.
• The site, the forms, and the mail share one hosting account and move together.
• You do not know who controls the DNS, or you are taking over from an agency.
• The mailboxes hold sensitive or regulated data.

We are not a hosting or email provider. We set up, move, and manage your website and business email on Google Workspace, Microsoft 365, or your hosting provider. So to settle the scope, request a quote for website and business email setup or migration.