How to Migrate Business Email: A Practical Plan

Business email migration consists of two separate processes that should be planned together. One changes the route for new incoming mail through MX. The other copies historical messages and folders from the old mailboxes. Change only DNS, and new messages reach the new server while years of history remain behind.

A sound migration does not begin by deleting old records. First gather information, prepare new mailboxes, and test access. Then perform a controlled switch, keep both environments available for a period, and retire the old service only after acceptance. No process removes every risk, but this sequence makes risks visible and reversible.

Define the scope and success criteria

Create an email register before technical work. For every address, record its owner, type, approximate size, important folders, and access method. Include shared addresses such as info@, aliases, groups, technical senders, and former employees whose messages must be retained.

A useful table contains at least:

Agree in advance what “accepted” means: all listed addresses can receive and send test messages, owners can see critical folders, public DNS matches the plan, and the old service remains available through the observation period.

Do not define success as “no message can ever be lost.” One test cannot prove that promise. A practical standard is successful control scenarios, a migration error log, and an intact source environment to consult if something differs.

Audit the existing configuration

Save current MX, SPF, DKIM, DMARC, and their TTL values as text or a zone export—not only screenshots. Exact previous values are essential if a serious issue requires rollback.

Identify all systems that send on behalf of the domain, including:

• website contact forms;
• CRM and invoicing systems;
• application notifications;
• bulk or transactional mail services;
• scanners and other office devices.

Every legitimate source must be represented in the new authentication design. Do not replace SPF with only the new email provider and forget existing services. Do not leave several separate SPF records either, because that produces an error.

Verify where DNS is actually managed. Registrar access is not enough if the zone is delegated to other name servers. See the MX record guide and SPF, DKIM, and DMARC for roles and common mistakes.

Prepare the new environment before switching

Create every mailbox, alias, and group from the register. Include account-recovery addresses and old public contacts, not only current employees. Give each user separate credentials.

Test webmail, IMAP, and SMTP before changing MX. Configure email applications as an additional account without removing the old one, allowing users to see both environments during transition and compare folders.

The new provider supplies MX, SPF, DKIM, and DMARC values at this stage. Verify names, record types, and priorities. Do not tighten DMARC blindly; first ensure every real sender passes SPF or DKIM with the required domain alignment.

With Mailcore, a specialist guides this work: we agree the mailbox list, prepare records, and create a separate archive-migration plan before changing the route. The full process is described in how Mailcore connects a domain.

Copy the archive over IMAP

IMAP works with server-side messages and folders, so it is commonly used to migrate between providers. IMAP availability does not mean all data appears identically, however. Contacts, calendars, filtering rules, signatures, and local client archives may live separately and require another method.

Before copying, check:

1. IMAP access on both sides;
2. passwords or application-specific passwords;
3. enough capacity in the new mailbox;
4. folder names and encodings;
5. connection and rate limits;
6. local folders that do not exist on the server.

A two-pass synchronization suits active mail. Copy most data while MX still points to the old server. After switchover, run a final pass for messages received during transition. This reduces migration-day work.

Speed depends on message count, attachment size, server limits, and connectivity, so a 500 MB mailbox and a multi-gigabyte archive cannot share one promised duration. Keep an error log and verify by folders; total bytes alone do not prove a complete migration.

Read how IMAP and SMTP are used for the protocol roles. SMTP sends messages and does not copy an archive.

Switch MX during an agreed window

Choose a time when the administrator and several users can test. Confirm that new mailboxes work, current records are saved, and the old server will not shut down automatically after the change.

Because DNS is cached, senders may see the new value at different times and messages can reach either environment during transition. Lowering TTL in advance shortens the lifetime of future answers but does not remove data from existing caches.

After publishing the new MX set, query independent DNS resolvers, then:

• send from an external service to several domain addresses;
• reply through the new webmail;
• repeat sending through a configured SMTP client;
• inspect Inbox, Sent, and Spam;
• examine SPF, DKIM, and DMARC results in headers;
• confirm that old mailboxes remain accessible.

Correct DNS and a successful reply establish the technical delivery path. Recipients still apply their own filters and reputation signals. Use the deliverability checklist if problems arise, changing one parameter at a time.

Prepare a rollback plan

A rollback plan does not predict failure; it prevents recovery from relying on memory. Include the old MX records, the person responsible for changes, rollback conditions, and the user communication channel.

Rollback is justified for a systemic issue—for example, most agreed mailboxes cannot receive, users cannot sign in, or external sending fails in the required scenario. One message in spam is not always a reason to revert DNS; inspect headers and logs first.

If the old route is restored, do not clear the new server. It may contain messages received during the test, which must be synchronized back or preserved separately. Record actions and times to reconstruct the sequence.

Accept the migration before retiring old email

Run the final IMAP synchronization after the route stabilizes. Ask owners to inspect important folders and search older messages, paying particular attention to custom folders, large attachments, and the period around the MX change.

Retire the old service only when all conditions are true:

1. public DNS records are stable;
2. incoming and outgoing correspondence has been tested;
3. owners have confirmed the agreed archives;
4. migration errors are resolved or documented;
5. local data, contacts, and calendars are preserved separately;
6. the agreed observation period has passed.

Until then, the old server is a useful safety net and verification source—not waste to remove immediately. Independent backup or long-retention requirements need their own design and a real restore test. IMAP migration is not a backup system.

A short, repeatable sequence

The migration can be summarized in seven actions: inventory, save current DNS, create new mailboxes, perform the first copy, switch MX in an agreed window, run final synchronization, and accept the result. Skipping any step transfers the risk to users.

Without mail history, the process is simpler: prepare mailboxes, records, and tests using the general domain email setup guide. With archives, budget separate time for them and do not confuse copying progress with route change.

The central principle is reversibility. While source settings are saved and the old environment remains available, the team can verify and correct discrepancies without panic. That is more useful than any promise of a “one-click migration.”

Sources

• RFC 9051: Internet Message Access Protocol
• RFC 5321: Simple Mail Transfer Protocol
• RFC 7208: Sender Policy Framework
• Google: Email sender guidelines
• Microsoft Learn: Email authentication