Co-management workloads, and moving one slider at a time

Co-management attaches a Configuration Manager-managed Windows device to Intune as well, so both can manage it. It is the sensible route out of a mature Configuration Manager estate, because it does not require a rebuild, a migration project or a cutover weekend.

The mechanism that makes it safe is also the one people misunderstand: each workload has exactly one management authority at a time. Not both. Not most-restrictive-wins. One.

Requirements

Configuration Manager and Intune, with the device enrolled in both. The device is Configuration Manager-managed, joined to Entra ID — hybrid or cloud — and enrolled in Intune.

Entra ID joined or hybrid joined devices. Hybrid join requires the directory synchronisation to be healthy, which brings in everything in hybrid identity failure modes.

Licensing for both. Co-management is not a way to use Intune without licensing it.

A pilot collection. This is the control that makes the whole approach safe, and it must exist before you move anything.

The workloads

Co-management supports these workloads:

• Compliance policies — the rules a device must meet to be considered compliant, which is what Conditional Access evaluates.
• Windows Update policies — update rings and deferral behaviour.
• Resource access policies — certificates, Wi-Fi, VPN and email profiles.
• Endpoint Protection — antivirus and related protection.
• Device configuration — settings and configuration profiles.
• Office Click-to-Run apps — Microsoft 365 Apps installation and updates.
• Client apps — application deployment.

Each has three positions: Configuration Manager keeps the authority, Pilot Intune moves it only for devices in the nominated pilot collection, and Intune moves it for every co-managed device.

Two details worth knowing because they surprise people:

• A policy created from the settings catalog is governed by the Device configuration workload, regardless of what the policy actually contains. The slider that matters is determined by the policy type, not by the settings inside it.
• Moving Office Click-to-Run apps to Intune makes Intune the authority for Microsoft 365 Apps and their updates. That is a larger change than the workload name suggests.

Design: the order to move them in

Move in increasing order of blast radius. My preferred sequence, with reasoning:

1. Compliance policies. Frequently the first, because it is what Conditional Access needs and because the failure is visible and reversible. Be careful about one thing: if compliance moves to Intune and no Intune compliance policy is assigned, the device’s compliance state depends on your tenant’s setting for devices with no policy assigned. Get that right first, or you can mark an estate non-compliant and lock it out of resources through Conditional Access.

2. Windows Update policies. Visible, reversible, and a good test of whether your Intune configuration is doing what you think. The risk is devices sitting under no effective update policy during the transition, so confirm the Intune rings are assigned before moving.

3. Resource access policies. Certificates, Wi-Fi and VPN. Higher stakes, because a device that loses its certificate loses network access — and may then be unreachable by either management system. Pilot this carefully and make sure your pilot includes a remote worker, not only a device on the corporate network.

4. Endpoint Protection. Moving antivirus management. Verify that policy actually applies before assuming protection continues as configured.

5. Device configuration. The broadest workload, and the one most likely to surface the conflicts described in Intune policy conflicts. Expect this one to take the longest and to reveal settings nobody knew Configuration Manager was applying.

6. Client apps. Application deployment, which usually means repackaging for Intune Win32 deployment — the largest body of work in the whole programme. The detection rule discipline in Intune app deployment is what makes this survivable.

7. Office Click-to-Run apps. Often last, because Configuration Manager handles it well and there is little urgency.

One at a time. The entire value of the slider model is that it isolates change. Moving two workloads together means a problem has two candidate causes, and you lose the ability to roll back cleanly.

Deployment: the pilot mechanism

The Pilot Intune position is what makes this safe, and it should be used for every workload without exception.

1. Create a pilot collection with devices that are representative rather than convenient. Include at least one remote device, one device belonging to a person who will report a problem clearly, and one device with an unusual configuration.
2. Configure the equivalent Intune policy for the workload, assigned to the pilot devices, before moving the slider. A workload moved to Intune with no Intune policy assigned means the devices are managed by nothing for that workload.
3. Move the slider to Pilot Intune.
4. Verify on the pilot devices that the Intune policy applies and behaves as the Configuration Manager policy did.
5. Wait. A week at minimum. Long enough for a Windows Update cycle, a certificate renewal, or whatever the workload’s natural period is.
6. Expand the pilot collection in stages rather than jumping to the full slider.
7. Move to Intune once the expanded pilot has been stable.

Step 2 is the one that gets skipped, and it is the one that produces incidents.

Validation

For each workload, confirm three things:

• Intune is applying the policy. Per-setting status, not profile status.
• Configuration Manager has stopped applying its version. The device should no longer be receiving that workload’s policy from Configuration Manager. Confirm this rather than assuming the slider did it.
• The end result on the device is what it was before. The actual setting, the actual update behaviour, the actual certificate. Not the console’s opinion.

Check the co-management dashboard in the Configuration Manager console for enrolment status and workload distribution. It is the authoritative view of which devices are co-managed and which authority holds each workload.

Rollback

Move the slider back. That is the rollback, and its availability is the strongest argument for the pilot approach — but it is not instantaneous, and devices need to check in and receive the change.

Two cautions:

• Devices offline during the change are in an indeterminate state until they check in. For a workload like resource access policies, a device that has lost its certificate may be difficult to reach, so plan the rollback path for devices you cannot easily contact.
• Rollback does not undo side effects. If moving Office Click-to-Run apps to Intune caused a reinstallation or an update, moving the slider back does not reverse it.

Operations

Keep the Configuration Manager infrastructure healthy throughout. Co-management is a transition, and during it you are dependent on both systems. Letting the Configuration Manager site decay because you are moving to Intune leaves you with two partly working systems.

Do not leave the transition half-finished indefinitely. A long-lived split is a genuine operating cost: two consoles, two policy models, and a permanent question about where any given setting lives. Have a target end state and a date.

Document which workload is where, with dates. When troubleshooting a device six months later, the first useful question is which system is the authority for the thing that is broken, and nobody will remember.

Verification and limits

The seven co-management workloads, the three slider positions, the settings catalog being governed by the Device configuration workload, and Office Click-to-Run apps covering both installation and updates were checked against current Microsoft documentation on 20 September 2026. The ordering and the pilot discipline are my own practice.

No workload was switched for this article. Moving a slider transfers management authority for every device in scope at once — configure the Intune policy first, always use Pilot Intune, and move one workload at a time. Workload behaviour changes between Configuration Manager releases, so confirm the current list and behaviour for your site version.

References

• Co-management workloads
• Co-management for Windows devices
• Switch co-management workloads
• Troubleshooting co-management workloads