cPanel Migration: Wrong Email Dates

The Monday morning that hurts

You just finished migrating a shared cPanel hosting account to Google Workspace or Microsoft 365. Everything went smoothly, mailboxes are accessible, users are logging in. Then, around 9:15 AM, the first ticket arrives: "All my old emails show the same date, last weekend." Then a second one. Then ten.

This isn't an isolated bug. It's the direct result of how cPanel migrations handle (or rather don't handle) email date metadata.

cPanel, Roundcube, Horde: a specific IMAP context

A shared cPanel hosting environment is a Linux server running an IMAP server (typically Dovecot) with Roundcube or Horde as the webmail interface. Nothing exotic about that. But this context has a few quirks that make migrations to enterprise platforms trickier than they appear.

For one, cPanel mailboxes tend to accumulate emails over years, sometimes a decade. A client who's been hosting their domain on shared hosting since 2013 can have very deep archives. That volume, combined with how the migration gets executed, creates fertile ground for the date problem.

On top of that, the tools used for these migrations are often either the native cPanel tool (WHM's "Migrations" feature), imapsync run from the command line by the hosting provider or IT consultant, or consumer-grade solutions like GSMMO for migrating to Google Workspace.

Why dates get corrupted after a cPanel migration

To understand the problem, you need to grasp two distinct concepts: the Date: header in an email and the IMAP INTERNALDATE.

The Date: header is written into the raw message body at the time of sending, per RFC 2822. It records when the email was composed and sent. This header never changes unless someone deliberately alters the message.

INTERNALDATE, on the other hand, is a piece of metadata that the IMAP server associates with each stored message. It's separate from the message content itself. When an email arrives normally on a server, INTERNALDATE is derived from the Received: headers, or from the deposit timestamp if the message is submitted directly. This is the value that Outlook, Thunderbird, and most email clients use to sort messages.

During an IMAP migration, messages are copied from one server to another. The problem: the migration tool has to create each message on the destination server. And for many tools, the INTERNALDATE of the newly created message is set to the migration date, not the original message date. On top of that, a Received: header timestamped to the migration date gets prepended to the header chain, which further confuses email clients that rely on it to calculate the display date.

The result: a 2019 email lands on Google Workspace with an INTERNALDATE set to the day of the migration, and a Received: header stamped yesterday. Outlook displays it in the inbox as if it just arrived. The entire archival timeline is destroyed.

The WHM / cPanel migration tool

The tool built into WHM for migrating cPanel accounts to another platform generates this problem almost systematically when the destination is an external IMAP server (Google Workspace, Microsoft 365). It copies Maildir content to the new server without preserving the original INTERNALDATE. Every message gets the timestamp of the operation.

imapsync and manual migrations from cPanel

imapsync is a powerful tool, but its default behavior doesn't always preserve dates. Without the right parameters (and the right version), it can easily copy 40,000 messages and stamp every single one with the script's execution date. (If you've ever gone through imapsync logs line by line to diagnose a date problem on a 25,000-message mailbox, you know it's an experience you don't want to repeat.)

To be precise, imapsync does have options to attempt date preservation, but those options interact differently depending on the source and destination servers, and their effectiveness isn't guaranteed across all cPanel / Dovecot configurations.

GSMMO and consumer-grade tools

Google Workspace Migration for Microsoft Outlook (GSMMO) is designed to migrate from Outlook, not from a bare IMAP server. When it's used to migrate from cPanel (via an IMAP account configured in Outlook), dates get the same treatment: INTERNALDATE on Google Workspace is set to the migration date. The GSMMO email date problem is actually documented separately, it's that common.

Which email clients are affected?

Date corruption doesn't show up the same way in every client.

Outlook is the worst affected. It uses INTERNALDATE (or the migration Received: header) as its primary sort key for folders. After a poorly handled cPanel migration, an Outlook mailbox can show thousands of archived emails with the migration weekend's date. Fixing imapsync migration dates in Outlook is one of the most requested corrections.

Gmail (Google Workspace) generally displays the date from the Date: header in the email list, but sorting can still be affected by INTERNALDATE in some cases. Users report erratic behavior in search and date-based sorting.

Apple Mail and Thunderbird behave more inconsistently, but neither is immune, especially when a migration Received: header is sitting at the top of the header chain.

Good news: the original date is still there

This is the technical detail that changes everything. The original Date: header is written into the raw message body. The migration doesn't touch it. When you open an affected email and look at the raw headers (in Gmail: "Show original", in Outlook: File > Properties), you can see the original Date: intact, followed by one or more Received: headers where the first one carries the migration date.

That information is still there. It can be used to correct the metadata. That's exactly what Redate.io's correction engine does.

Why "just fixing it yourself" is riskier than it looks

The temptation is real. The problem seems simple: read the original date, correct the metadata, move on. But there's a significant gap between understanding the mechanism and correcting 12,000 production emails without losing a single one.

A few realities that homemade scripts typically don't account for:

S/MIME signed or PGP encrypted emails: any modification to the message structure invalidates the cryptographic signature. An email that passed signature verification before correction won't after. Users in regulated environments (law firms, financial sector, healthcare) discover this problem at the worst possible moment.
Non-ASCII headers and RFC 2047 encoding: cPanel mailboxes accumulate years of emails from very diverse clients. Some headers contain characters encoded per RFC 2047. A poorly written script that reconstructs headers can silently corrupt those encodings.
Nested MIME structures: an email with three attachments and an alternative HTML body has a complex multipart structure. The slightest error on MIME boundaries makes the message unreadable, or worse: attachments disappear with no error message.
API quotas and rate limiting: Google Workspace and Microsoft 365 enforce strict limits on IMAP operations per minute. A script that doesn't implement proper exponential backoff will hit 429 errors at 3 AM, and you'll wake up to a half-finished migration with no clear idea of where it stopped.
No rollback: if something goes wrong halfway through, what state do you return to? Are the originals still there? Do you have duplicates? Redate.io keeps originals in a visible backup folder for 30 days, precisely to avoid ever being in that situation.

A script that works on 50 test emails in a dev environment won't necessarily hold up against 18,000 messages in a production mailbox inherited from a cPanel account running since 2011.

How Redate.io corrects dates after a cPanel migration

Redate.io connects directly to the destination mailbox (Google Workspace via domain delegation, Microsoft 365 via Azure AD, or direct IMAP) and starts with a free scan to identify emails whose date metadata is inconsistent with the original Date: header.

The multi-stage analysis pipeline then applies pattern matching against Received: header signatures to identify those introduced by migration tools (and distinguish them from legitimate headers). Targeted metadata correction is applied without altering message content: body text, attachments, original headers, everything stays intact. Each corrected email is verified individually before the operation is confirmed.

For cPanel migrations specifically, the engine recognizes the typical signatures of Dovecot-to-IMAP migrations and imapsync scripts, including configuration variants common among shared hosting providers.

Specific guides by destination platform

Depending on where your cPanel migration landed, these guides cover the exact steps:

Migrated from cPanel and your users are seeing wrong dates? Run a free scan on Redate.io to find out exactly how many emails are affected, with no changes made until you approve.

Wrong Email Dates After cPanel Migration