This business email migration guide explains how to move mailboxes, contacts, calendars, and DNS records from one provider to another without losing messages. A business email migration follows five phases: audit the current setup, prepare the new platform, copy historical mail, switch MX records, and verify everything before closing the old service. Most lost-email problems trace back to skipped steps in the first two phases. The sections below cover all 10 steps, a method comparison, DNS timing rules, and fixes for the problems IT forums report most often.
Key Takeaways
- A business email migration has two separate jobs: copying stored mail and redirecting new mail through MX records.
- Lower the MX record TTL to 300 seconds at least 24 to 48 hours before cutover so the switch takes effect within minutes.
- IMAP-based migrations move email folders only. Contacts, calendars, tasks, and inbox rules need a separate export.
- Run a delta sync after the MX change to capture messages delivered to the old server during DNS propagation.
- Publish SPF, DKIM, and DMARC records for the new provider at cutover to protect deliverability.
- Keep the old mailboxes accessible for at least 30 days after cutover.
What Is Business Email Migration?
Quick Answer: Business email migration is the process of moving a company’s mailboxes, folders, contacts, calendars, and mail routing from one provider to another while keeping the same domain addresses. The work splits into copying existing data and redirecting future mail, and each half fails in a different way.
Business email migration is the transfer of stored email data and mail routing for a company domain from a source platform to a destination platform. The source can be a shared hosting mailbox, an on-premises Exchange server, a cloud productivity suite, or a single webmail account. The destination receives copies of the data. DNS changes then tell the internet where to deliver new messages.
The volume of mail at stake is large. The Radicati Group’s Email Statistics Report, 2024-2028 estimates that 361.6 billion business and consumer emails were sent and received per day in 2024, with a forecast of 424.2 billion per day by 2028. A team of 10 people can hold years of contracts, invoices, quotes, and customer history in its inboxes.
What Moves during a Migration and What Does Not
A migration moves email messages and folders in almost every case, while contacts, calendars, rules, and permissions move only with certain methods. The table below shows typical coverage for the three most common approaches.
| Data Type | IMAP Sync | Export and Import (PST or MBOX) | API-Based Migration Tool |
| Email messages and folders | Yes | Yes | Yes |
| Read and unread status, flags | Usually | Usually | Yes |
| Contacts | No | PST yes, MBOX no | Usually |
| Calendars and recurring meetings | No | PST yes, MBOX no | Usually |
| Tasks | No | PST yes, MBOX no | Varies |
| Inbox rules and filters | No | No | Rarely |
| Email signatures | No | No | No |
| Shared mailbox permissions and delegation | No | No | Varies |
| Aliases and distribution lists | No | No | Varies |
The Internet Message Access Protocol is defined in RFC 9051 as a protocol for accessing and managing mail folders on a server. IMAP has no concept of contact cards or calendar events. That limit explains why IMAP migrations leave contacts and calendars behind. Microsoft’s migration documentation states the same limit: IMAP migrations move items in the inbox and other mail folders, while contacts, calendar items, and tasks must be moved separately.
Common Reasons Businesses Migrate Email
Businesses migrate email for four recurring reasons:
- Renewal pricing: Introductory rates end, and the renewal price no longer fits the budget.
- Storage limits: Mailboxes hit their quota, and adding storage costs more than switching.
- End of support: Exchange Server 2016 and Exchange Server 2019 reached end of support on October 14, 2025, so servers still running them no longer receive security updates.
- Professional addresses: A business moves from free personal addresses to addresses on its own domain.
How Long Does a Business Email Migration Take?
Quick Answer: A business email migration for a team of 5 to 50 users typically takes 1 to 3 weeks from audit to decommission. The data copy itself often finishes in hours or a few days. Mailbox size, source throttling, and DNS TTL values set the pace, and planning usually takes longer than the transfer.
Business email migration time depends on three variables: total data volume, the transfer rate the source server allows, and the TTL value on the domain’s MX records. The table below breaks a typical small business migration into phases.
| Phase | Typical Duration | What Sets the Pace |
| Audit and planning | 2 to 5 business days | Number of mailboxes, aliases, and connected apps |
| Destination setup | 1 business day | Mailbox count and access to DNS |
| TTL reduction lead time | 24 to 48 hours | Current TTL value on MX records |
| Pilot migration | 1 to 3 days | Issues found in test mailboxes |
| Bulk copy of historical mail | Several hours to several days | Mailbox size and source throttling |
| MX cutover | 5 minutes to 48 hours | TTL value and resolver caching |
| Delta sync and verification | 1 to 2 days | Mail volume during the cutover window |
| Parallel access window | 30 days or more | Retention needs and late messages |
Source platforms limit how fast data can leave. Large cloud suites apply per-user bandwidth and API throttling during migrations. Shared hosting servers often cap simultaneous IMAP connections per account. Throttling explains why two mailboxes of equal size can finish hours apart.
Our migration process copies mailboxes to temporary staging and verifies them before DNS changes, so the bulk copy phase in this table runs while your staff keep working in the old system.
Business Email Migration Methods Compared
Business email migration methods fall into five categories: cutover, staged, hybrid, IMAP sync, and export and import. Cutover, staged, and hybrid describe how many users move at once. IMAP sync and export and import describe how the data travels.
Cutover Migration
Cutover migration moves every mailbox in one scheduled event, followed by a single MX change. Cutover suits small teams because no period exists where some staff use the old system and others use the new one. Microsoft’s documentation for Exchange cutover migrations allows up to 2,000 mailboxes but recommends 150 or fewer, because creating and moving 2,000 users takes too long for one event.
Staged Migration
Staged migration moves users in batches, usually by department or office, over several days or weeks. Mail routing must stay coordinated between both systems until the final batch moves. Staged migration reduces risk for organizations with hundreds of mailboxes. Staged migration also requires forwarding or coexistence rules so users on both platforms keep receiving messages from each other.
Hybrid Migration
Hybrid migration connects an on-premises mail server and a cloud platform so both run as one organization for an extended period, with shared calendars across both. Hybrid deployments require the most configuration and mainly apply to larger companies that run their own Exchange servers.
IMAP Sync Migration
IMAP sync migration logs in to the source and destination mailboxes and copies folders and messages between them. IMAP sync works with almost every email host, including cPanel accounts and Roundcube webmail. IMAP sync preserves folder structure and read status, but it does not move contacts, calendars, or rules. Most IMAP sync tools can run repeatedly, which makes the final delta sync simple.
Export and Import with PST and MBOX Files
Export and import migration saves mailbox data to a file and then uploads that file into the new account. PST files come from Outlook on Windows and hold email, contacts, and calendars together. MBOX files hold email only and open in most other clients. File-based moves suit single mailboxes, archives, and POP3 users. Each file must be handled by hand, so file-based moves scale poorly past 10 to 15 mailboxes.
| Method | Best For | Moves Contacts and Calendars | Disruption Risk | Skill Required |
| Cutover | Teams of 150 or fewer moving in one event | Depends on tool | Low if scheduled after hours | Medium |
| Staged | Hundreds of users or several offices | Depends on tool | Low, but needs coexistence rules | High |
| Hybrid | On-premises Exchange with a long transition | Yes | Lowest during long transitions | Very high |
| IMAP sync | Any host, small to mid-sized teams | No | Low with a delta sync | Low to medium |
| Export and import | Single users, archives, POP3 users | PST only | Medium, due to manual handling | Low |
How to Use This Business Email Migration Guide by Team Size
Using this business email migration guide by team size means matching the method to mailbox count, source platform, and in-house skills. The table below gives a starting recommendation for five common situations.
| Team Profile | Recommended Method | Reason |
| 1 to 10 mailboxes on shared hosting | IMAP sync with a weekend cutover | Fast, low cost, no coexistence needed |
| 10 to 150 mailboxes on a cloud suite | Cutover with a migration tool | Moves mail, contacts, and calendars in one event |
| More than 150 mailboxes or several offices | Staged migration | Limits risk to one batch at a time |
| On-premises Exchange with a long transition | Hybrid migration | Keeps calendars and routing unified |
| Users on POP3 with mail stored on their computers | Export and import from each device | The server holds no complete copy of old mail |
Our Business Mail tiers line up with the first two rows of this table, with 10, 20, or 60 email addresses per plan, and we tailor mailbox counts and storage for teams that need more.
What Should You Audit before Migrating Business Email?
Quick Answer: Before migrating business email, audit every mailbox, alias, shared inbox, and distribution list. Then record mailbox sizes, current DNS records, and every app that sends mail from your domain. The audit takes a few days and prevents the most common post-migration failures, including bounced alias mail and silent website form outages.
Inventory Mailboxes, Aliases, and Shared Inboxes
A mailbox inventory lists every address that receives mail at the domain and the type of each address. Build the list from the current admin panel, not from memory. Include these address types:
- User mailboxes for current staff
- Shared inboxes such as info@, sales@, billing@, and support@
- Aliases that deliver into another mailbox
- Forwarders that send mail to an outside address
- Distribution lists and group addresses
- Catch-all settings for mistyped addresses
- Mailboxes of former employees that must be retained for legal or tax reasons
Archive or delete inactive accounts before the move. Migrating unused mailboxes adds transfer time and storage cost.
Business Mail includes aliases, email forwarding, and catch-all addresses on every plan, so each address type in this inventory has a direct equivalent after the move.
Measure Mailbox Sizes against Destination Storage
Mailbox size determines both transfer time and whether the destination plan has enough storage. Export a size report from the current admin panel, or check each account’s quota usage in webmail. Compare the total against the destination plan’s storage, and leave room for 12 months of growth.
Teams that exceed destination storage have three options:
- Archive mail older than a fixed cutoff, such as 24 months, to local MBOX or PST files.
- Delete large attachments that already exist in a file share or document system.
- Buy additional storage before the migration starts.
Our Business Mail plans list 1 GB of storage on Starter, 2 GB on Grow, and 5 GB on Pro, and we can tailor mailbox counts and storage when a team needs more. Our migration process starts with an assessment of your current provider and DNS, which is the right point to compare current mailbox sizes against plan storage before any mail moves.
Record Current DNS Records
Recording current DNS records means saving a copy of every mail-related record before anything changes. Save these records:
- MX records, including every hostname and priority value
- SPF record, the TXT record that starts with v=spf1
- DKIM records, the TXT or CNAME records under selector._domainkey
- DMARC record, the TXT record at _dmarc
- Autodiscover and autoconfig records that email clients use for automatic setup
- Webmail and verification records, such as CNAME and TXT entries added by the current provider
Export the zone file or take screenshots. The saved copy is the rollback plan if cutover fails. Confirm who controls DNS before planning further: the domain registrar, the current host, or a third-party DNS service. Migrations stall when nobody has the login for the account that holds the zone.
Map Every App That Sends Email from Your Domain
Mapping sending apps means listing every system that sends messages as your domain, because each one must be added to the new SPF record or reconfigured. Common senders include:
- Website contact forms and WordPress SMTP plugins
- WooCommerce order confirmations and password resets
- CRM, invoicing, and accounting software
- Help desk and ticketing systems
- Email marketing platforms
- Scanners and printers with scan-to-email
- Phone systems that send voicemail to email
- Booking and scheduling tools
A website contact form configured to send through the old host’s SMTP server stops working when that account closes. The failure is usually silent, so leads disappear without an error message.
If your website or store sends transactional messages such as receipts and password resets, Emercury SMTP Relay is available as an optional add-on with our Business Mail and is a listed feature in our SMB Hosting plans. Emercury SMTP Relay gives those system emails a separate sending path from staff mailboxes, and its sending details belong in your SPF planning alongside the new mailbox provider.
Document Rules, Signatures, and Delegated Access
Documenting rules and delegated access means capturing every inbox rule, forwarding rule, signature, and shared permission, since most migration methods do not move them. Use screenshots for rules, a shared document for signatures, and a device count for phones and tablets. The table below summarizes the full audit.
| Audit Item | Where to Find It | Why It Matters |
| Mailbox list and sizes | Current admin panel or webmail quota page | Sets storage needs and transfer time |
| Aliases, forwarders, catch-all | Admin panel email routing settings | Missing aliases cause bounced mail |
| MX, SPF, DKIM, DMARC records | DNS zone at the registrar or DNS host | Rollback plan and authentication baseline |
| Apps that send as the domain | Website, CRM, billing, and device settings | Each needs SMTP or SPF updates |
| Inbox rules and signatures | Each user’s client or webmail settings | Most methods do not migrate them |
| Shared access and delegation | Mailbox permission settings | Access must be rebuilt after the move |
| Mobile devices | Admin panel device list or a staff survey | Each device needs new account settings |
Business Email Migration Guide: 10 Steps from Audit to Decommission
The 10 steps below follow the order that prevents lost mail: preparation first, data copy second, the DNS change third, and verification last. Steps 1 through 6 happen while the old system still receives all mail, so staff work normally until cutover.
Step 1: Choose the Destination and Set a Cutover Date
Choosing the destination and cutover date means confirming the new plan meets mailbox, storage, protocol, and collaboration needs, then picking a low-traffic window. Confirm these capabilities on the destination plan:
- IMAP and POP support for desktop and mobile clients
- Webmail access for travel and shared computers
- Calendars, address books, and shared calendars if the team uses them
- Aliases, forwarding, and catch-all addresses
- Spam filtering and virus protection
- Storage that covers current mailbox sizes plus growth
Schedule cutover for a Friday evening or a weekend. Avoid month-end invoicing, payroll dates, and product launches. Tell staff the date at least 1 week ahead.
Every Business Mail plan includes each capability on this checklist, from POP and IMAP support to shared calendars, catch-all addresses, and spam and virus protection. You can add mailboxes or storage later without changing platforms.
Step 2: Lower DNS TTL 24 to 48 Hours before Cutover
Lowering DNS TTL means reducing the time-to-live on MX records, typically from 3,600 seconds or more to 300 seconds, at least 24 to 48 hours before the MX change. TTL tells DNS resolvers how long to cache a record. If the current TTL is 86,400 seconds, resolvers can keep routing mail to the old server for a full day after the change.
Lowering TTL in advance gives the old cached value time to expire. Once the new MX record is published, most resolvers pick it up within about 5 minutes. Restore the TTL to 3,600 seconds after cutover is stable. Some DNS hosts enforce a minimum TTL, so check the allowed range first.
Step 3: Create Mailboxes, Aliases, and Groups on the New Platform
Creating mailboxes on the new platform before copying data is required for IMAP migrations, because IMAP copies into existing accounts and does not create them. Use the same addresses as the old system. Set strong temporary passwords. Recreate aliases, forwarders, shared inboxes, and the catch-all setting. Complete any domain verification step the new provider requires, which usually means adding a TXT record. Test each mailbox by logging in to webmail on the new provider before the domain points there.
Step 4: Back Up Every Source Mailbox
Backing up every source mailbox creates a restorable copy outside both platforms in case the copy fails or data is deleted during cutover. Export each mailbox to PST or MBOX. Export contacts as vCard (.vcf) or CSV files. Export calendars as iCalendar (.ics) files. Store the backup on encrypted storage, and open a sample file to confirm it is readable. Treat the backup as a rollback copy that nobody edits.
Step 5: Run a Pilot Migration with 2 to 5 Mailboxes
Running a pilot migration means moving 2 to 5 test or volunteer mailboxes first to find errors before the full move. Choose mailboxes that represent the hard cases: the largest mailbox, a mailbox with deeply nested folders, folder names with special characters, and a heavy calendar user. Compare folder names, message dates, attachments, and item counts between source and destination. Fix every issue before moving the rest of the team.
Step 6: Copy Historical Mail to the New Platform
Copying historical mail is the bulk transfer of existing messages from source mailboxes to destination mailboxes while the old system keeps receiving new mail. Run the copy outside business hours when possible. Record item counts for each folder in each mailbox. Split very large mailboxes into date ranges if transfers time out.
Step 7: Switch MX Records at a Low-Traffic Time
Switching MX records means replacing the old provider’s mail exchanger records with the new provider’s records so new messages route to the new platform. Delete every old MX record. Leaving one old record at a lower priority splits incoming mail between two systems. Update autodiscover and autoconfig records at the same time so email clients find the new server. Confirm the change from a terminal:
dig MX yourdomain.com +short
nslookup -type=mx yourdomain.comBoth commands should return only the new provider’s mail servers.
When you move to our Business Mail, we configure the DNS records email depends on, including A, MX, SPF, DKIM, TXT, and CNAME records, and we cut over DNS at a low-traffic time. You do not need to edit zone files yourself unless you prefer to.
Step 8: Publish SPF, DKIM, and DMARC for the New Provider
Publishing SPF, DKIM, and DMARC for the new provider means updating the domain’s authentication records so receiving servers accept mail sent from the new platform. Update the SPF record in the same session as the MX change. Enable DKIM signing on the new platform and publish its public key. Keep the current DMARC policy until aggregate reports show the new provider passes. The section on email authentication below covers each record in detail.
Step 9: Run a Delta Sync and Verify Item Counts
Running a delta sync means repeating the copy process so only messages that reached the old server after the bulk transfer are moved. Run the first delta sync 24 to 48 hours after the MX change, when propagation is complete. Compare item counts for every folder against the counts recorded in Step 6. Spot-check the oldest message, the newest message, the Sent folder, and messages with large attachments in each mailbox.
Step 10: Reconnect Devices and Decommission after 30 Days
Reconnecting devices and decommissioning means updating every desktop and mobile client to the new server settings, then closing the old service after at least 30 days of parallel access. Remove the old account from each client instead of editing it, which prevents cached settings from sending through the old server. Standard secure settings are IMAP on port 993 with SSL/TLS, POP3 on port 995, and SMTP on port 465 with SSL/TLS or port 587 with STARTTLS. Run a final delta sync and a final export before cancelling the old account, and check the old contract for renewal dates so the account does not auto-renew.
How Do You Migrate Email without Losing Messages?
Quick Answer: Messages get lost during migration when mail arrives at the old server after the bulk copy and nobody copies it again. Lowering TTL in advance, deleting all old MX records at cutover, running a delta sync, and keeping the old mailbox active for 30 days closes each gap where messages can disappear.
Why MX Changes Do Not Take Effect Instantly
MX changes do not take effect instantly because DNS resolvers cache the old record until its TTL expires. During that window, some senders deliver to the old server and others deliver to the new one. Split delivery is normal during cutover. Split delivery becomes data loss only when the old mailbox is closed or ignored before late messages are copied.
Sending servers also retry. RFC 5321, the SMTP standard, recommends that sending servers keep retrying undelivered messages for at least 4 to 5 days before giving up. A message that fails during cutover often arrives later instead of disappearing, as long as the destination mailbox exists.
How a Delta Sync Captures Mail That Arrives during Cutover
A delta sync captures cutover-window mail by comparing source and destination folders and copying only the messages missing from the destination. Most IMAP sync tools match messages by their Message-ID header, which prevents duplicates. Schedule three delta syncs: the first 24 hours after the MX change, the second after 72 hours, and a final run just before decommission.
What to Do if Emails Bounce after the MX Change
Bounced emails after an MX change usually mean the address does not exist on the new platform or the new provider has not finished verifying the domain. A bounce code of 550 5.1.1 indicates an unknown recipient, which points to a missing alias or mailbox. Recreate the missing address, confirm the domain verification record, and ask the sender to resend.
How Do You Migrate Contacts, Calendars, and Shared Mailboxes?
Quick Answer: Contacts and calendars usually need a separate export and import, because IMAP migration copies email folders only. Export contacts as vCard or CSV files and calendars as iCalendar files, then import them into each new account. Shared mailboxes and delegated access must be rebuilt and tested after the move.
Migrating Contacts
Migrating contacts means exporting each user’s address book and importing it into the new account. Export personal contacts as .vcf or .csv files from webmail or the desktop client. Rebuild the company directory or shared address book on the new platform as a separate task. Note that the autocomplete list in a desktop client is a local cache, not a contact list, so suggested addresses disappear after a client reset unless users save them as contacts first.
Migrating Calendars and Recurring Meetings
Migrating calendars means exporting each calendar as an .ics file and importing it into the matching account on the new platform. Imported recurring meetings appear as events, but the link to the original organizer often breaks. Updates sent from the old system no longer sync. Ask meeting organizers to re-send their most important recurring meetings from the new platform during the first week. Re-share any team calendars and confirm each person’s access level.
Migrating Shared Mailboxes and Delegated Access
Migrating shared mailboxes means moving the mailbox data like any other account, then rebuilding who can read and send from it. Migrate every member of a delegation chain in the same batch. An assistant who manages an executive’s inbox and calendar loses access if the two accounts move on different days. Test send-as and read access with each delegate before the first business day on the new system.
On our Business Mail, imported contacts and calendars go into built-in address books and calendars, and shared calendars and public folders give delegated teams a place to rebuild access. Our team verifies data, webmail access, and client setups during migration, before DNS switches.
Email Authentication after Migration: SPF, DKIM, and DMARC
Email authentication after migration means publishing SPF, DKIM, and DMARC records that authorize the new provider to send mail for your domain. Mailbox providers now enforce these records. Since February 2024, Google and Yahoo require all senders to authenticate with SPF or DKIM, and require senders of more than 5,000 messages per day to publish SPF, DKIM, and DMARC. Microsoft began enforcing similar requirements for high-volume senders to Outlook.com consumer addresses on May 5, 2025. A migration that skips the SPF update fails these checks immediately, and replies to customers can start landing in spam folders.
| Record | DNS Name | Example Value | Migration Action |
| MX | @ | 10 mx1.newprovider.example | Replace every old MX record |
| SPF | @ (TXT) | v=spf1 include:spf.newprovider.example ~all | Add the new provider, keep other legitimate senders |
| DKIM | selector._domainkey (TXT or CNAME) | v=DKIM1; k=rsa; p=MIIBIjANBg… | Publish the new key, keep the old key until decommission |
| DMARC | _dmarc (TXT) | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com | Keep current policy and monitor reports |
SPF Rules That Break during Migrations
SPF rules break during migrations when administrators add a second SPF record or exceed the DNS lookup limit. RFC 7208 allows only one SPF record per domain. Two separate v=spf1 records produce a permanent error, and receiving servers treat the domain as unauthenticated. RFC 7208 also caps SPF evaluation at 10 DNS lookups. Adding a new provider’s include without removing unused ones can push the record past that limit. Merge all senders into one record, keep the old provider’s include only while the old system still sends mail, and remove it at decommission.
DKIM Selector Changes
DKIM selector changes are safe because each provider signs with its own selector name, so old and new keys can exist at the same time. RFC 6376 defines the selector as the label that tells receiving servers which public key to retrieve. Publish the new provider’s key before cutover. Delete the old provider’s key only after the old service stops sending mail.
DMARC Policy during the Transition
DMARC policy during the transition should stay at its current level while you confirm the new provider passes alignment. RFC 7489 defines three policies: none, quarantine, and reject. A domain at p=reject rejects every message that fails alignment, so a misconfigured new provider causes immediate delivery failures. Verify SPF and DKIM alignment with the pilot mailboxes in Step 5. Review DMARC aggregate reports daily for the first 2 weeks after cutover.
When we set up Business Mail, we configure the SPF and DKIM records together with the MX change, so the authentication work in this section happens inside the same scheduled cutover. DMARC policy decisions stay with your team, and our support team can explain what each record does.
Security Risks during a Business Email Migration
Security risks during a business email migration come from three sources: phishing that imitates migration notices, credentials shared with migration tools, and gaps in protection while two systems run in parallel. The financial exposure is significant. The FBI’s 2025 Internet Crime Report recorded 24,768 business email compromise complaints with $3,046,598,558 in reported losses, up from $2.77 billion in 2024. Attackers know staff expect unusual messages about new passwords and logins during a migration.
Apply these controls during every migration:
- Announce the migration through a trusted channel, such as a staff meeting or internal chat, and state that IT will never request passwords by email.
- Enable multi-factor authentication on new mailboxes before users log in. The FBI report specifically recommends MFA for webmail.
- Use app passwords or OAuth for migration tools, and delete any file that stores mailbox passwords as soon as the copy finishes.
- Review forwarding rules on the old system before migrating them. Attackers who compromise a mailbox often add hidden forwarding rules, and migrating those rules carries the compromise to the new platform.
- Encrypt backup files, since PST and MBOX exports contain complete mailbox contents.
- Revoke migration tool access and reset temporary passwords after the final delta sync.
Business Mail includes spam filtering, virus protection, and TLS-secured delivery on every plan, so filtering is active on new mailboxes before staff start using them.
Common Business Email Migration Problems and Fixes
Common business email migration problems include missing contacts, duplicate messages, devices still connected to the old server, and website forms that stop sending. The table below lists 10 problems reported most often in IT forums, with the usual cause and fix.
| Problem | Likely Cause | Fix |
| Contacts and calendars missing | IMAP moved email folders only | Export .vcf and .ics files and import them |
| Duplicate messages | Sync ran twice without duplicate detection, or labels became folders | Use a tool that matches Message-ID, then remove duplicate folders |
| Some mail still arrives at the old server | An old MX record remains, or TTL has not expired | Delete all old MX records, wait for TTL, run a delta sync |
| Desktop client keeps connecting to the old server | Cached profile or outdated autodiscover record | Create a new client profile and update autodiscover |
| Phones show only old mail | Mobile account still points to the old host | Remove the account and add it again with new settings |
| Website contact form stops sending | Form uses the old host’s SMTP credentials | Point the SMTP plugin at the new server or an SMTP relay |
| Outbound mail lands in spam | SPF missing the new provider, or DKIM not enabled | Update SPF, enable DKIM, review DMARC reports |
| Folders missing or renamed | Special characters or different folder separators | Rename folders before migrating, check IMAP subscriptions |
| Migration stalls or times out | Source throttling or very large messages | Split by date range, run off-hours, retry failed items |
| Messages fail to copy | Attachment exceeds the destination size limit | Find oversized messages first, save attachments elsewhere |
What Happens to POP3 Email during a Migration?
POP3 email often exists only on the user’s computer, because POP3 clients download messages and frequently delete the server copy. A server-side migration finds an empty or partial mailbox for these users. The fix is to export mail from the desktop client as PST or MBOX and import it into the new account. A second option is to add the new account to the same client over IMAP and drag local folders into it. Switch these users to IMAP on the new platform so mail stays on the server.
Business Mail supports both POP and IMAP, so POP3 users can switch to IMAP on the same account once their local mail is imported. Business Mail also comes with responsive, human support, so post-cutover issues such as a phone still pointing at the old server or a missing alias get answered by a person.
Moving Email off Shared Hosting or cPanel Webmail
Moving email off shared hosting or cPanel webmail requires separating mail routing from website hosting, because many small businesses run both on the same account. The right DNS change depends on what moves:
- Email moves, website stays: Change only the MX, SPF, and DKIM records. Leave nameservers and A records alone, and the website keeps running.
- Website and email move together: Changing nameservers moves the whole DNS zone. Recreate every mail record in the new zone before the switch, or mail stops at the moment nameservers update.
- Website moves, email stays: Copy the existing MX, SPF, and DKIM records into the new host’s DNS zone before changing nameservers.
cPanel has one setting that causes frequent confusion. When email moves to an outside provider, set Email Routing for the domain to Remote Mail Exchanger. If routing stays on Local Mail Exchanger, the old server keeps delivering website form messages into the old local mailbox, and those messages never reach the new inbox. cPanel mailboxes support IMAP, so IMAP sync works for the mail itself. Roundcube contacts export as vCard files.
Our small business hosting plans include free email with unlimited mailboxes, free SSL, and free site migration, so a website and its mailboxes can sit on one account. Teams that prefer email as a standalone service can pair our WordPress hosting or general web hosting plans with Business Mail.
Should You Migrate Business Email Yourself or Use a Managed Service?
Quick Answer: A do-it-yourself migration works for small teams on IMAP-compatible hosts with someone comfortable editing DNS records. A managed migration fits teams with more than 20 mailboxes, low tolerance for disruption, or nobody in-house who owns DNS. The real cost of a DIY move is staff time and the risk of a mistimed MX change.
Choosing between a DIY migration and a managed service depends on mailbox count, DNS skills, and tolerance for disruption. The table below compares both options on five factors.
| Factor | DIY Migration | Managed Migration |
| Direct cost | Often free for IMAP tools, paid for API tools | Included or quoted by the provider |
| Staff time | Planning, monitoring, and verification fall on your team | Provider handles copy, cutover, and checks |
| DNS changes | Your team edits records | Provider configures records |
| Lost-mail risk | Depends on following the delta sync steps | Provider runs parallel operation and verification |
| Best fit | 1 to 20 mailboxes with a technical owner | Larger teams or teams without in-house IT |
Free Business Email Migration Options
Free business email migration options include the import tools built into many destination platforms, open-source IMAP sync utilities such as imapsync, and manual drag-and-drop between two IMAP accounts in a desktop client such as Thunderbird. Free tools cost staff time instead of money. A desktop client copy also routes every message through the local internet connection, so a 10 GB mailbox depends on that connection staying up for the full transfer.
Our Business Mail migration follows the same order this guide recommends: we assess your current provider and DNS, copy mailboxes to temporary staging, verify data, webmail access, and client setups, cut over DNS at a low-traffic time, and support your team after launch. We parallel-run both systems and test before switching DNS to minimize disruption.
How Prestige Technologies Handles Business Email Migration
We handle business email migration at Prestige Technologies through a five-step process tied to our Business Mail plans, which are built for small and mid-sized teams. The process keeps your current system running until the new one is tested.
Teams move their email to us for three reasons:
- Human support: Responsive people answer migration and post-cutover questions.
- Domain and DNS help: We register a new domain or connect your existing one, then configure the records email needs.
- Room to grow: Mailboxes and storage can be added at any time without a platform change.
| Plan | Price | Term and Renewal | Email Addresses | Storage |
| Business Mail Starter | $5/mo | 12-month term, renews at $95/year | 10 | 1 GB |
| Business Mail Grow | $10/mo | 12-month term, renews at $195/year | 20 | 2 GB |
| Business Mail Pro | $15/mo | 12-month term, renews at $295/year | 60 | 5 GB |
Every Business Mail plan includes:
- Webmail plus POP and IMAP support for Outlook, Apple Mail, Thunderbird, and mobile devices
- Calendars, address books, tasks, shared calendars, and public folders
- Aliases, forwarding, catch-all addresses, and auto-reply
- Spam filtering, virus protection, and TLS-secured delivery
- The option to add mailboxes or storage at any time without changing platforms
- DNS help for MX, SPF, DKIM, and the other records your domain needs
Business Mail storage tiers are sized for active correspondence. Teams with large archives can request tailored storage or archive older mail locally before the move. For marketing email, list and newsletter automations are available through Emercury as a separate optional add-on, so campaign sending stays apart from staff mailboxes.
Business Mail or SMB Hosting Email: Which Fits Your Team?
Business Mail fits teams that want standalone email, while SMB Hosting fits teams that want a website and email on one account. The table below compares the two options on verified plan details.
| Factor | Business Mail | SMB Hosting |
| Main purpose | Standalone business email | Website hosting with included email |
| Starting price | $5/mo on a 12-month term | $5.99/mo on a 36-month term |
| Renewal | $95 to $295 per year by plan | Renewal rates apply after the term |
| Mailboxes | 10, 20, or 60 by plan, tailored above that | Unlimited mailboxes |
| Emercury SMTP Relay | Optional add-on | Listed plan feature |
| Migration help | Five-step mailbox migration process | Free site migration |
Post-Migration Checklist for the First 30 Days
A post-migration checklist confirms that mail flows correctly, authentication passes, and no user or device still depends on the old system.
| Timeframe | Tasks |
| Day 1 | Send and receive test messages with outside addresses on at least 3 different providers. Confirm MX with dig. Submit a test website form. Check one phone per user. |
| Days 2 to 3 | Run the first delta sync. Review bounce messages. Read the first DMARC aggregate reports. |
| Week 1 | Verify item counts. Import contacts and calendars. Rebuild inbox rules and signatures. Restore TTL to 3,600 seconds. |
| Week 2 | Run the second delta sync. Check the old mailboxes for late arrivals. Confirm every delegate has access. |
| Day 30 and later | Run the final delta sync and final export. Cancel the old service. Remove the old SPF include and DKIM key. Revoke migration tool access. |
After cutover, Business Mail customers can add mailboxes or storage at any time without changing platforms, which covers the new hires and archive growth that often follow a migration.
Final Thoughts on Moving Your Business Email
A successful email move depends on order more than tools. Audit first, lower TTL early, copy while the old system still works, switch MX records at a quiet time, then verify with delta syncs for 30 days. Each step closes a specific gap where mail can disappear, from missing aliases to forms that send through a closed account.
Follow this business email migration guide step by step, and the move becomes a scheduled maintenance task instead of an outage. If you prefer to hand off DNS configuration, parallel operation, and cutover, explore our Business Mail plans or contact our team to schedule your migration.
Frequently Asked Questions
What is a business email migration?
A business email migration is the process of moving a company’s mailboxes, folders, contacts, calendars, and mail routing from one email provider to another while keeping the same domain addresses. The process has two parts: copying stored mail to the new platform and changing MX records so new messages arrive there. Both parts need verification before the old service closes.
How long does a business email migration take?
A business email migration for 5 to 50 users usually takes 1 to 3 weeks from audit to decommission. The data copy often finishes in hours or a few days, depending on mailbox size and source throttling. Planning, DNS preparation, verification, and a 30-day parallel access window account for most of the total timeline.
Will I lose emails when I switch email providers?
You should not lose emails when switching providers if you follow four controls. Lower the MX record TTL before cutover, delete every old MX record at cutover, run a delta sync after DNS propagates, and keep the old mailbox accessible for at least 30 days. Most lost messages arrive at the old server after the bulk copy finishes.
Can I keep my email address when I change providers?
Yes, you can keep your email address when changing providers if you own the domain. You create the same addresses on the new platform, copy the old mail, and point the domain’s MX records to the new provider. Free addresses on a provider’s own domain cannot move, because the provider owns that domain.
What is the difference between cutover and staged email migration?
Cutover migration moves every mailbox in one scheduled event with a single MX change, which suits teams of roughly 150 users or fewer. Staged migration moves users in batches over days or weeks and needs coexistence rules so both groups keep receiving mail. Staged moves lower risk for large organizations but take longer to coordinate.
Does IMAP migration move contacts and calendars?
No, IMAP migration moves only email messages and folders. The IMAP protocol has no support for contact cards, calendar events, or tasks. Export contacts as vCard or CSV files and calendars as iCalendar files, then import them into each new account. Inbox rules, signatures, and delegated permissions also need to be recreated by hand.
What DNS records change during an email migration?
An email migration changes the MX records, the SPF record, and the DKIM records for the domain. Many migrations also update autodiscover or autoconfig records for automatic client setup and add a TXT record for domain verification. The DMARC record usually stays the same, but its policy should be reviewed against reports after cutover.
How long does MX record propagation take?
MX record propagation takes as long as the previous TTL value allows, which ranges from about 5 minutes to 48 hours. A TTL of 300 seconds means most resolvers see the new record within 5 minutes. A TTL of 86,400 seconds means some resolvers can keep using the old record for a full day after the change.
Should I lower my DNS TTL before migrating email?
Yes, lower the MX record TTL to 300 seconds at least 24 to 48 hours before migrating email. The lead time lets resolvers drop the old cached value, so the new MX record takes effect within minutes at cutover. Restore the TTL to 3,600 seconds once mail flows correctly on the new platform.
Is there a free way to migrate business email?
Yes, free ways to migrate business email include the import tools built into many destination platforms, open-source IMAP sync utilities, and dragging folders between two accounts in a free desktop email client. Free methods cost staff time instead of money. Free methods work best for small teams with someone comfortable editing DNS records and checking item counts.
What does an email migration service do?
An email migration service plans and runs the move for you. The service typically audits the current setup, copies mailboxes to the new platform, configures DNS records, schedules the MX cutover, runs follow-up syncs, and helps staff reconnect devices. A managed service suits teams without in-house IT or teams that cannot tolerate disruption.
What is a delta sync in email migration?
A delta sync is a follow-up copy that moves only messages added to the old mailbox since the previous sync. Delta syncs capture mail delivered to the old server while DNS changes propagate. Run the first delta sync 24 to 48 hours after the MX change and a final delta sync before closing the old account.
How do I migrate POP3 email to a new provider?
Migrate POP3 email from the user’s computer, not the server, because POP3 clients usually download messages and delete the server copy. Export mail from the desktop client as a PST or MBOX file and import it, or add the new account over IMAP in the same client and drag the local folders into it.
Do email rules and filters transfer during migration?
Inbox rules and filters rarely transfer during migration, because providers store them separately from message data. IMAP sync and file exports do not include them. Take screenshots of every rule before cutover, then rebuild the rules on the new platform during the first week. Review forwarding rules carefully, since unexpected forwarding can indicate a compromised mailbox.
How do I move email from one business account to another?
To move email between two business accounts, create the destination mailbox, connect both accounts to an IMAP sync tool or a desktop client, and copy folders from source to destination. Then export and import contacts and calendars separately. If the domain also moves, update the MX, SPF, and DKIM records after the copy finishes.
What should I back up before migrating business email?
Before migrating business email, back up every mailbox as a PST or MBOX file, contacts as vCard or CSV files, and calendars as iCalendar files. Also save the current DNS zone, inbox rules, signatures, and a list of aliases and forwarders. Store backups on encrypted storage and open a sample file to confirm it is readable.
Why are my emails going to spam after migration?
Emails usually go to spam after migration because the SPF record does not include the new provider or DKIM signing is not enabled. Receiving servers then cannot confirm the new platform is authorized to send for the domain. Update SPF, publish the new DKIM key, and check DMARC aggregate reports to confirm messages pass alignment.
How long should I keep my old email account after migrating?
Keep the old email account active for at least 30 days after migrating. The overlap captures late messages delivered during DNS propagation, gives time for final delta syncs, and lets staff recover anything missed. Run a final export before cancelling, and check the old contract renewal date so the account does not renew automatically.
How do I migrate email without breaking my website?
Migrate email without breaking your website by changing only the MX, SPF, and DKIM records and leaving nameservers and A records unchanged. If nameservers must change, recreate every mail and website record in the new DNS zone first. Also update website contact forms that send through the old host’s SMTP server.
What is the best time to migrate business email?
The best time to migrate business email is a low-traffic window such as a Friday evening or a weekend. Avoid month-end invoicing, payroll dates, and product launches. Lower the MX record TTL 24 to 48 hours earlier, and announce the date to staff at least 1 week ahead through a trusted internal channel.