SCCM to Intune Migration Checklist (2026)

Short answer: do not treat an SCCM-to-Intune migration as a cutover weekend. Choose the required cloud-management features, co-manage a pilot collection, move supported workloads in stages, and keep the Configuration Manager client until every required Intune replacement has passed an agreed validation gate.

Microsoft now calls the on-premises product Microsoft Configuration Manager, although “SCCM” remains the search term most administrators use. This guide is an execution checklist for moving management authority. If you first need the product boundaries, read SCCM vs MECM vs Intune. This page deliberately does not repeat that comparison.

Pick the migration end state

“Move to Intune” can describe three different outcomes. Decide which one you actually want before changing a workload.

Microsoft’s Intune migration guide presents the same three broad choices. A permanent co-managed state is valid; success does not require removing Configuration Manager from every device.

Licences, platforms and administrative roles

• Configuration Manager: run a supported current-branch version.
• Cloud services: co-management requires Microsoft Entra ID P1 or P2 and Microsoft Intune. Confirm user entitlements and the current Configuration Manager co-management licensing rules before buying additional licences.
• Windows: use an Intune-supported Windows version. Co-management supports Microsoft Entra joined and Microsoft Entra hybrid joined devices.
• Intune tenant: set up Intune, set its MDM authority correctly and enable Windows automatic enrolment for the intended pilot.
• Roles: Microsoft documents Configuration Manager Full Administrator with All scope rights for enabling co-management. Creating Entra applications from Configuration Manager can require Global Administrator; use that highly privileged role only for the specific task. Intune policy and app work should use the appropriate least-privileged Intune RBAC roles.

Check whether Intune is already in your Microsoft subscription before adding licences. The site’s Intune pricing guide for Australia explains common bundle overlap, while Microsoft’s co-management prerequisites control the technical design.

Phase 1: Discover what SCCM is really doing

A migration fails when the project plan lists products but not dependencies. Export an inventory that answers who owns each workload, what it targets, how success is measured and what breaks if it disappears.

• Supported Windows clients, unsupported clients, macOS records and Windows Server devices
• Collections, maintenance windows, client settings and security scopes
• Applications, packages, dependencies, supersedence, install context and detection logic
• Task sequences, drivers, BIOS configuration and operating-system deployment
• Software update groups, automatic deployment rules and reporting obligations
• Configuration baselines, compliance items and remediation scripts
• Endpoint protection, firewall, encryption and attack-surface settings
• Microsoft 365 Apps configuration and update channels
• PKI, certificates, Wi-Fi, VPN, proxies and network-access controls
• Remote control, CMPivot, inventory, custom reports and service-desk workflows

Give every item a disposition: replace in Intune, retain in Configuration Manager, redesign, retire, or manage with another service. “Migrate all GPOs” is not a valid disposition. Microsoft advises using Group Policy analytics to identify settings that still matter rather than translating years of accumulated policy without reviewing the reason for each setting.

Phase 2: Define gates, rings and rollback owners

Create at least three collections or groups: lab, pilot and production. A useful pilot includes remote and office users, different hardware models, standard-user accounts, business-critical apps and a service-desk representative. Keep executives and single-purpose devices out until the standard build is stable.

For every workload, write the gate before you move it. A gate might require policy success on all pilot devices, no unresolved priority-one incident, equivalent reporting and a tested reversal. Name the person authorised to reverse the workload and the evidence they will use.

Phase 3: Prepare identity and cloud access

1. Confirm the Microsoft Entra tenant, verified domains, user synchronisation and licence assignments.
2. Choose a device identity model. Existing Active Directory-joined Configuration Manager clients commonly enter co-management as Microsoft Entra hybrid joined; new cloud-native devices should normally use Microsoft Entra join.
3. Enable automatic Intune enrolment for a pilot scope.
4. Test line-of-business applications and resource access on an Entra-joined device. Machine-based authentication, certificate delivery, file shares and legacy VPNs deserve explicit tests.
5. Plan internet content delivery. Remote Configuration Manager clients may still need a cloud management gateway or VPN for Configuration Manager functions.

Important: Microsoft’s cloud-native endpoint planning guide says there is no Microsoft migration utility that converts an existing on-premises domain-joined or hybrid-joined endpoint into Microsoft Entra join. Microsoft recommends reset and redeployment, often aligned with hardware refresh, for that identity transition.

That distinction prevents a common planning error: moving policy authority through co-management is gradual, while changing the device’s join state is usually a separate rebuild project.

Phase 4: Consider tenant attach for cloud visibility

Tenant attach synchronises selected Configuration Manager device information to the Intune tenant and makes supported actions available in the Intune admin center. It does not transfer management authority and is not a prerequisite for co-management. Use it when cloud visibility and remote actions meet your design; scope the initial connection and permissions deliberately.

• Attach only the intended collection first.
• Verify device counts, serial numbers, operating systems and last sync.
• Test a non-destructive remote action and confirm the audit trail.
• Document which data is now visible to each support role.
• Do not assume a device is Intune-managed merely because it appears in the Intune admin center.

Phase 5: Enable co-management for a pilot collection

Complete Microsoft’s co-management prerequisites, then configure automatic Intune enrolment for only the pilot collection. Enabling co-management does not automatically transfer every supported workload to Intune. Confirm each workload’s current authority and any version-specific exceptions. Microsoft describes the initial enablement as transparent to the end user, with no new client agent or reboot required because the Configuration Manager client is already present.

• Confirm the pilot device shows as co-managed in both consoles.
• Check its identity is Microsoft Entra joined or hybrid joined as designed.
• Verify Configuration Manager policy still applies before moving a workload.
• Capture baseline app, update, compliance and policy reports for comparison.
• Keep the supported workloads you plan to move at their existing authority until the co-management pilot itself is healthy.

Phase 6: Move workloads one at a time

Co-management exposes supported workloads individually. Use Pilot Intune for the test collection before selecting Intune for the broader estate. Account for dependencies: moving Device configuration also includes Endpoint Protection. The retired Resource Access workload is not another ordinary pilot slider. Choose the order from your actual dependencies rather than a universal migration sequence.

Microsoft’s co-management workload reference is the controlling list. Do not infer that a Configuration Manager feature has moved just because its nearest workload slider is set to Intune.

Phase 7: Build cloud-native provisioning for new devices

Once Intune policy and application delivery are stable, provision new Windows 11 devices with Windows Autopilot and Microsoft Entra join. Keep this as a separate workstream from converting existing device identity. New-device success is the cleanest proof that Intune can produce a usable endpoint without relying on a Configuration Manager task sequence.

Use Microsoft’s cloud-native endpoint planning guidance for the provisioning workstream. Prepare each application’s silent commands, detection, requirements, upgrade and removal checks before assigning it to the new devices.

Phase 8: Validate operations, not just policy status

1. Compare device inventory between Configuration Manager, Intune and Microsoft Entra ID. Explain every material mismatch.
2. Run application install, repair, upgrade and uninstall tests from an internet connection outside the corporate network.
3. Confirm quality and feature updates obey the intended deadline and restart experience.
4. Test a noncompliant device, remediation, and access recovery without using an administrator shortcut.
5. Validate encryption recovery, certificate renewal, Wi-Fi, VPN, remote support and service-desk escalation.
6. Measure help-desk volume and failed deployments through an agreed observation period.
7. Export reports required for audit or operational handover.

For portfolio or lab practice, document these gates as a project. The site’s system administration project ideas explains how to turn technical work into useful evidence rather than a list of products.

Phase 9: Exit Configuration Manager only when the evidence supports it

Moving every co-management slider is not the same as retiring Configuration Manager. Identify remaining server management, operating-system deployment, reporting, remote-control, inventory and application functions. Provide an owned replacement or keep Configuration Manager for those functions.

For a fully cloud-managed Windows client, remove the Configuration Manager client only after workload success, reporting, support ownership and rollback have been signed off. Microsoft’s migration guide includes client removal as a late step, after Intune is set up and workloads have moved.

Rollback plan

Configuration Manager lets you move a co-management workload back from Intune, but reversal might not undo changes already made. Microsoft gives the example that a newer Windows or Office version installed under Intune remains at that newer version. Treat rollback as restoring management authority, not time travel.

• Keep the Configuration Manager client and infrastructure healthy during the observation period.
• Retain the previous deployment and policy exports.
• Move only the affected pilot workload back to Configuration Manager.
• Remove or exclude the conflicting Intune assignment before restoring its Configuration Manager equivalent.
• Force policy sync through the supported consoles, then verify on the endpoint.
• Record residual app, version, encryption or identity changes that reversal cannot undo.

Migration troubleshooting

Frequently asked questions

Can Intune replace SCCM completely?

It can be the sole management service for suitable cloud-native Windows clients, but only after your applications, policy, updates, reporting, support and resource-access needs have replacements. Configuration Manager can also remain for servers or specialist on-premises workflows.

Do I need to move every workload at once?

No. Co-management is designed so workloads can move individually, through separate pilot collections, while Configuration Manager controls those that have not moved.

Does tenant attach make a device co-managed?

No. Tenant attach provides cloud visibility and supported actions. Co-management additionally enrols a Configuration Manager client in Intune and lets you move supported workload authority.

Can I convert a domain-joined PC to Entra join without resetting it?

Microsoft’s current cloud-native planning guidance says there is no Microsoft migration utility for that conversion and recommends reset/redeployment, commonly during hardware refresh.

Bottom line

The safest SCCM-to-Intune migration is a series of evidence-backed workload decisions. Inventory the real dependencies, choose whether tenant attach is useful, enrol a pilot into co-management, move a supported workload, validate the endpoint and keep a specific reversal path. Cloud-native provisioning comes after Intune proves it can deliver a complete working device, not before.

Sources reviewed 10 September 2026 against Microsoft Learn. Validate workload changes in an authorised pilot before production rollout.

Primary Microsoft sources

• Migration guide: Set up or move to Microsoft Intune
• Planning guide to move to cloud-native endpoints
• Co-management for Windows devices
• Switch co-management workloads to Intune
• Co-management workloads
• Co-management FAQ