SCCM to Intune Migration: What Moves, and in What Order

An SCCM to Intune migration is planned as a cutover and delivered as a series of switches. The pages that rank for it stop at assess, pilot, migrate, decommission, which is a project plan rather than an answer, because it never says which workload is allowed to move on its own. There are seven workloads, three states each, and one slider that moves two others without saying so. Below is the order those constraints force, in Microsoft’s own words, and the places the documentation has gone quiet. This sits inside the wider question of Intune troubleshooting when the estate is co-managed.

One naming point first, because it decides what you find. The product is Microsoft Configuration Manager, and SCCM is the name practitioners kept. Microsoft’s documentation says Configuration Manager throughout, so a search for an SCCM to Intune migration returns vendor landing pages while a search for Configuration Manager returns the articles that actually constrain the work. That split is most of why the results for this question look like a buying decision rather than an engineering one.

What an SCCM to Intune migration actually moves

Co-management exposes seven workloads on the Workloads tab of the co-management properties page. The slider is the unit of migration. There is no per setting cutover, and nothing below the workload can be moved on its own.

Two of those rows are not independent, and that is the whole of the sequencing problem. Everything else in a migration plan is scheduling.

Three states, and the one that never cleans up

Each slider has three positions, defined as follows. Configuration Manager continues to manage the workload. Pilot Intune switches it only for the devices in the pilot collection, which is set on the Staging tab. Intune switches it for all Windows devices enrolled in co-management.

Pilot Intune is where migrations quietly rot. For Endpoint Protection and Device Configuration Policies, Intune only deploys the policies and does not perform policy removal upon unassignment. Removal requires the workload to be switched all the way to Intune. A pilot collection left in the middle state for a quarter therefore carries every setting anyone ever assigned to it, including the ones that have since been unassigned, and no blade in either console lists them as orphaned. That is a conflict generator rather than a pilot, and it is the state most likely to produce the symptoms covered in how an Intune policy conflict resolves.

Worth knowing before you plan around that article: Microsoft last updated the page that defines the three states on 21 March 2023. The workload reference beside it was last updated 12 May 2025. When a two year gap sits between two pages describing the same tab, assume the older one omits rather than contradicts, and verify behaviour in a lab before you rely on it.

The slider that moves two others

Device configuration is the widest control on the tab and it is presented as one of seven equals. Switching it also moves Resource Access and Endpoint Protection. Three consequences follow.

1. A policy created from the Settings catalog is controlled by the Device Configuration workload slider regardless of the contents of the policy. The slider does not inspect what the policy does.
2. Configuration Manager can still deploy settings after the switch, but only through the escape hatch: enable Always apply this baseline even for co-managed clients on a configuration baseline. That is the documented exception, and it is the one thing that keeps a compliance baseline alive through a migration.
3. Microsoft Defender Antivirus settings inside the Intune Device restrictions profile are not in scope of the Endpoint protection slider. Antivirus policy is a separate object with a separate lifecycle, so moving the Endpoint Protection workload does not move it.

The practical consequence is that Device configuration belongs at the end of the sequence, not the beginning. Most plans put it early because it feels like the core of device management. It is the last thing you should touch, because it is the only slider whose blast radius is three workloads wide.

The four routes Microsoft documents

The migration guide names four options for an estate already running Configuration Manager, and they are not degrees of the same thing.

1. Tenant attach. Included with the co-management licence. Surfaces Configuration Manager devices in the Intune admin centre without moving any workload.
2. Co-management. Workloads split between the two products, moved with the sliders above. This is a destination, not only a corridor.
3. Cloud only. Hybrid Microsoft Entra join, co-management, the workload sliders, then uninstall the client.
4. Start fresh with Microsoft 365 and Intune. Windows client devices only.

Two exclusions are stated plainly and are the ones that decide whether a clean break is even available. Option four does not apply to Windows Server, which should stay on Configuration Manager. Hybrid Microsoft Entra join supports only Windows, so macOS devices under Configuration Manager have to have the client uninstalled and then be enrolled, which leaves them temporarily unprotected. If the estate contains either, the answer is co-management for longer than the plan says, which is the case made in why co-management is a valid end state.

The licence gate is separate and often missed in costing. The co-management overview article, last updated 4 December 2024, requires Microsoft Entra ID P1 or P2 plus at least one Intune licence for the administrator, and notes that an Enterprise Mobility + Security subscription includes both. Where that sits against the rest of the bill is covered in the Microsoft 365 licensing rules that decide your bill.

The failure modes

These are the documented behaviours that read as faults on the day they happen.

Microsoft 365 Apps stop installing from Configuration Manager. A default global condition named Microsoft 365 apps managed by Microsoft Intune in version 2111 or later, or Are Office 365 applications managed by Intune on the device in 2107 and earlier, blocks the install. Co-managed clients that do not meet the condition do not install Microsoft 365 deployed via Configuration Manager. Nothing errors; the deployment simply never applies.

Updates arrive twice, or not at all. Moving the Windows Update workload does not reconfigure Configuration Manager. The client settings have to be adjusted manually, and for Windows Autopatch the Software Updates client setting must be set to No. Leave it and two update authorities compete, which produces the cancelling behaviour described in how Intune update rings cancel each other out.

Scripts run before you switched the workload. On Windows 10 version 1903 and later, PowerShell scripts still run on co-managed devices even if the Client Apps workload has not been switched to Intune. The delivery channel is the Intune management extension and what installs it, which is independent of the slider position. A script assigned during planning executes during planning.

Two app catalogues, both half right. After the Client apps switch, Intune available apps appear in Company Portal and Configuration Manager apps stay in Software Center. Users have two front doors and no indication which one holds what. Repackaging is also not a migration step that any tooling performs for you: a Win32 package needs its original source files, the same constraint described in Intune Win32 app deployment.

Operating system deployment has no row. The migration guide lists routes for MDM, third party MDM, Group Policy, Basic Mobility and Security and tenant to tenant moves. It names no replacement for task sequences. That absence is the answer: imaging is not migrated, it is abandoned in favour of a different model, and the guide does not pretend otherwise.

To establish what a given device currently believes, read its co-management state rather than the console’s view of it.

1# Read the co-management state a Windows client is actually reporting.
2# Run locally, elevated. ComanagementFlags is the bitmask of switched workloads.
3Get-CimInstance -Namespace root\ccm\ComanagementInfo -ClassName CCM_ComanagementInfo |
4  Select-Object ComanagementFlags, MDMEnrolled, HybridAADJoined

What I would do differently

Three things, and the first costs nothing.

Move Compliance policies first and Device configuration last. Compliance is the only workload in the list with no stated coupling and no stated residue, which makes it the cheapest way to prove enrolment, licensing and assignment all work end to end. Device configuration is last because it takes two workloads with it.

Treat Pilot Intune as a stopwatch rather than a state. It exists to prove a policy applies, not to run an estate. Given that it deploys without removing, a pilot that outlives its purpose leaves settings behind that nobody can enumerate.

Decide early whether co-management is the destination or the corridor, and write the answer down. An SCCM to Intune migration planned as a corridor but delivered as a destination is the most common shape I see in public write-ups, and it is not a failure; it is just an outcome nobody budgeted for. If the estate holds Windows Server or macOS clients, Microsoft’s own exclusions have already decided it for you.

Primary sources, verified on the date below: Co-management workloads, Switch co-management workloads, and Migration guide to Microsoft Intune.

Last verified: 16 October 2026. I have not run this in production; my tenant is a lab with no enrolled devices, so everything above is what the documentation states and where I would expect it to bite.