Migrating IMAP and Legacy Email Systems to Microsoft 365

Not every migration starts from Exchange or Google Workspace. A large share of the businesses we move are on something older or odder: mail hosted by their web hosting company on a cPanel server, a hosted email provider that has announced it is shutting down, an ancient in-house server running Zimbra or a Linux mail stack, or a mix of POP accounts that has grown by accretion since the early 2000s. The common thread is IMAP, the decades-old protocol nearly every mail system speaks, and it is both the reason these migrations are possible and the reason they need more planning than people expect.

The one sentence that shapes the whole project

IMAP migration moves mail, and only mail. No calendars, no contacts, no tasks, no distribution lists, no auto-replies, no server-side rules. The protocol simply has no concept of those things, so no IMAP-based tool, Microsoft's included, can carry them. Every IMAP migration is therefore really two projects: a mail copy that tooling handles well, and a manual workstream for everything else. Companies that discover the second project after cutover have a bad week. Companies that plan it barely notice.

How the mail copy works

Microsoft 365 includes IMAP migration natively: from the admin tooling you point it at the source server, supply credentials for each mailbox (or admin credentials where the source supports impersonation), and it copies folders and messages into already-created Exchange Online mailboxes in batches. Because the copy runs while the source stays live, the standard pattern is the same pre-stage-then-cutover rhythm we use everywhere:

1. Create the target first. Unlike some migration paths, IMAP migration copies into mailboxes that already exist, so users are created and licensed in Microsoft 365 up front, with the domain verified while MX still points at the old host.
2. Initial sync. The bulk of every mailbox copies across over hours or days. Legacy hosts are often the bottleneck: shared hosting providers throttle IMAP connections aggressively, and a mailbox with 200,000 messages in one folder tests everyone's patience.
3. Incremental passes. The tooling re-syncs new mail periodically, keeping the target close to current while users keep working on the old system.
4. Cutover. MX records flip to Microsoft 365, a final delta sync catches the stragglers, and the batch is deleted, ending synchronization. From that moment the old server is history.

Practical limits apply: items over the configured Exchange Online message size ceiling are skipped rather than migrated, folder names with characters Exchange dislikes get adjusted, and some servers expose folders (like a webmail client's internal folders) that deserve filtering out rather than copying. Our post on mailbox and item limits covers the size rules in detail, including why the skipped-item report matters.

The second project: everything IMAP leaves behind

Here is the gap inventory we walk through for every legacy migration, because each item needs an owner and a plan:

The last row is the one that bites hardest. The old hosting account did not just receive mail; it relayed it, for the office scanner, the website's contact form, the backup job notifications. Those senders fail quietly at cutover, and nobody notices until an invoice reminder never goes out. A proper discovery pass finds them by combing the old server's logs before anything is switched.

POP accounts: the special case

POP is worse than IMAP for migrations, because POP clients typically downloaded mail and deleted it from the server. The server-side mailbox for a longtime POP user is often nearly empty, and the real history lives in a local file on their machine. IMAP-based migration copies what the server has, so POP environments need the local stores identified and imported separately, machine by machine. It is tedious, it is entirely doable, and it must be scoped up front, because it changes the effort estimate more than any other single factor in legacy migrations.

Cutover care for old DNS

Legacy hosting setups add DNS wrinkles worth respecting. MX records sometimes point at hostnames tangled up with the website's hosting, so moving mail without breaking the site takes care. TTLs are often set to a day or longer and should be lowered ahead of cutover so the switch propagates quickly. SPF records referencing the old host need rewriting, and DKIM signing, which many legacy hosts never had, should be set up fresh in Microsoft 365 along with a DMARC policy. Getting authentication right at cutover means your first week of mail from the new system lands in inboxes, not spam folders.

Why bother, beyond the shutdown notice

Many legacy migrations are forced (the provider is closing, the server is dying), but the destination is an upgrade even when the move is voluntary: mailboxes measured in tens of gigabytes instead of the old host's 2 GB caps, real shared calendars and contacts at last, modern authentication with MFA instead of a plain password on port 143, and a platform that gets patched without anyone driving to an office. The follow-on question of keeping that platform healthy is its own topic; see why managed Office 365 matters after the migration.

What a specialist changes

An IMAP migration looks simple in the admin center, and the mail-copy half mostly is. The value of a migration partner is the other half: the gap inventory done before cutover instead of after, the sender audit that finds the scanner and the web form, the POP local stores scoped into the plan, the throttled source server scheduled around realistically, and DNS switched in the right order with authentication ready. If your legacy environment sits alongside a Google tenant or an old Exchange box, we run those paths too; see the Google Workspace guide for that side of the house.