Exchange Server, the email server companies keep inside their own building, reached the end of Microsoft's support on October 14, 2025 — both the 2016 and the 2019 version. According to Microsoft itself, that means the product stopped receiving technical support for problems that come up, bug fixes for issues affecting stability, security fixes for vulnerabilities, and even time zone updates. The server keeps running normally. What changes is that if a new vulnerability turns up tomorrow, no one is going to fix it.
Coverage published shortly after the deadline pointed out that companies in regulated sectors — finance, healthcare, essential services — risk failing a compliance audit by continuing to run an unsupported system, on top of a higher exposure to attack. An email server with no more security updates is an open door, and it is exactly the kind of door attackers know to look for first.
For whoever signs off on the budget, the question is no longer whether the migration will happen — it is when, and how much disruption comes with it. Done with a method, swapping the in-house email server for Microsoft 365 (the former Office 365) goes by almost unnoticed. Done in a rush, that is exactly where a customer's message gets lost.
The risk of leaving email as it is
The most common situation is a familiar one: someone set up that email server years ago, built the rules and the mailboxes the way the company needed at the time, and no longer works there. Whoever is responsible for IT today knows the system works, but avoids touching it — because they cannot map out every piece that depends on it, and the fear of bringing down the company's email outweighs the discomfort of leaving it alone.
The trouble is that "leaving it alone" had an expiration date, and it has passed. Microsoft lists four things that simply stopped: technical support for questions or incidents, fixes for issues affecting stability, security fixes, and time zone updates. The first three tend to show up at the worst possible moment — when something has already broken, or when an attacker has already found the way in.
It is the kind of situation managed service providers such as Skills IT see often: the server does not announce that it is out of date, it simply keeps running until the day it stops — or until someone outside finds a flaw no one is going to patch anymore. In the meantime, every month that passes is another month without a fix, stacked on top of the last one.
Microsoft itself recommends starting to plan the move away from Exchange Server as soon as possible, pointing to a move to Microsoft 365 as the most direct path — a single step that removes server updates, hardware purchases, and server-room upkeep, replacing them with always being on the current version of email, with no more upgrade project needed a few years down the road.
Why the usual approach falls short
The usual approach, once the decision is finally made, tends to be one of two extremes: keep putting it off until the server actually fails, or try to solve everything in one weekend, with no inventory and no testing, hoping it is "just a matter of copying the mailboxes to the cloud."
Research from Osterman Research among IT professionals at mid-size and large companies migrating their communication systems, published in 2020, found that nearly half consider making sure everything keeps running during the migration — systems staying up, access staying open, nothing breaking along the way — the hardest part of the process. Right behind it, 37% named managing the coexistence between the old and the new email system, while both remain live at the same time, as difficult.
There is a practical reason for that: while the switch is not yet complete, messages addressed to someone already migrated keep arriving at the old server until the internet's delivery pointer switches over to the new address. If no one watches that window, messages get lost in it — not because the migration failed, but because no one checked what was still arriving at the wrong place.
An additional "usual approach," and an even riskier one, is trying to move every mailbox at once, with no grouping at all. Microsoft itself recommends the opposite even for small companies — moving mailboxes gradually, checking each batch before moving on to the next, even when the technical limit would allow moving everything together.
What has to be in place
A well-run email migration rests on concrete mechanisms, not on hoping for the best.
An inventory of mailboxes and what depends on each one. Before moving anything, someone needs to list who uses each address and which outside systems send to it — billing, invoices, equipment alerts, a supplier portal. This is usually what is missing when a migration "discovers" a broken system only after it is done.
Migration in waves, not all at once. Small groups first — one department, one branch — with a check before moving on to the next group. An error caught early, in a handful of mailboxes, is easy to fix; the same error spread across the whole company is not.
A coexistence period between the old server and the new one. While the switch is unfinished, both systems stay live and a message can arrive at either one. Someone needs to watch that window until delivery finally points to the new address for good.
A check before switching off what is left behind. Every migrated mailbox is checked — history, folders, contacts — before any old server gets switched off. Switching it off first and checking later is how a lost message becomes permanent.
A plan for the history and the old attachments. Not everything needs to move to the new system on day one; what matters is deciding, and writing the decision down, instead of leaving old messages behind by accident.
This is how Skills IT works: an inventory before touching any mailbox, migration in waves with a check between each one, and the old server only goes offline once the new one has proven it is receiving everything correctly.
What the company gains afterward
The most direct gain is no longer keeping a piece of equipment in-house: no new server purchase a few years down the road, no cooled room to maintain, no one on call hoping the disk does not fail over a weekend. The cost of keeping that server — power, hardware, the time of whoever looks after it — disappears from the spreadsheet and turns into a predictable monthly fee, within what the contract already defines.
There is also a gain for whoever uses that email every day: a bigger mailbox, always on the current version, native integration with calendar, files, and meetings — with no more upgrade project needed down the road. And for whoever decides, the central advantage is no longer having to hope: with the email server out of the building and always current, the question stops being "will this still hold up?" and becomes what the company wants to do with the time that freed up.
None of these gains depend on rushing. They depend on the migration having been done with an inventory, in waves, with checks along the way — the opposite of the improvised weekend that is usually where a lost message comes from.
Questions to settle before migrating
Before setting a start date, it is worth bringing these questions to the next conversation between leadership and whoever is responsible for IT:
- Does anyone know, today, which outside systems depend on a specific email address? Billing, invoices, equipment alerts, a customer portal — if the answer is not written down anywhere, the migration will find out the hard way, one broken system at a time.
- Is there an inventory of active mailboxes and of the ones that only stick around because of history? Migrating without knowing what each mailbox holds means deciding in the dark what stays and what gets lost.
- Who is going to check each batch of mailboxes before moving on to the next? Without that step, a small error early on turns into a big problem by the end.
- What happens to the email history once the old server is switched off? The answer needs to exist before the switch-off, not after.
- Who is the single person responsible for this migration, inside and outside the company? A migration with no clear owner is the most common recipe for a lost message.
