Choosing between Intune and SCCM co-management: a decision record

The question this actually answers

Not "should we move to Intune" — that decision was already made. The real question was sequencing: co-management has seven workload switches (compliance policies, device configuration, endpoint protection, resource access policies, client apps, Office click-to-run apps, Windows Update policies), and flipping them in the wrong order creates more support tickets than the migration itself needed to.

The order that worked

Compliance policies first. Low risk — this workload determines what "compliant" means for Conditional Access, and running it from Intune while everything else stays on SCCM is a clean, reversible first step. Flip this and watch for two weeks before moving on.
Endpoint protection second. Similarly low-blast-radius, and it surfaces early whether your Defender/AV policy translation from SCCM baselines to Intune profiles was done correctly, before higher-stakes workloads depend on it.
Resource access policies (Wi-Fi, VPN, certificate profiles) third. Test thoroughly against a pilot group — a broken certificate profile silently breaks Wi-Fi for whoever it hits, and that's a support-desk-visible failure, not a background one.
Client apps — this is where most of the real work is, not the switch itself. Don't flip this workload until the SCCM-to-Intune app parity checklist (see the Autopilot migration playbook for the same exercise) is actually complete. Flipping the switch before app parity is done just moves the problem, it doesn't solve it.
Device configuration after client apps, once you've built confidence in profile deployment order and seen how Intune's policy conflict resolution behaves versus SCCM's.
Office Click-to-Run apps — genuinely low risk if you're already on Click-to-Run rather than MSI Office. If you're still on MSI Office, that's a separate, bigger migration to do first.
Windows Update policies last. This one has the most potential for estate-wide impact if misconfigured (rings, deferral, feature update pacing), so it goes last — by the time you reach it, you've built confidence in every other workload's Intune behaviour.

What we'd flip earlier next time

Endpoint protection and compliance policies could safely have been flipped in the same week rather than two weeks apart — the caution there turned out to be unnecessary given how low-risk both workloads are.

What we'd slow down next time

Client apps. The workload switch itself is simple; the app parity work underneath it was consistently underestimated in project planning, and rushing it to hit a workload-switch date created avoidable support load. Scope client app migration as its own workstream with its own timeline, not as a sub-task of "flip the co-management switch."

Signal to watch, regardless of order

Whatever workload you flip, do it against a pilot collection first and watch Intune's policy-conflict reporting (not just deployment success/failure) for two full patch cycles before expanding scope. A policy that deploys "successfully" but conflicts with a lingering SCCM baseline is a common source of intermittent, hard-to-reproduce device behaviour that doesn't show up as a deployment failure anywhere.