Configuration Manager goes annual: what it signals, and why co-management is a valid end state

Configuration Manager moves to an annual release cadence with version 2609 next month. Every time Microsoft changes the shape of ConfigMgr, someone reads it as a deprecation notice. It is not one, and the actual signal is more useful than the panic.

What Microsoft announced

From version 2609, due September 2026, Configuration Manager releases once a year rather than three times. The releases align with the Windows client H2 security and stability cadence. Support terms do not change: each version still gets 18 months from its release date. Microsoft has said each release prioritises reliability over new features, with hotfix rollups only where genuinely necessary.

What it actually signals

Reliability-first releases on a yearly clock is what a product looks like when it has stopped growing and started being maintained. That is not the same as being killed. Microsoft has been explicit that new investment goes to Intune while Configuration Manager remains supported, and current lifecycle dates run to at least March 2029.

The honest reading: ConfigMgr is a stable dependency now, not a platform you should expect new capability from. Plan for it the way you plan for any stable dependency, which means fewer upgrades and no new architecture built on top of it.

Co-management is a valid end state

The part most migration advice gets wrong is treating co-management as a corridor you pass through on the way to pure cloud. Microsoft’s own position is that permanent co-management is a legitimate destination, and for a lot of estates it is the correct one.

You keep co-management permanently when you have something ConfigMgr does that Intune does not do as well for you. Usually that is one of three things: deep OS deployment and imaging, complex application sequencing with real dependency chains, or the reporting and inventory depth people have built a decade of process around.

Moving workloads in the right order

Workloads move independently, which is the whole point of co-management. Move them in order of blast radius, smallest first.

1. Compliance policies. Reporting only until Conditional Access consumes them, so a mistake is visible and harmless.
2. Windows Update policies. Reversible, and the failure mode is a delayed patch rather than a broken device.
3. Resource access policies. Certificates, Wi-Fi, VPN. Test on real hardware before widening, because failure here locks people out of the network.
4. Endpoint Protection. Straightforward once Defender is already the engine.
5. Device configuration. Higher risk because settings conflict silently.
6. Client apps. Usually last, and often the one that never fully moves.

Checking where your workloads actually sit

The console shows the intended slider position. This shows what the devices believe, which is not always the same thing.

1# Run on a co-managed client. Returns the workload bitmask the client is
2# actually honouring, not the value the console thinks it pushed.
3$cm = Get-CimInstance -Namespace rootccmComanagementInfo -ClassName CCM_ComanagementInfo
4
5[PSCustomObject]@{
6    Enabled        = [bool]$cm.ComanagementEnabled
7    MDMWorkloads   = $cm.MDMWorkloads      # bitmask: which workloads Intune owns
8    ComgmtPolicy   = $cm.ComgmtPolicyState
9    CapabilityMask = $cm.Capabilities
10} | Format-List
11
12# Decode the workload bitmask.
13$map = [ordered]@{
14    1   = ‘Compliance policies’
15    2   = ‘Resource access policies’
16    4   = ‘Device configuration’
17    8   = ‘Windows Update policies’
18    32  = ‘Endpoint Protection’
19    64  = ‘Client apps’
20    128 = ‘Office Click-to-Run apps’
21}
22$map.GetEnumerator() | ForEach-Object {
23    [PSCustomObject]@{
24        Workload  = $_.Value
25        OwnedBy   = if ($cm.MDMWorkloads -band $_.Key) { ‘Intune’ } else { ‘ConfigMgr’ }
26    }
27} | Format-Table -AutoSize

What I would do

If you are on 2409 or earlier, the cadence change is not your problem. Being unsupported since June is. Get current first.

If you are current and co-managed, do nothing differently. Annual releases make your life easier, not harder. Use the extra room to move one workload properly rather than three badly.

If you are planning a full decommission, be honest about which of the three ConfigMgr strengths you actually rely on. If the answer is none of them, finish the migration. If the answer is any of them, permanent co-management is a supported end state and choosing it deliberately beats drifting into it.