Email Migration: Moving Mailboxes to a New Provider Without Losing Messages

The host is too slow, support does not respond, prices have gone up — the decision to switch is made quickly. And then everything stays as it is. Not because of the website: that migrates in an afternoon. It is the mailboxes. They hold years of correspondence, often in folder structures that have grown organically, and you get exactly one attempt. This guide explains how an email migration works technically, in what order the steps must come, and where the two traps lie that actually break most migrations.

Why a mailbox is not a folder

The obvious idea — "I will just copy the emails across" — assumes that a mailbox is a collection of files. It is not. An IMAP mailbox lives on the provider's server, and your email program only shows a view of it. Besides the actual text, every message carries information that is easy to overlook:

• The folder it sits in — including subfolders of any depth.
• Status flags: read, unread, replied, flagged, draft.
• The server's received date, which can differ from the date in the message header.
• Attachments in their original encoding.

A migration that transfers only the message text produces a mailbox where everything sits unread in the inbox. Technically nothing is lost — practically, ten years of filing is destroyed.

The two traps that migrations fail on

Trap 1: The gap at cutover

The most common real data loss happens not during copying but during the switch. When you point your domain's MX records at the new server, the change does not take effect instantly: DNS responses are cached, and how long they are cached is determined by what is called the TTL. If it is set to four hours, some mail servers keep delivering to the old provider for up to four hours, even though you switched over long ago.

Anyone who copies during this window and then stops checking loses exactly the messages that trickle into the old mailbox in the meantime. There are rarely many, but it is Murphy's law: it is the one order you were waiting for.

The solution is unspectacular: lower the MX record's TTL to 300 seconds a day before the migration, then switch over and run a follow-up sync on the old mailbox one or two days later. A proper migration tool recognises what has already been transferred and only fetches the stragglers.

Trap 2: The mailbox was never fully on the computer

Anyone who has fetched their mailbox via POP3 rather than IMAP for years may have all the messages locally in the program, with almost nothing left on the server. The reverse happens just as often: the email program is set to load only the headers, or only the last twelve months. Either way, you only notice once something is missing after the migration.

So check beforehand how many messages are actually on the server. A migration tool that counts before transferring answers that in a minute. The number should match what you expect. If it is far off, find out why before you cancel anything.

Three ways to migrate a mailbox

Method 1: By hand in the email program

Set up both accounts in Thunderbird or Outlook, select folders, drag them into the new account. It works, and it costs nothing.

What it suits: a single, manageable mailbox.
Where it struggles: the computer has to stay running throughout, and the transfer goes through your internet connection — down once, up once. With several gigabytes, that becomes a day's work. If it breaks off, the state is unclear: some has transferred, some has not, and a second attempt easily creates duplicates. Status flags survive or do not, depending on the program.

Method 2: Export and import via files

Export the mailbox as a PST or MBOX file, import it at the new provider. Sounds clean; rarely is: the formats represent folder structures differently, special characters in folder names do not always survive the trip, and on import everything tends to land in one flat list. As a backup before the migration, an export makes sense — as a migration method, it is the worst of the three.

Method 3: Directly from server to server

A tool logs in to both mailboxes and copies folder by folder directly between the servers. Your computer is not involved and can stay switched off. The folder tree, status flags and attachments are preserved because both sides speak the same protocol.

The decisive advantage lies elsewhere, though: such tools work incrementally. They use each message's unique identifier to recognise what is already at the destination and skip it. So a second run does not duplicate anything; it only fetches what has changed since the MX cutover.

What matters here is the mode: a good migration copies; it does not move. Nothing on the old server is deleted or changed. That means there is never a point where your emails exist in only one place. If something goes wrong, the original is still there.

The right order

Almost all avoidable mishaps happen because two of these steps get swapped:

1. Create the destination mailbox. Set up a mailbox for every address at the new provider. No migration tool creates email addresses — it only writes into existing ones.
2. Count and check. Test the connection to both sides, count folders and messages. Does the number match what you expect?
3. Lower the TTL. A day beforehand, set the MX record's validity period to five minutes.
4. Copy. The actual transfer run. Mail traffic keeps flowing completely normally throughout — nobody notices a thing.
5. Spot-check. Set up the new mailbox in your email program and look into the old folders. Are the attachments there? Do the dates match?
6. Switch the MX record. Only now does the domain point to the new server.
7. Run a follow-up sync. Run it again one or two days later — that fetches everything that still arrived at the old provider during the transition period.
8. Cancel. Right at the end, not before. One month of paying twice is cheaper than a lost mailbox.

Special cases worth knowing beforehand

Gmail and Google Workspace

Google requires an app password for IMAP access; the ordinary account password is rejected. It can only be generated if 2-step verification is enabled (Account → Security → App passwords). On Workspace accounts, administrators can additionally block app passwords.

The second peculiarity is the label system: in Gmail a message does not have folders, it has labels, and over IMAP it appears again in every label folder. Archived messages, in turn, carry no label at all and sit exclusively in the "All Mail" folder. Anyone who leaves this folder out of the migration (a common recommendation to avoid duplicates) may thereby leave behind most of the mailbox. A tool that understands Gmail detects duplicate occurrences itself and does not need that exclusion.

Microsoft 365 and Outlook.com

Here too an app password is required. In addition, IMAP access has to be permitted for the tenant at all: many organisations have turned it off. That is your administrator's decision, not the migration service's. Clarify this before the appointment, or the migration will stall before it starts.

Calendars, contacts and aliases

Calendars and address books do not live in the IMAP mailbox but in separate services (CalDAV, CardDAV, or Exchange at Microsoft). They are not carried across in an email migration and need their own export. Alias addresses and forwarding rules do not move automatically either. You set those up again at the new provider. Note both down beforehand.

How long a migration takes

There is no credible figure in minutes, and anyone who gives you one is guessing. Duration depends on three things: the volume of data, the number of messages (many small ones take longer than a few large ones) and, above all, how willing both servers are to cooperate.

The last point is the most important one. Google and Microsoft noticeably throttle IMAP access to protect their systems. A private mailbox of a few hundred megabytes is often transferred there in minutes; a business mailbox that has grown to several gigabytes needs hours, in individual cases half a day. That is normal and not a sign of a problem. Traditional hosts such as IONOS, Strato or All-Inkl are usually considerably faster.

The practical consequence: do not schedule the migration for the last hour before your contract ends. And choose a method that runs server-side: then it does not matter whether it takes two hours or eight, because nobody has to sit and watch.

What an email migration costs

For a single mailbox, common self-service tools charge between €10 and €15; some providers have a free tier for small mailboxes. If you commission a service provider to handle the entire switch including the DNS cutover, the price depends on the number of mailboxes and the amount of consulting involved.

At PixAgentur, a mailbox up to 3 GB is free; larger mailboxes are unlocked with a one-off payment of €12.90, no subscription and no registration. If you would rather hand off the entire switch, including setup at the new provider and the delicate MX cutover, enquire about the assisted migration. For hosting customers, transferring existing mailboxes is included at no extra charge.

The most common mistakes in brief

• Cancelled too early. The contract expires while the migration is still running — the source mailbox is gone.
• No follow-up sync. Everything copied, MX switched, done. The messages from the transition window are gone for good.
• Only half checked. Looked in the inbox after the migration, but not in the old subfolders.
• Aliases forgotten. The main address works, but info@ and accounts@ go nowhere.
• No safety net. Chose a method that deletes or moves items in the source mailbox. Copying is always the safe approach.

Conclusion

An email migration is not rocket science, but it does not forgive the wrong order of steps. Anyone who creates the destination mailbox beforehand, copies instead of moving, syncs a second time after the MX cutover, and cancels only at the very end has ruled out the three realistic sources of loss. The rest is waiting time. It is best spent not in front of the screen, but left to the server to handle.

If you would like to handle it yourself: the PixAgentur email migration guides you through the process in five steps, counts folders and messages beforehand, and shows progress live. The connection test costs nothing and tells you within seconds whether both sides are reachable.