How to Migrate Email via IMAP Without Losing Mail
A mailbox move should not require abandoning ten years of receipts, client threads, and the folder structure that makes them findable. To migrate email via IMAP, you copy messages directly between two mail servers while keeping the original account intact until the new one is proven. It is the most practical migration path for standard email hosts because IMAP is built for mail access and folder synchronization, not vendor lock-in.
That does not make every move identical. A one-person mailbox with 2 GB of mail can finish quickly. A team with years of attachments, nested folders, shared addresses, and active inbound mail needs a cutover plan. The good news is that the plan is usually simpler than changing providers makes it sound.
What an IMAP email migration actually copies
IMAP migration reads mail from the old server and writes it to the new server. In a normal move, that includes messages, folders, subfolders, sent mail, drafts, timestamps, read status, and attachments. It can preserve a surprisingly large archive without exporting PST files or dragging folders through a desktop app.
It does not copy everything associated with an email account. Contacts, calendars, browser autocomplete entries, desktop-client settings, signatures, server-side filters, forwarding rules, vacation responders, and user permissions generally need separate handling. If you use aliases or a catch-all address, recreate those at the destination before changing DNS.
The distinction matters. IMAP is a mail migration protocol, not an account-cloning protocol. Treat the mail archive and the mail configuration as two related projects.
Start with an inventory, not a DNS change
The easiest way to create a stressful migration is to point MX records at a new host before mailboxes exist there. Start by writing down what the current service actually handles.
For a small organization, that means every mailbox, alias, forwarding address, distribution address, catch-all rule, and domain. Also identify which addresses receive important automated mail: invoices, password resets, monitoring alerts, form submissions, and registrar notices. These are often the addresses people forget until something fails.
Check storage before you begin. A source mailbox may show less mail than you expect because deleted items, spam, archives, or sent folders are hidden from the main quota view. The destination needs enough capacity for the copied mail, plus room for incoming mail after the switch. At FranklyMail, storage is pooled rather than assigned per seat, so a large archive in one mailbox does not force you into a higher per-user tier. But capacity is still capacity - measure it before copying.
You should also record the source provider's IMAP server name, port, encryption method, username format, and authentication method. Most standard providers offer IMAP over TLS on port 993. Some require an app password when two-factor authentication is enabled. Do not turn off two-factor authentication just to migrate mail. Generate a limited app password if the provider supports it, then revoke it after the move.
Prepare the destination before you copy
Create destination mailboxes first. Match the source addresses where possible, then add aliases and forwarding rules. If multiple people receive mail at one address today, decide whether that address should become an alias, a shared workflow handled by forwarding, or separate copies delivered to individual mailboxes.
This is also the right time to clean up old habits. You may not need the twenty aliases created for abandoned projects, but do not delete an address that still receives account-recovery mail. Keeping an alias costs less than missing a legal notice or a customer inquiry.
Verify the destination domain's DNS records before cutover. At minimum, that means MX records for receiving mail and SPF, DKIM, and DMARC for authentication. DNS changes can take time to propagate, and some resolvers hold old data longer than expected. A host that shows live DNS verification is useful here because it distinguishes a record that looks right in your registrar dashboard from one that is actually visible on the internet.
Do not remove the old service yet. Keep it active through the migration and for a short overlap period after DNS changes. That is not wasteful duplication. It is inexpensive insurance against delayed DNS, forgotten aliases, and a source folder that was skipped in the first run.
How to migrate email via IMAP safely
A reliable IMAP migration is usually done in two passes. The first pass copies the historical archive while the old account remains live. The second pass catches messages that arrived during the first copy, just before or shortly after DNS cutover.
Begin with one mailbox as a pilot. Choose an account with a representative amount of mail and a normal folder structure, not necessarily the largest mailbox. Confirm that the migration tool can log in to both sides, sees the expected folders, and copies messages into the right destination folders.
After the first pass, inspect more than the total message count. Open several old messages with attachments, check Sent and Archive folders, and search for a few known subjects. Confirm that nested folders did not flatten into a single folder and that spam or trash was included only if you intended to preserve it.
Then run the same process for the remaining mailboxes. Large archives may take hours or days depending on mailbox size, server limits, and the number of simultaneous migrations. More parallel jobs are not always better. Source providers may throttle IMAP connections, and aggressive copying can trigger security controls. A slower migration that completes cleanly is better than a fast one that requires repairing thousands of missing messages.
When the first pass is complete, change the MX records to the new provider's values. Keep the source account available. New mail will gradually begin arriving at the destination as DNS caches expire, while some senders may still use the old route for a period.
Run an incremental IMAP pass after the MX change. This copies messages received at the old service during the overlap. If your migration tool can safely skip messages already copied, it should only transfer the difference. Once inbound delivery has been stable and you have checked the important addresses, you can retire the old service.
Common migration problems and what they mean
Authentication failures are usually credential problems, not bad mail data. Confirm the exact IMAP username and whether the provider requires an app password. Some providers restrict password-based IMAP migration or require their own export and authorization process. Microsoft 365 and Proton, for example, can impose limitations that make a standard username-and-password IMAP copy less straightforward. Check the provider's current migration options before setting a cutover date.
Missing folders often come down to folder subscriptions, special-use folders, or localized names. One provider may call a folder Sent, another Sent Items, and another may expose it in a different language. A good migration process maps folders deliberately rather than assuming every name means the same thing.
Duplicate messages can occur if a migration is restarted without proper state tracking. This is annoying but less dangerous than missing mail. Use a tool that reports its progress, preserves logs, and supports incremental syncing. Do not repeatedly rerun a full copy without understanding how it identifies messages.
Messages arriving at both providers for a short period are normal during DNS propagation. The risk is not duplicate delivery by itself. The risk is assuming the switch is complete too early and canceling the old service before all routes have updated.
Verify the move from the outside
Internal checks are useful, but external testing catches the mistakes that matter. Send messages to each primary address from an unrelated account. Reply from the new mailbox. Test aliases, catch-all behavior, forwarding, and any address used by automated systems.
Look at the message headers for a test email if you know how. They can confirm that the message was received by the new infrastructure and authenticated correctly. If you do not inspect headers, at least confirm that messages are landing in the intended mailbox rather than disappearing into a spam folder or an old forwarding rule.
Keep a short written checklist for the first week: incoming mail, outgoing mail, mobile client access, webmail access, aliases, and critical third-party accounts. Email is basic infrastructure. The migration is done when it is boring again.
A good provider makes leaving possible, not painful. IMAP is valuable because it keeps your archive portable: you can copy it to a new service later without asking permission or rebuilding your history from scattered exports. Set up the move carefully, keep the old account until the evidence says you are safe, and let standards do the work.