Every operating system version eventually reaches end of support, after which the vendor stops releasing security updates. Servers running unsupported systems become steadily more exposed and may breach compliance requirements.
Track lifecycle dates
Record the support end dates for every operating system version in your estate. Vendors publish lifecycle policies for Windows Server and for enterprise Linux distributions, which often offer long-term or extended support options.
Start early
Upgrades frequently take longer than expected because of application compatibility, vendor certification and change windows. Begin planning well ahead of the deadline.
Choose a path for each server
- In-place upgrade where supported and low risk.
- Rebuild and migrate to a fresh, hardened image — often cleaner.
- Re-platform to containers, PaaS or SaaS.
- Retire servers and applications that are no longer needed.
If you cannot upgrade in time
- Investigate paid extended security updates where available.
- Isolate the server on a restricted network segment.
- Increase monitoring and limit administrative access.
- Set a firm deadline and track it as a formal risk.
5 best steps for an end of support programme
- Build an accurate inventory. Identify every server, operating system version, application and owner, including virtual machines and cloud instances.
- Classify by upgrade path. Group servers into in-place upgrade, rebuild and migrate, replace with SaaS, or retire.
- Engage application vendors early. Confirm which versions they support on newer operating systems and whether application upgrades are needed.
- Plan in waves. Upgrade lower-risk systems first to refine runbooks, then move to critical systems with tested rollback plans.
- Track progress publicly. Share dashboards showing remaining servers by owner and deadline to maintain momentum.
Options when you cannot upgrade in time
- Purchase extended security updates where vendors offer them, as a temporary bridge.
- Isolate the server with strict firewall rules and remove internet access.
- Restrict administrative access and increase monitoring.
- Move the workload to a platform where extended support is included, if available.
Common mistakes to avoid
- Starting planning only months before the deadline.
- Forgetting appliances and embedded systems running older operating systems.
- Upgrading the operating system without testing backup, monitoring and security agents.
Frequently asked questions
What happens after end of support?
The server keeps running, but no new security fixes are released, so new vulnerabilities remain permanently exploitable.
How long does an upgrade programme take?
For large estates, start at least 18 months before end of support.
A 90-day action plan
Days 1 to 30: produce a list of every server running a release that loses vendor updates within two years, with owners and applications.
Days 31 to 60: confirm supported upgrade paths with application vendors, estimate effort for each server and secure budget and staffing.
Days 61 to 90: upgrade a first wave of simple servers, refine runbooks and publish a progress dashboard showing remaining systems by deadline.
Questions to ask application vendors
- Which newer releases are certified for your product?
- Do we need an application upgrade before changing the operating system?
- Are there licence implications when moving to new hardware or versions?
- Is an in-place upgrade supported, or must we rebuild?
- What support will you provide during the migration?
Key terms explained
- Mainstream support: the period when a vendor provides features and security fixes.
- Extended support: a later period with security fixes only, sometimes for an extra fee.
- In-place upgrade: upgrading an existing installation rather than rebuilding.
- Rebuild and migrate: creating a new server and moving the application across.
The bottom line
Unsupported systems become easier targets every month as new vulnerabilities remain unpatched. Starting early, building an accurate inventory, engaging application vendors and upgrading in planned waves keeps the programme on track. Where deadlines cannot be met, use extended updates and isolation as temporary measures rather than permanent solutions. Treat lifecycle planning as an ongoing discipline, so future version changes become routine rather than a recurring crisis.
Further reading on end of support
For authoritative, vendor-neutral guidance on end of support, see Microsoft’s product lifecycle information. You can also browse our free whitepapers.
