Introduction

When an IMAP client starts downloading the entire mailbox again after a migration, the problem is usually not that all mail is duplicated on the server. In most cases, the client no longer recognizes the migrated mailbox as the same mailbox it synced before. UID values changed, folders were recreated, namespace behavior changed, or the local cache no longer matches the server state. Treat this as a mailbox identity and sync-state problem, not a generic bandwidth or mail delivery problem.

Symptoms

  • Outlook, Thunderbird, Apple Mail, or a mobile client starts downloading old mail again after migration
  • The mailbox appears to re-sync from the beginning even though messages already existed locally
  • Duplicate local messages or duplicate folder counts appear after the move
  • Only some folders re-download while others remain normal
  • The problem starts immediately after mailbox migration, server replacement, or profile reconnect
  • The server mailbox looks correct, but one or more clients behave as if it is brand new

Common Causes

  • The migration changed IMAP UID validity or message UIDs, so the client treats the mailbox as new
  • Folders were recreated instead of preserved, breaking the sync relationship to the old mailbox state
  • The destination server uses a different namespace, delimiter, or folder mapping than the source server
  • The mail client profile or local cache became inconsistent during reconnect after cutover
  • The mailbox was imported in multiple passes, making the final server state look different to the client
  • A partial sync issue on one client is being mistaken for a mailbox-wide server problem

Step-by-Step Fix

  1. Confirm whether the server mailbox actually contains duplicate messages or whether only the client is re-downloading existing mail, because the fix is different for a client cache problem than for a bad migration import.
  2. Test the same mailbox in webmail or a second clean IMAP client before changing the server, because if the mailbox looks normal there, the existing client profile is usually the main problem.
  3. Check whether the migrated mailbox preserved folder structure cleanly or whether folders were recreated on the destination, because recreated folders often trigger clients to treat the mailbox as a new sync target.
  4. Review the migration method and server change for anything that would alter UID validity, message IDs, or folder identity, because IMAP clients rely on that metadata to continue an existing sync instead of starting over.
  5. Compare behavior across multiple devices using the same mailbox, because one misbehaving desktop profile does not prove the server migration itself is wrong.
  6. Reset or rebuild the local mail cache only on the affected client if the server mailbox is healthy, because stale local state is one of the most common reasons a client re-downloads everything after reconnection.
  7. Verify namespace and special folder mapping on the destination server, because a change in folder path behavior can make clients believe old folders disappeared and new ones appeared.
  8. Watch for repeated imports, duplicate migration passes, or ongoing sync tools still touching the mailbox, because a mailbox that keeps changing during cutover can trigger clients to re-evaluate the whole sync set.
  9. Once the mailbox is stable, reconnect one clean client profile and let it finish syncing before restoring other devices, because that confirms whether the problem is resolved at the mailbox level or still isolated to legacy local profiles.