Windows Server 2016 End of Support: Four Months Out, Here Is Your Plan
Written by Damien Harrison, Director of Client Success · Published 7 September 2026 · Estimated reading time 7 minutes
Four months. That is what stands between today and 12 January 2027, when Microsoft stops supporting Windows Server 2016.
If you read our guide to what end of support actually means earlier in the year, you will know that a migration done properly runs three to six months. Which puts September in an awkward but useful position. There is still time to do this well, but not much room left for the project to sit on someone’s list while other things take priority.
So rather than restate the risks, this post does something more practical. It sets out what needs to happen in each of the four months you have left, what the decision points are, and what to do if your estate is complicated enough that four months is not realistic. If you are running Server 2016 anywhere, you should be able to read this and know what your September looks like.
Time remaining: approximately four months to 12 January 2027.
Typical migration: three to six months across discovery, procurement, testing and cutover.
What that means: a straightforward estate started this month finishes comfortably. A complex one needs a decision in September about scope, sequencing, or a paid bridge.
The one thing to do this week: confirm exactly how many Server 2016 instances you have and what depends on them.
Why four months is the honest cut-off
Migration timelines are not padded out of caution. Each stage has a floor beneath which you are borrowing risk from the next one. Discovery takes two to four weeks because you have to find every dependency, not just the obvious ones. Procurement or cloud setup takes three to eight weeks, and hardware lead times are outside your control. Migration and testing takes four to eight weeks, and testing is where problems surface cheaply instead of expensively. Training and clearing down the old environment takes another two to four weeks.
Add the floors together and you get roughly eleven weeks of genuine work, which fits inside four months. Add the ceilings and you get closer to six months, which does not. The difference between those two numbers is mostly application complexity, and that is why September matters more than it looks: it is the month where you find out which of the two you are.
There is a second factor worth naming. You are not the only organisation working to this date. Engineering capacity across the industry tightens through the autumn, and hardware lead times stretch as demand concentrates. A project that takes twelve weeks in September can take longer in November for reasons that have nothing to do with your estate.
Your month by month plan
Find out what you are dealing with
Inventory every Server 2016 instance, including anything virtualised or forgotten in a branch office. Map what depends on each one: applications, shares, print, authentication, integrations. Contact your software vendors and get written confirmation of what is supported on Windows Server 2022 or 2025. Decide the destination for each workload. This is the month that determines whether the rest is calm or rushed.
Commit and procure
Sign off the plan and the budget, then order. Hardware lead times are the thing most likely to bite you, so if you are staying on premises, October is the latest sensible point to place an order. If you are moving to Azure, build and configure the target environment this month. Book your engineering resource for the cutover window now rather than later.
Build, migrate and test
Stand up the new environment, migrate data and applications, and test properly. Test with the people who actually use the system, not just technically. This is where you find the integration nobody documented and the report that only finance runs at month end. Rehearse the cutover, including the rollback, so the live run is a repeat rather than a first attempt.
Cut over and close out
Run the live migration, ideally over a planned weekend with the rollback tested. Then finish the job: decommission the old server, train anyone who needs it, and update your documentation, asset register and compliance evidence. Aim to be done before the Christmas shutdown rather than working around it, which leaves early January as contingency rather than the deadline itself.
The plan above finishes a month early on purpose. Building contingency into the schedule is what separates a controlled project from a stressful one, and the last two weeks of December are unusable for most organisations anyway. Treat 12 January as the point by which you must already be finished, not the day you finish.
What if four months is not enough for us?
For some estates it genuinely will not be, and it is better to establish that in September than to discover it in November. If you have a line of business application whose vendor cannot confirm support on a modern server, a heavily customised environment, or a dozen instances rather than one, then compressing this into four months means accepting risk you would not otherwise accept.
If that is you, there are three sensible responses, and they work together.
Sequence by risk
You do not have to move everything at once. Identify which instances are most exposed, usually anything internet-facing, anything holding personal or financial data, and anything in scope for an audit or insurance renewal, and move those first. A partial migration that clears your highest risks by January is far better than an all-or-nothing plan that slips.
Use Extended Security Updates as a bridge
Microsoft offers paid Extended Security Updates for up to three years past the deadline. The costs climb each year and it is not a destination, but as cover for a workload that genuinely cannot move by January it is a legitimate part of a plan. The difference between using ESU and drifting is whether you have a migration date attached to it.
The third response is the one people skip: tell whoever needs to know. If a workload will still be on Server 2016 in January, your insurer, your auditor and in some cases your customers would rather hear about it alongside a dated remediation plan than discover it themselves. A documented, in-progress migration is a far easier conversation than an unexplained gap.
What to do this week
- Count your Server 2016 instances, including virtual machines and anything at other sites.
- List what depends on each one, and check whether SQL Server 2016 is running alongside it, since that already went out of support on 14 July 2026.
- Email your software vendors and ask, in writing, what they support on Windows Server 2022 and 2025.
- Put a decision date in the diary before the end of September for destination and budget.
- If the answer to any of the above is “I am not sure”, that is the thing to resolve first, and it is exactly what a readiness check is for.
Frequently asked questions
Is four months enough to migrate from Windows Server 2016?
When is the latest we can order hardware?
What happens if we are still running Server 2016 in January?
Should we prioritise some servers over others?
Fifteen minutes is enough to tell you exactly where you stand
Most of the difficulty in September is not technical. It is not knowing how many instances you have, what depends on them, or whether four months is comfortable or tight for your particular estate. We will work that out with you, tell you honestly which category you are in, and give you a plan and timeline you can take to the board. No obligation.