The Clock on SCOM 2016 Runs Out in January 2027
If your monitoring platform is still System Center Operations Manager 2016 or your management servers still run Windows Server 2016, you have a hard deadline in front of you:
| Product | Extended support ends |
|---|---|
| System Center 2016 Operations Manager | 11 January 2027 |
| Windows Server 2016 | 12 January 2027 |
| SQL Server 2016 (worth checking too) | Already ended — July 2026 |
That is a matter of months away, not years. And because SCOM 2016 cannot be upgraded in place to SCOM 2025, this is not a weekend job. It is a migration project, and the time to scope it is now.
What “end of extended support” actually means
Extended support is the second and final phase of Microsoft’s Fixed Lifecycle Policy. Mainstream support for both products ended back in January 2022; since then you have been in the extended phase, which delivers security updates only. Once that phase closes in January 2027:
- No more security updates. Every vulnerability discovered after that date stays open on your servers permanently. For a SCOM management group — which holds privileged Run As accounts and an agent on nearly every server you own — that is a very attractive target.
- No Microsoft support. No hotfixes, no Update Rollups, no ability to open a case when your data warehouse stops writing.
- Compliance and audit exposure. ISO 27001, PCI DSS, DORA, NIS2 and most internal control frameworks expect supported, patchable software. “Unsupported monitoring platform” is an audit finding waiting to happen — and monitoring is often the very control your auditor relies on for availability and incident detection.
- A slow compatibility squeeze. Newer management packs, newer agent operating systems, newer SQL versions and modern browsers increasingly assume a current SCOM build. SCOM 2016’s web console already sits awkwardly with today’s browsers.
Microsoft is offering Extended Security Updates for Windows Server 2016 via Azure Arc, and ESU exists for SQL Server 2016 as well. ESU buys time — at a cost, and only for the OS and database layers. There is no equivalent lifeline that keeps SCOM 2016 itself supported. Treat ESU as a bridge while a migration runs, not as an alternative to one.
Why SCOM 2025 is the right target
SCOM 2025 is the current release and the version with the longest runway ahead of it. Moving there rather than to an interim version means you do this once.
What you get:
- Windows Server 2025 and modern SQL support. Management servers run on Windows Server 2022 or 2025, with SQL Server 2019, 2022 and — from Update Rollup 1 — SQL Server 2025. Your monitoring platform stops being the thing that pins you to an old OS build.
- A supported, current agent estate. Agents are supported on Windows Server 2016 through 2025, plus Windows 10 and 11, so you can migrate monitoring first and modernise the servers behind it on your own schedule.
- Serious Linux and UNIX modernisation. OpenSSL 3.1 to 3.3 support across current distributions, and UR1 adds RHEL 10, Oracle Linux 10, Rocky 10, Alma 10 and Debian 13. If your SCOM 2016 environment has quietly stopped monitoring newer Linux hosts, this is why.
- Modern browser support for the web console — Edge 121+ and Chrome 121+ — instead of the fragile browser workarounds many SCOM 2016 users have learned to live with.
- A hybrid path. With SCOM 2025 you’re positioned to work alongside Azure Monitor and hybrid cloud monitoring if and when you want to move parts of the platform to Azure.
- Ten more years of lifecycle. The most underrated feature of all.
The catch: there is no in-place upgrade from SCOM 2016
Microsoft supports in-place upgrade to SCOM 2025 only from SCOM 2022. From SCOM 2016 the documented in-place route is a chain: 2016 → 2019 → 2022 → 2025. Three consecutive upgrades, each with its own prerequisites, SQL requirements, downtime window and failure modes, carried out on hardware and an operating system that are themselves out of support. Every accumulated flaw in the existing environment — an oversized data warehouse, orphaned management packs, half-decommissioned agents, undocumented overrides — comes along for the ride.
The practical, and in our experience far safer, answer is a side-by-side migration: build a clean SCOM 2025 management group next to the existing one, move what deserves to be moved, and decommission the old environment once the new one has proven itself.
A side-by-side migration typically runs like this:
- Inventory what is transferable — management packs and their versions, overrides, custom MPs and authored monitors, Run As accounts and profiles, notification subscriptions, user roles, groups, maintenance schedules, reports and dashboards.
- Design the new management group — sizing, resource pools, gateway placement, SQL and data warehouse layout, retention, high availability, certificates and hardening.
- Deploy SCOM 2025 clean, with the latest Update Rollup applied from day one.
- Rebuild rather than inherit — import current MP versions, reapply the overrides that still make sense, and deliberately leave behind the ones that no longer do. This is the single best opportunity you will get to reduce alert noise.
- Migrate agents, multi-homing where a parallel run is needed so nothing goes unmonitored during transition.
- Validate, then decommission the SCOM 2016 environment — after you’re confident, not before.
The upside of the harder-looking option: you end up with a genuinely healthy platform, not a decade of accumulated debt on a new version number.
How TopQore runs this — and why we do health check twice
Migrations fail on the things nobody looked at first. That is why every TopQore SCOM migration is bracketed by a health check before and after.
The health check before establishes the truth about your current environment: management group performance, database and data warehouse sizing and growth, agent health and coverage gaps, management pack sprawl, alert noise and tuning debt, Run As and security configuration, and the state of the underlying Windows and SQL layers. It tells us what to carry forward, what to leave behind, and which migration path — side-by-side or, for well-maintained newer environments, in-place — actually fits. It also gives you a defensible scope and cost before you commit.
The health check after proves the outcome: the new management group is correctly sized and configured, every agent that should be reporting is reporting, monitoring coverage matches or exceeds what you had, and alerting is tuned rather than merely inherited. You get a documented baseline and a tuning backlog to work from — not just a login to a new console.
Around those two checks sit the services that make the project stick: migration design and execution, management pack tuning, custom MP authoring, SCOM training for your team so the platform stays healthy after we leave, and ongoing consultancy or managed support.
Start now, not in December
Working backwards from January 2027, a realistic side-by-side migration for a mid-sized estate needs a health check and design phase, hardware or VM provisioning, a build, a parallel run long enough to trust, an agent migration wave plan that respects your change windows, and a decommissioning step. Add procurement lead times and a change freeze over the year-end holidays, and the comfortable window closes well before the deadline does.
If you are running SCOM 2016 or Windows Server 2016, the useful next step is small: a health check that turns “we need to do something about SCOM” into a scoped plan with a date on it.
Request a quote or get in touch — we’ll tell you honestly what your environment needs.
Frequently asked questions
When does SCOM 2016 support end?
Extended support for System Center 2016 Operations Manager ends on 11 January 2027. Mainstream support ended on 11 January 2022.
When does Windows Server 2016 support end?
Extended support for Windows Server 2016 ends on 12 January 2027.
Can I upgrade SCOM 2016 directly to SCOM 2025?
No. Microsoft supports an in-place upgrade to SCOM 2025 only from SCOM 2022. From SCOM 2016 the documented in-place route is 2016 → 2019 → 2022 → 2025 — three consecutive upgrades. In practice, a side-by-side migration to a clean SCOM 2025 management group is faster and considerably lower risk.
What is a side-by-side SCOM migration?
You build a new SCOM 2025 management group alongside the existing one, migrate management packs, overrides, Run As accounts, subscriptions and agents into it, run both in parallel until the new environment is proven, then decommission the old one.
Is there an ESU option for SCOM 2016?
No. Extended Security Updates are available for Windows Server 2016 (via Azure Arc) and for SQL Server 2016, but there is no ESU programme that keeps SCOM 2016 itself supported.
What operating system and SQL Server versions does SCOM 2025 need?
Management servers run on Windows Server 2022 or 2025, with SQL Server 2019, 2022, or — from Update Rollup 1 — SQL Server 2025. Agents remain supported on Windows Server 2016 through 2025.
How long does a SCOM 2016 to SCOM 2025 migration take?
It depends on estate size, but plan for a health check and design phase, provisioning, build, a parallel run long enough to build confidence, phased agent migration around your change windows, and decommissioning. Working back from January 2027, mid-sized estates should be starting now.