Shared Hosting to Microsoft 365: The Hidden Date Problem

The problem nobody warned you about

You just finished migrating your mailboxes from OVH, Infomaniak, Ionos or o2switch to Microsoft 365. The EAC (Exchange Admin Center) migration wizard ran all night, everything shows green, mailboxes are full. Monday morning, first ticket: "All my old emails show today's date." Then a second. Then ten.

This isn't a Microsoft 365 bug. It's not a coincidence either. It's the mechanical result of an IMAP migration, and with shared hosting providers, the problem is often twice as bad as in a standard migration. Here's why.

How IMAP handles dates (and where things go wrong)

Every email stored on an IMAP server has two distinct types of dating. On one side, the Date: header (defined by RFC 2822), embedded in the message body itself, indicating when the message was sent or received. On the other, the INTERNALDATE, a server-level metadata value indicating when that message was deposited into the mailbox. This is the value email clients like Outlook use by default to sort and display messages.

(If you've ever tried reading raw email headers in the EAC, you know it's not exactly beach reading. There are easily twenty to thirty header lines before you get to any actual content.)

When an IMAP migration tool transfers a message from one mailbox to another, it has to recreate that INTERNALDATE on the destination server. Some tools do this correctly. Many don't, or do it with significant limitations. The receiving server, for its part, keeps what it's given: when a copy carries its original date, Exchange Online keeps that date. So when dates come out wrong, the tool is the one to look at, not Microsoft 365.

The result: every migrated email appears to have been "received" on the day of the migration. Doesn't matter if it was sent back in 2019.

The two-stage scenario: why shared hosting makes everything worse

This is where things get genuinely messy for migrations from shared hosting providers like OVH, Infomaniak, Gandi, Ionos or o2switch.

These providers typically run shared Postfix, Dovecot or cPanel servers with standard IMAP configurations. Many small businesses have accumulated years of email there, sometimes going back to 2010 or 2012. When they decide to move to Microsoft 365, the migration often happens in two stages.

Stage 1: the first corruption (before Microsoft 365 even enters the picture)

In many cases, those emails have already been through one migration before. The company switched shared hosting providers once or twice over the years: from Gandi to OVH in 2018, then from OVH to Infomaniak in 2022, for example. Each IMAP transfer could have reset the original INTERNALDATE to the day of the transfer (whenever the tool didn't pass the original date), and some tools also leave migration headers of their own, dated that day.

By the time those emails arrive at Microsoft 365, they're already carrying scars. The original Date: header is intact (it's part of the message body, nobody touches it), but the date metadata has already been disrupted once.

Stage 2: the second corruption when moving to Exchange Online

The EAC's IMAP migration tool, or a third-party tool like BitTitan MigrationWiz running in IMAP mode, then ingests these already-damaged emails. If that tool doesn't pass each email's original date either, Exchange Online files the email under the day of the transfer, and that's the "received date" Outlook ends up showing.

An email sent in March 2017 can end up carrying two layers of wrong dates: migration headers left by the 2022 move, and a received date from the 2024 migration to Microsoft 365. Outlook shows 2024. The user sees 2024. That's wrong on two separate levels.

Actually, to be precise: Outlook determines the displayed date from a combination of the INTERNALDATE Exchange Online recorded and the headers present. But whenever the migration tool doesn't pass the original dates, the move to Exchange Online adds a fresh layer of errors on top of the old one.

Migration tools and hosting providers: the risky combinations

A few combinations come up constantly in shared hosting migrations:

• OVH / Infomaniak / Ionos + EAC IMAP tool: Microsoft's native tool is convenient but well-known for not preserving dates correctly during high-volume IMAP migrations.
• cPanel (o2switch, LWS, etc.) + BitTitan MigrationWiz in IMAP mode: MigrationWiz in IMAP mode adds its own migration headers. The results are documented, among other places, on the fix BitTitan migration dates in Microsoft 365 page.
• Gandi / Mailcow + imapsync: imapsync is a powerful tool, but its INTERNALDATE handling depends entirely on configuration. Without the right option, dates aren't preserved. See also imapsync: dates not preserved.
• Any manual drag-and-drop migration in Outlook: if someone copied entire folders by dragging between two accounts configured in Outlook, the INTERNALDATE of every single email gets rewritten to the copy date. No exceptions.

The common thread: all of these methods result in Exchange Online mailboxes where the date displayed in Outlook no longer corresponds to anything real.

Why "just fix it yourself" is a bad idea at scale

Understanding the problem is one thing. Correcting 8,000 emails spread across 40 Exchange Online mailboxes, with complex folder structures, S/MIME signed messages, large attachments and nested conversation threads, is another thing entirely.

A PowerShell script that seems to work on ten test emails can silently fail on message number 4,237 because of a corrupted MIME boundary or a header encoded in RFC 2047 format (that =?UTF-8?B?...?= notation used for non-ASCII characters in sender names). Without per-message verification, you won't know. You'll just have a lost email.

The concrete risks of DIY on this type of migration:

• Duplicate messages if the insertion logic fails halfway through
• Missing attachments if the multipart structure is incorrectly rebuilt
• Broken conversation threads in Outlook (conversations rely on References: and In-Reply-To: headers that can be altered)
• 429 Too Many Requests errors from the Microsoft Graph API at 3 AM, halting processing with no rollback
• No straightforward way to verify that all 8,000 corrections were actually applied correctly

And for shared hosting migrations specifically, there's an extra layer of difficulty: those emails carry multiple stacked Received: headers, not just one. A naive script that strips "the last Received:" won't cut it. You have to analyze the full header chain to identify which header belongs to which migration, and which one actually represents the original received date.

What Redate.io does differently

Each person signs in with their own Microsoft account, and Redate.io opens that mailbox with the access that sign-in grants. No portal, no application to register. The initial scan is free: Redate.io identifies every email where the displayed date doesn't match the real date, and gives a precise per-mailbox count.

The correction relies on a proprietary engine that performs header chain analysis and date metadata reconstruction on each individual message, whatever migration tool was used, even when multiple layers of corruption are stacked on top of each other. Every corrected email is verified individually. Originals stay in a visible backup folder inside your own mailbox until you delete them yourself.

For shared hosting migrations specifically, Redate.io's multi-stage analysis pipeline explicitly handles double-corruption scenarios: it doesn't just look at the last Received: header, it traces the full history to recover the real received date. See also how to fix email dates after Microsoft 365 migration in general, and the technical breakdown of IMAP INTERNALDATE and why dates break.

Before or after migration: two moments to act

Two situations, two approaches.

You haven't migrated yet. Good news: it's possible to limit the damage. Some migration tools (MigrationWiz in Exchange mode, CloudM with the right settings) preserve dates better than others. But even in the best case, a migration from shared hosting without a clean history will probably leave traces. Plan a Redate.io pass after the migration, before handing mailboxes back to users.

You've already migrated and the tickets are rolling in. Redate.io corrects existing mailboxes in Microsoft 365, regardless of how long ago the migration happened. The scan gives you a precise picture of the real state of each mailbox before any intervention. Also check the email migration checklist to avoid the same problems next time.

Migrated from OVH, Infomaniak, Ionos or o2switch to Microsoft 365 and the dates are wrong? Create a Redate.io account to scan your mailboxes for free and see exactly the extent of the damage before deciding anything.