A significant number of enterprise environments are going to live in co-management for years. Not because it’s the goal, but because it’s the practical reality of migrating a large Windows fleet from Configuration Manager to Intune without a full device refresh.
Co-management is the Microsoft term for running both Configuration Manager and Intune simultaneously on the same Windows device – each managing different workloads, with the organization controlling which platform owns what. It’s a transitional architecture, not a destination. But calling it transitional doesn’t mean it’s temporary in practice. Many organizations that entered co-management expecting to exit it quickly are still there years later, and designing for that reality produces a more stable environment than treating co-management as something to minimize or rush through.
Co-management works by enabling the Configuration Manager client on devices that are also enrolled in Intune. Workload sliders in Configuration Manager control which platform manages which capability – compliance policies, device configuration, endpoint protection, resource access policies, Windows Update policies, and client apps can each be set to Configuration Manager or Intune independently. This gives organizations the ability to move workloads incrementally, validating Intune management of each area before fully committing.
Workload sliders are the operational control in co-management. Moving a slider from Configuration Manager to Intune transfers ownership of that workload – policies from the other platform for that workload no longer apply. This is not reversible without consequences.
The workload migration sequence matters. Compliance policies are typically the first workload to move to Intune, because compliance is foundational to Conditional Access and Intune’s value as an enforcement layer. Without Intune compliance ownership, devices managed by Configuration Manager can’t participate in Conditional Access device compliance requirements. Moving compliance first unlocks the identity-based enforcement model while leaving other workloads in Configuration Manager temporarily.
Device configuration is usually the most complex workload to migrate because it involves the most accumulated policy history. Configuration Manager environments frequently carry years of baseline configurations, software deployments, and compliance settings that need to be assessed, translated or rebuilt in Intune, and validated before the slider moves. The GPO migration caution from Phase 1 applies equally here – importing Configuration Manager policy intent into Intune without reducing and reorganizing it creates the same kind of policy sprawl that makes environments hard to manage.
Client apps and software distribution are often the last workload to move, because Configuration Manager’s software distribution capabilities – particularly for complex packages, staged deployments, and content distribution to remote sites – are mature and deeply integrated into many organizations’ workflows. Intune’s Win32 app model handles most scenarios well, but the migration of a large software catalog requires careful prioritization of which applications move first and which stay in Configuration Manager until the organization is ready.
Co-management is not a failure state. It’s a deliberate architecture that lets organizations migrate at a pace that matches their operational reality rather than their ambition.
The cloud management gateway is a prerequisite for co-management to function for internet-connected devices. Without it, the Configuration Manager client can only reach the site server when the device is on the corporate network or connected via VPN. For organizations with remote workers – which is most organizations – this means co-managed devices off the corporate network effectively lose Configuration Manager management. The CMG extends Configuration Manager management to internet-connected devices through a cloud-hosted proxy, which is required infrastructure for co-management to work reliably at scale.
The exit strategy from co-management is the decision that most organizations defer too long. At what point does a workload move fully to Intune? What does “done” look like for the Configuration Manager client? Defining that endpoint early – even if it’s years away – shapes the migration sequence and prevents co-management from becoming the permanent default through inertia. The organizations that exit co-management cleanly are the ones that treated it as a migration mechanism with a defined endpoint, not as a long-term steady state.
Intune Deployment Guide · Phase 4: Provisioning
‹ Previous: [4.2] Provisioning without Autopilot
Next: [4.4] Windows Backup for Organizations: The Second Migration ›
