Configuration Manager co-management with Intune

For organisations migrating from Microsoft Configuration Manager (formerly SCCM) to Microsoft Intune, co-management is the transition state where devices are managed by both at once — Configuration Manager for some workloads, Intune for others, with a clear path to gradually move workloads to Intune.

Why co-management exists

Many large enterprises invested heavily in Configuration Manager:

• Software distribution to tens of thousands of endpoints.
• OS deployment via task sequences.
• Patching with maintenance windows.
• Compliance reporting.
• Remote control.

Moving to Intune in one step isn't realistic. Co-management lets you keep ConfigMgr operational while progressively shifting workloads to Intune.

How co-management works

A device enrolled in co-management has both the ConfigMgr client and the Intune agent. Each workload — software, patching, compliance, etc. — is assigned to one tool at a time:

• Configuration Manager workloads (slider position "ConfigMgr") — ConfigMgr handles it.
• Pilot workloads (slider position "Pilot Intune") — Intune handles for a pilot group; ConfigMgr for everyone else.
• Intune workloads (slider position "Intune") — Intune handles tenant-wide.

The slider in the ConfigMgr console lets you progressively shift each workload to Intune at your own pace.

Workloads you can shift

The shiftable workloads:

• Compliance policies — define compliance in Intune instead of ConfigMgr.
• Resource access policies — Wi-Fi, VPN, certificates from Intune.
• Windows Update policies — Windows Update for Business via Intune (and Autopatch on top).
• Endpoint Protection — Defender Antivirus and ASR from Intune.
• Device configuration — most settings.
• Office apps — Microsoft 365 Apps deployment from Intune.
• Client apps — non-Microsoft app deployment.

Some workloads aren't shiftable today; the list expands over time.

Tenant attach

A precursor / companion to co-management is tenant attach — link your ConfigMgr hierarchy to Intune without enrolling devices into co-management. You get unified visibility in the Intune admin console of ConfigMgr-managed devices, with limited cloud-side actions. Useful if you're not ready for co-management but want a single inventory view.

The migration journey

A typical path:

1. Tenant attach ConfigMgr to Intune for visibility.
2. Enable co-management on a pilot device population.
3. Shift workloads progressively — usually starting with compliance, then Office apps, then patching, then device configuration.
4. Migrate Autopilot provisioning away from ConfigMgr OSD task sequences.
5. Decommission ConfigMgr when all workloads are on Intune and there are no remaining ConfigMgr-only requirements.

This journey is multi-year for large enterprises. Microsoft has continually invested in Intune feature parity, but specific scenarios (complex task sequences, specific software distribution requirements) still drive ConfigMgr usage.

When ConfigMgr stays

A few reasons ConfigMgr remains:

• Imaging and OS deployment at scale with custom task sequences. Autopilot covers most modern scenarios but not all.
• Servers — ConfigMgr manages Windows Server too; Intune is endpoint-focused.
• Air-gapped environments that can't talk to the Microsoft cloud.
• Investments in deep custom packaging that haven't been ported to Intune Win32 yet.

For most knowledge-worker endpoints, Intune-only is the strategic end state. Co-management is the bridge — designed to make the journey gradual rather than disruptive.