Last month we gave our verdict on Windows Server 2016 for private cloud estates. The punchline there was that management upgrades first: you cannot properly run 2016 Hyper-V hosts under System Center 2012 R2, so the System Center 2016 upgrade is the gate everything else queues behind. We have now taken a full 2012 R2 management stack — SCVMM, SCOM, SCCM, plus DPM and Orchestrator in supporting roles — through the upgrade in our lab, modeled on a client environment that manages a 400-plus-server virtualized estate, and we have the first production wave scheduled for December.
This post is the field notes: the upgrade order we settled on and why it differs from the one you might expect, the coexistence matrix that determines how long you can take, and the four things that broke in the lab so they would not break in production.
First, a terminology correction that matters more than it looks: there is no "SCCM 2016." Configuration Manager left the wave-release model last year and became Current Branch — versioned 1511, 1602, 1606 — with in-console servicing updates. If you are on Current Branch, you are already current, and 1606 is the baseline that supports the rest of this story. If you are still on ConfigMgr 2012 R2, your path is a supported in-place upgrade to Current Branch, and it is comfortably the smoothest upgrade in the whole suite. The suite's marketing says "System Center 2016"; plan ConfigMgr on its own cadence.
Prerequisites before anything moves: update rollups and SQL
Every 2012 R2 component must be at a recent update rollup before its 2016 setup will proceed — for the versions we upgraded, that meant UR9 or later on SCOM and SCVMM (we standardized on UR11, current at the time we built the plan). Verify this before you schedule anything, because "apply a UR to production SCOM" is itself a change with a test cycle, and we have seen upgrade projects lose a month discovering their monitoring platform was three rollups behind.
SQL Server is the second gate. System Center 2016 wants SQL 2012 SP2 at minimum and is happy on SQL 2014; check each component's matrix rather than assuming the suite moves as one. Our client had OperationsManager and VirtualManagerDB instances on a shared SQL 2012 RTM-era cluster — so the real project plan started with a SQL servicing exercise that appeared on nobody's original estimate. Look at your SQL estate first. It is where upgrade plans go to get honest.
Also non-negotiable: backups you have tested restoring. For SCVMM specifically, export the encryption keys and back up the VMM database together — a VMM database restored without its keys is a list of hosts that no longer trust you.
The order we run: VMM first, SCCM on its own track, SCOM last
Microsoft's documented suite order upgrades Orchestrator, Service Manager, and DPM early, then Operations Manager, then VMM. We deviate deliberately: in our sequence VMM goes first among the big three and SCOM goes last, and since "why we stage SCOM last" raises eyebrows, here is the reasoning.
VMM goes first because it is the blocker. The entire business case — 2016 Hyper-V hosts, rolling cluster upgrades, eventually Storage Spaces Direct — waits on VMM 2016, and VMM 2012 R2 cannot manage what comes next. Note that VMM 2016's management server itself requires Windows Server 2016 underneath, which for us meant a new VM and a database-move upgrade rather than a literal in-place one: build the new 2016 management server, uninstall VMM on the old server retaining the database, point setup at the existing VirtualManagerDB, restore the encryption keys, done. It sounds worse than it is; the lab run took an afternoon, most of it snapshot-and-verify discipline.
SCCM runs on its own track entirely, per the Current Branch point above — we took the lab from 1602 to 1606 through in-console servicing with no drama, and it has no ordering dependency on the rest.
SCOM goes last for a simple operational reason: it is the component watching everything else while everything else is in surgery. Upgrade your monitoring platform first and you spend the riskiest weeks of the program either blind or distrusting every alert because the alerting system itself just changed. We keep SCOM 2012 R2 stable and lit while VMM and the fabric move, let the estate settle, then upgrade SCOM in a quiet window with the confidence that anything it alerts on afterward is real. The cost of this choice is a few weeks of SCOM 2012 R2 monitoring 2016 components with imperfect management pack coverage — a trade we make knowingly, and mitigate by importing the updated MPs immediately after the SCOM upgrade completes.
Coexistence and the agent question
The whole plan stands on coexistence being supported, so here is the matrix that governed ours, condensed to what actually matters in the field:
| Combination | Supported? | Field notes |
|---|---|---|
| VMM 2016 managing 2012 R2 Hyper-V hosts | Yes | The key to phased fabric upgrades |
| VMM 2012 R2 managing WS2016 hosts | Not properly | This is why VMM goes first |
| SCOM 2012 R2 agents reporting to SCOM 2016 | Yes | Buys you a long agent-upgrade tail |
| SCOM 2016 monitoring WS2016 | Yes, with updated MPs | Import the 2016 MP wave immediately |
| ConfigMgr 1606 clients on WS2016 | Yes | Full support arrived in Current Branch |
| VMM 2016 with SCOM 2012 R2 integration | Sequencing risk | Re-wire the connector after both sides land |
The SCOM agent row deserves emphasis. On an estate with hundreds of agents, the ability of a SCOM 2016 management group to keep working with 2012 R2 agents means agent upgrades become a controlled, ring-based rollout — we push them via ConfigMgr in waves, monitoring heartbeat and health service restarts per wave — rather than a big-bang event on upgrade night. Plan weeks for the agent tail, not days, and reconcile with a simple report of agent versions until the stragglers are gone.
The VMM–SCOM connector is the sequencing trap in the middle: it binds the two components whose upgrades you are deliberately separating in time. Ours is documented, torn down before the VMM upgrade, and re-established after SCOM lands — leaving it wired during the interregnum produced exactly the connector errors in the lab you would expect.
What broke in the lab, so it wouldn't break in December
Four findings, in descending order of how much production pain they pre-paid:
- A custom SCOM management pack referencing a deprecated module failed import on 2016. An internally authored MP from 2013 monitoring a line-of-business service imported with errors and silently dropped a monitor. The lesson generalizes: inventory your custom and third-party MPs and test-import all of them on a 2016 lab management group before upgrade weekend. Vendor MPs from vendors who have not touched them since 2013 are the highest-risk items in your whole upgrade.
- The VMM library's stale objects turned into upgrade noise. Years of orphaned templates and unattend files referencing dead hosts produced a wall of warnings during the database upgrade phase, several of which masked one warning that mattered (a logical network with an empty definition). Run a library and fabric hygiene pass first; upgrades amplify clutter.
- Orchestrator runbooks using the 2012 R2 VMM integration pack broke against VMM 2016 until the integration pack was updated and each activity re-registered. If you have automation calling VMM — and every mature estate does — list those runbooks now. This is the coexistence gap that bites mid-program, after VMM upgrades and before anyone remembers the runbooks exist.
- Console sprawl. Operators with the 2012 R2 VMM console on their workstations cannot connect to the upgraded server. Trivial, foreseeable, and still the thing that generates the most upgrade-morning helpdesk tickets. Package the 2016 consoles in ConfigMgr and deploy them the week before.
None of these are exotic. All of them would have turned a clean production window into a long night, and the lab surfaced every one for the price of a few days of engineering time. That trade never stops being worth it — it is the same lesson our migration practice relearns on every mail and directory project, wearing a different logo.
If you're facing this
If your System Center 2012 R2 stack is the thing standing between you and Windows Server 2016 — or if the phrase "custom management pack from 2013" made you slightly nauseous — we can help. We have run this upgrade sequence in the lab and are taking production estates through it now; get in touch and we will share the runbooks, the agent-wave plan, and the list of things to check before you commit a weekend.