Switching Co-Management Workloads to Intune: Pilot Collection First, Never All Seven at Once

On a Friday afternoon, an admin opens the co-management properties in the ConfigMgr console, moves the Device configuration slider from Configuration Manager straight to Intune, and clicks OK. No pilot collection, no staged test — the change applies to every co-managed device in the organisation at once. By Monday morning, help desk tickets are piling up. USB restrictions that used to come from a GPO baseline are gone. A registry-enforced browser setting nobody had rebuilt in Intune has silently stopped applying. BitLocker enforcement nuances that lived in a ConfigMgr configuration baseline for three years are no longer being pushed to anything. Nothing crashed. Nothing threw an error. The devices just quietly stopped being told to enforce settings that only ever existed in Group Policy or a ConfigMgr baseline — and thousands of them did it overnight.

This is the single most common real-world failure in co-management rollouts, and it's entirely avoidable. Microsoft documents a staged, pilot-first process for exactly this reason. This post walks through why switching all seven workloads at once for your whole estate is a bad idea, how the pilot-collection mechanism is actually supposed to work, and gives you a read-only PowerShell script that reports which devices sit in your pilot group versus everything else, and what workload authority state Graph can actually see for each of them.

The problem

Co-management lets you split management authority for a Windows device across two tools at once: Configuration Manager continues to manage whatever you haven't switched, and Intune takes over whatever you have. There are exactly seven switchable workloads: Compliance policies, Windows Update policies, Resource access policies, Endpoint Protection, Device configuration, Office Click-to-Run apps, and Client apps. Each one has its own slider on the Workloads tab of the co-management properties, and each slider has three positions: Configuration Manager, Pilot Intune, and Intune.

The failure mode isn't really about co-management itself — it's about what happens when the Device configuration workload is switched to Intune before an equivalent Intune configuration profile exists for every setting the organisation actually depends on. Microsoft's own documentation is specific that switching Device configuration also moves the Resource access and Endpoint Protection workloads with it — so a single slider move can silently reassign three workloads' worth of authority in one action.

Microsoft does document one legitimate escape hatch: you can keep deploying a specific ConfigMgr configuration baseline to co-managed devices even after Intune becomes the device configuration authority, by enabling Always apply this baseline even for co-managed clients on that baseline's properties. This is explicitly meant for settings your organisation requires that Intune doesn't yet support. But it has to be configured deliberately, baseline by baseline, before the switch — it isn't a safety net that appears automatically.

Why it happens

The pilot mechanism exists specifically to catch this class of problem before it reaches your whole estate, and it's built directly into the co-management properties pages — it isn't something you have to bolt on separately.

Each workload's slider on the Workloads tab has three settings, and the middle one is the one people skip:

• Configuration Manager — the default. ConfigMgr keeps managing this workload for every co-managed device.
• Pilot Intune — Intune becomes the authority for this workload, but only for the devices that are members of that workload's pilot collection. Every other co-managed device is untouched.
• Intune — Intune becomes the authority for this workload for every Windows device enrolled in co-management, organisation-wide.

The pilot collection itself is set independently, per workload, on the Staging tab of the same properties page — you can run a different pilot collection for Device configuration than the one you use for Compliance policies. That granularity is the entire point: it lets you validate one workload, on a small, known set of devices, completely independently of every other workload and without touching production.

There's also a behavioural difference between Pilot Intune and Intune that catches people out even when they do use a pilot collection correctly: when Pilot Intune is selected for Endpoint Protection or Device configuration policies, Intune only deploys the policies — it doesn't perform policy removal on unassignment. Full removal-on-unassignment behaviour only happens once the workload is switched to Intune (org-wide) rather than Pilot Intune. That's a deliberate safety behaviour during the pilot phase, but it means your pilot testing won't fully exercise policy-removal edge cases — worth knowing before you assume the pilot proved everything.

Skipping the pilot phase and switching straight to organisation-wide Intune authority means the first time anyone finds out a setting is missing is when it's already missing on every device that matched the co-management criteria — not a controlled group of twenty test machines.

There's a scale argument here too, separate from the missing-settings problem. A pilot collection is normally a few dozen devices, hand-picked to represent your real hardware and software mix — a mix of laptops and desktops, a few different driver sets, whatever line-of-business software actually gets in the way of policy enforcement in your environment. Production, by contrast, might be five thousand devices spread across multiple sites, VPN conditions, and OU structures you inherited from three different reorganisations. Any assumption you made about how a workload behaves — timing of policy application, interaction with existing GPOs, how quickly Intune actually catches up once ConfigMgr stops enforcing something — gets tested at a completely different order of magnitude the moment you move a slider to organisation-wide Intune. A pilot collection is the only mechanism co-management gives you to find out which of those assumptions were wrong before the blast radius includes your entire estate.

How to verify

Before touching any slider, confirm two things: which workloads are currently under which authority, and which collection is configured as the pilot for each one.

On the co-management object's Properties page: the Workloads tab shows every slider's current position (Configuration Manager / Pilot Intune / Intune) for all seven workloads, and the Staging tab shows which collection is currently assigned as the pilot for each workload that supports one. If you're on version 2103 or earlier, this same properties page is under the Co-management node instead of Cloud Attach.

Microsoft Graph exposes a per-device property called configurationManagerClientEnabledFeatures on the managedDevice resource, with boolean flags including compliancePolicy, resourceAccess, deviceConfiguration, and windowsUpdateForBusiness, alongside modernApps and inventory. These flags reflect whether the ConfigMgr client on that device currently has each of those features enabled — which is the closest read-only signal Graph gives you to "who currently owns this workload for this device," without needing console access.

The fix

The staged rollout itself is straightforward once you commit to doing it workload by workload, starting with the lowest-risk workloads and treating Device configuration as the one that needs the most preparation before it ever touches a slider.

For Device configuration specifically, don't rely on memory to know what GPO or ConfigMgr baseline settings are actually in force today. Export the real list first, then confirm each one has an Intune equivalent before the pilot collection ever sees the slider move — the point of the pilot isn't to discover missing settings, it's to confirm the settings you already rebuilt behave correctly on real hardware.

A practical way to build that "settings in force today" list without relying on tribal knowledge: run Get-GPOReport against every GPO linked to the organisational units your co-managed devices sit in, and separately export every ConfigMgr configuration baseline's referenced configuration items. Cross-reference both lists against your existing Intune configuration profiles and settings catalog policies. Anything that appears in the GPO or baseline export but has no matching Intune policy is a gap — and it's exactly the kind of gap that switches from "documented risk" to "live incident" the moment the Device configuration slider moves to Intune for a device that depends on it.

Proof it worked

"It worked" here means two things: the pilot collection's devices show the expected workload authority, and every other co-managed device is untouched until you deliberately widen the rollout. The companion script below reports both, using Microsoft Graph, without changing anything on any device.

References

• Switch co-management workloads — Microsoft Learn
• Co-management workloads reference — Microsoft Learn
• Paths to co-management — Microsoft Learn
• managedDevice resource type — Microsoft Graph v1.0