For organisations still running Exchange Server 2016 or 2019, the clock is now very definitely ticking.
Both versions reached end of support in October 2025. Microsoft subsequently introduced an Extended Security Update programme to give organisations additional time to complete migrations, but the second and final period ends in October 2026.
Microsoft has confirmed there will be no further extension.
For many organisations, that makes the next few months about getting Exchange migrated and the old infrastructure switched off.
But there is an important question that can easily get overlooked:
What else still depends on your Exchange environment?
For organisations with a legacy email archive, the answer can be more complicated than expected.
Exchange and the archive may be more closely connected than you think
Email archives rarely operate entirely in isolation.
An archive that has been in place for ten or fifteen years may depend on Exchange for journaling, mailbox access, service accounts, connectors, SMTP routing or other integration points.
There may also be archived mailboxes, journal mailboxes or historic data that still needs to be extracted before the old environment can disappear.
The problem is that these dependencies aren’t always obvious.
The people who originally implemented the archive may have left the organisation years ago. Documentation may be incomplete. Configurations that were perfectly normal when the archive was installed may now be regarded as legacy.
Exchange migration can therefore expose dependencies that nobody realised were still there.
And discovering them after the migration programme has reached its decommissioning phase is considerably less convenient than finding them at the beginning.
Don’t make archive migration an afterthought
There is a temptation to treat messaging and archive migration as two separate projects.
First, migrate Exchange.
Then, once that is safely completed, decide what to do about the old archive.
Sometimes that will be perfectly sensible. But it should be a conscious decision rather than an assumption.
If the archive depends on the Exchange environment that is being retired, the two programmes need to be considered together.
Before beginning the Exchange decommissioning process, organisations should understand:
- how email currently enters the archive;
- which Exchange servers, mailboxes and accounts the archive depends upon;
- whether any journaling infrastructure remains in use;
- whether archive extraction or migration tooling relies on Exchange;
- whether inactive or former users have data that still needs to be migrated;
- what happens to legal holds and retention requirements;
- and what needs to remain operational until the archive migration is complete.
The objective is not necessarily to migrate everything simultaneously.
It is to make sure that the sequencing is understood.
Decide what happens to the archive
Retiring Exchange can also provide a useful opportunity to reconsider the archive itself.
An organisation that has maintained the same archive platform for many years may no longer have the same requirements it had when that platform was selected.
Microsoft 365 may now provide some or all of the required retention, eDiscovery and compliance functionality.
Another specialist archive may be more appropriate.
The organisation may want to consolidate several historic archives into a single destination.
Or there may be legitimate reasons to retain the existing archive.
The important thing is to make that decision deliberately.
An infrastructure deadline shouldn’t dictate the information governance strategy, but it can be an excellent trigger to review it.
Understand what is actually in the archive
If the archive is going to move, discovery should happen before the source environment starts disappearing.
How much data is there?
How many users and archives?
How much belongs to former employees?
Are there journal archives?
Are there PST files or other historic data stores associated with the environment?
Are records subject to legal hold?
What retention policies currently apply?
Are there corrupt, inaccessible or unusual items that need special treatment?
These questions establish the scope of the migration and, importantly, provide a baseline against which the eventual destination can be reconciled.
That becomes much harder if parts of the original environment have already been decommissioned.
Don’t forget the technology between source and destination
There is another dependency worth considering: the migration technology itself.
Legacy archive migrations often interact with messaging platforms through APIs, protocols and authentication methods whose own lifecycles are changing.
That means organisations need to understand not just whether their source and destination platforms are supported, but whether the proposed migration route between them will remain supported for the duration of the project.
For a migration involving tens or hundreds of millions of messages, that duration can be significant.
This is one reason why early technical discovery matters.
A migration design that works today needs to remain viable until the last required record has reached its destination.
Preserve the evidence before decommissioning
Finally, switching off the old environment changes the nature of the migration.
While both platforms exist, questions can be investigated against the source.
After decommissioning, that option may disappear.
Before retiring the old infrastructure, organisations should therefore be satisfied that the archive migration has been properly reconciled.
That means being able to demonstrate:
- what data existed at the source;
- what was selected for migration;
- what migrated successfully;
- what exceptions occurred;
- how those exceptions were resolved;
- and whether the required metadata, attachments and compliance context were preserved.
Migration reports and audit trails should be retained independently of the system being decommissioned.
The objective is to reach the point where the old environment can be switched off confidently rather than simply because the project plan says it is time.
October is a deadline, not a migration strategy
Microsoft’s final Extended Security Update period gives organisations still operating Exchange Server 2016 and 2019 a very clear deadline.
But the objective shouldn’t simply be to get Exchange switched off before the clock runs out.
It should be to understand everything that depends on it and make sure those dependencies have somewhere safe to go.
For organisations with legacy email archives, that means bringing archive discovery into the Exchange migration conversation early.
You don’t necessarily have to migrate Exchange and the archive at the same time.
But you do need to know how you’re going to migrate both before you start switching things off.