Blog
SCCM to Intune migration: a phased playbook for cloud endpoint management
Plan an SCCM to Intune migration with phased workload switching, GPO migration, app packaging, pilot metrics, and decommissioning.
G2 Names Nerdio a Leader Across Fall 2026 Reports for Desktop as a Service Read the blog
Blog
Plan an SCCM to Intune migration with phased workload switching, GPO migration, app packaging, pilot metrics, and decommissioning.
Table of Contents
Your co-management sliders have sat on Configuration Manager for eighteen months, and the site server is aging out of support. Starting with Configuration Manager version 2609, releases shift to an annual cadence, and Microsoft's own guidance now names Intune as the future of device management and the place where all new innovation will occur.
This guide walks enterprise IT directors and endpoint management teams through a phased move from Configuration Manager (Microsoft Endpoint Configuration Manager, formerly called SCCM) to Microsoft Intune. An SCCM to Intune migration is a workload-by-workload handover through co-management. Group Policy rework, application repackaging, and provisioning usually set the timeline.
Many Configuration Manager estates that start a migration stop halfway, because co-management is comfortable enough to live in. Microsoft documents two on-ramps for Configuration Manager estates moving to Intune, and both lead to full migration:
Full migration slides every workload to Intune and uninstalls the Configuration Manager client through an Intune app configuration policy.
In Recast Software's State of Intune in 2026 report, a survey of 890 IT professionals, 62% of respondents manage devices with both Intune and Configuration Manager. Another 55% of Configuration Manager users have no plans or no timeline to retire the platform.
Enabling co-management changes nothing for users on its own, because Configuration Manager keeps managing every workload you haven't switched. Stopping there means running aging on-premises infrastructure while the remaining workload handoffs and decommissioning work are still ahead.
The Entra identity cleanup, Intune tenant configuration, and policy work you do for this migration also become the foundation for Windows 365 Cloud PCs and supported Azure Virtual Desktop session hosts, which enroll into the same Intune tenant.
Reaching that management plane starts with prerequisites many environments haven't fully cleaned up.
Three prerequisites shape how long the rest of the migration takes. Identity hygiene in Entra ID determines whether devices enroll cleanly, Group Policy analytics sizes the manual rework queue, and the July 2026 licensing changes decide what you actually pay to run Intune at scale.
Working through them before the first pilot enrollment prevents the schedule surprises that surface during workload switching.
Co-management requires devices to be Microsoft Entra hybrid joined or Microsoft Entra joined; co-management doesn't support devices that are only Entra registered. You also need Entra ID P1 or P2 licensing and Windows automatic enrollment turned on.
Microsoft's enablement docs warn that if you don't clean up stale devices in Entra ID before attempting co-management, devices can fail to enroll in Intune. Duplicate device objects appear when a machine registered earlier gets hybrid joined later. You usually meet them during the first pilot batch, when a handful of devices fail enrollment and each failure turns out to have a second object in Entra ID.
Group Policy analytics, built into the Intune admin center, imports GPOs exported as XML and scores each one with an MDM support percentage. It marks each setting ready for migration or identifies it as unsupported or deprecated. Practitioners have documented password policy GPOs at 14% MDM support, other policy sets at 36%, and drive-mapping GPOs at zero. Together, those results define the manual rework queue before pilot enrollment.
Low support scores widen the pilot scope because each unsupported setting needs an owner and a tested replacement. The migration tool doesn't support Group Policy Preferences, including drive mappings and registry keys, while the migration interface grays out AppLocker and firewall settings and moves them through the Endpoint Security workload instead.
Microsoft describes the one-click migrate feature as "best effort," so the transition from Group Policy carries a manual rework budget.
In July 2026, Standalone Intune Plan 1 runs $8.00 per user per month, but Microsoft 365 E3, E5, and E7, Business Premium, and the frontline F1 and F3 SKUs already include Intune Plan 1. Effective July 1, 2026, Microsoft also folded formerly paid Intune add-ons into the enterprise bundles:
| Bundle | Price (effective July 1, 2026) | Newly included Intune capabilities |
| $39.00/user/month (up $3.00) | Intune Plan 2, Remote Help, Advanced Analytics | |
| Microsoft 365 E5 | $60.00/user/month (up $3.00) | Everything in E3 plus Endpoint Privilege Management, Cloud PKI, Enterprise Application Management |
For a budget deck, E3's $3.00 increase is largely offset by add-ons that previously cost $3.50 to $5.00 per user per month each.
Moving management authority depends on settled identity and licensing, plus a clear inventory of GPO settings that will and won't translate.
Co-management exposes seven workloads, each with its own three-position slider. The middle position scopes the switch to a pilot collection. The last applies it to every co-managed device.
Microsoft's co-management FAQ states the general sequence of events: "Compliance is the workload that most customers switch first," and the most common workloads after that are Office Click-to-Run apps, Client apps, and Windows Update policies.
| Workload (slider: Configuration Manager, Pilot Intune, or Intune) | Watch for |
| Compliance policies | Lowest-risk first move; enables Conditional Access to cloud resources while existing Configuration Manager compliance checks still count |
| Windows Update policies | Existing Windows Update GPOs take precedence over the Intune CSP; they have to come off first. Windows Autopatch requires this workload on Intune and Configuration Manager client settings for software updates set to 'No' |
| Resource access policies | Configuration Manager deprecated these policies in version 2203; version 2403 blocks upgrade if old policies exist |
| Endpoint Protection | In Pilot Intune, policies deploy, but Intune doesn't remove them on unassignment until the slider reaches Intune |
| Device configuration | Switching it also moves Resource access and Endpoint Protection |
| Office Click-to-Run apps | When Intune installs an Office version, it remains at the later version even if you switch back |
| Client apps | Configuration Manager keeps its app deployment capability after the switch; both tools can deploy |
Microsoft's pre-switch requirement governs every row: "Before you switch any workloads, make sure you properly configure and deploy the corresponding workload in Intune." Move the slider only after the Intune policy is configured and confirmed on the pilot collection.
A common failure pattern in co-managed estates is the inverse. Intune policies report "Succeeded" while device behavior still follows Group Policy, because GPO wins over MDM for most settings when both are configured. MDMWinsOverGP applies only to settings in the Policy CSP, so conflicting GPOs must be removed. A Microsoft moderator's guidance on MDMWinsOverGP states: "We strongly recommend that you avoid using this policy setting."
Resolving conflicting GPOs can involve editing policies. Nerdio Manager for Enterprise backs up Intune policies when administrators edit them. Those backups give the team policy-level restore points for the weeks when settings change fastest.
Intune security baselines don't reach co-managed devices until the Device configuration workload sits on Intune. For cutover sign-off, the Intune admin center retains audit logs for 30 days, and forwarding them to Azure Monitor extends retention to 730 days.
Moving the sliders is typically not the primary schedule driver. Applications and provisioning set the calendar.
Applications and provisioning are where migrations actually spend their time. Application repackaging usually runs the longest, provisioning replaces the imaging process co-management doesn't cover, and two Configuration Manager dependencies keep running after both workstreams finish.
The same Recast Software report (previously cited) found that 37% of respondents named application packaging and deployment their top migration challenge, and that 49% of organizations still package Win32 applications manually.
For organizations with substantial Win32 packaging backlogs, application management sets the overall timeline. Intune's Win32 model caps dependencies at 100 per app and has no equivalent to Configuration Manager task sequences for multi-step deployments with conditional logic and mid-sequence reboots. Nerdio Manager extends this application workstream through unified application management across Windows devices.
Windows Autopilot configures an existing Windows installation after first boot and is a provisioning service. Provisioning therefore becomes the second schedule driver. Intune has no bare-metal imaging or PXE boot.
Microsoft recommends that on-premises domain-joined or hybrid-joined endpoints be reset and redeployed as part of a hardware refresh. Microsoft offers no in-place identity conversion, and no utility exists to convert those endpoints to Entra joined without a redeploy.
Two Configuration Manager dependencies keep running after applications and provisioning are complete. The first is patching. WSUS is deprecated but still supported in Windows Server 2025, and Windows Autopatch only takes over once the Windows Update policies workload sits on Intune.
The second is content distribution. Intune has no distribution-point equivalent, and Microsoft Connected Cache doesn't cache the OS WIM images that task sequences use.
Phase 4 covers the last stretch of the migration. Realistic timeline ranges frame what the whole program actually takes, Microsoft's recommended wave structure sets the pilot-to-production cadence, and Configuration Manager decommissioning becomes the final scheduling exercise once every slider reads Intune.
Published timelines vary widely, and the ranges below describe manual policy and application work. Practitioner numbers put mid-market deployments (500 to 5,000 devices) at 8 to 14 weeks and full programs at 9 to 18 months depending on size and complexity. Those hours go to inventory and owner identification, followed by exception handling. How many of your Win32 packages have a named owner today? Large-enterprise GPO migration alone runs 12 to 36 months.
Setup time itself compresses with tooling. L7 Solutions, a managed service provider, reported going "from 8+ hours per customer setup to near real-time deployment" after standardizing on Nerdio Manager and Microsoft Intune.
Microsoft's recommended rollout structure is wave-based. A limited pilot of roughly 50 IT users runs for about a month, then an expanded pilot, then a first production phase of about 2,000 users, with remaining groups following in waves. Microsoft ran its own internal migration through a transitionary stage in which devices kept SCCM installed with Intune running in parallel.
Two Configuration Manager deadlines land during this phase. Co-managed environments require Configuration Manager update 2603 before October 2026, when Microsoft deprecates an internal service used for device compliance checks. Without it, Software Center compliance checks can fail in co-managed environments where the compliance workload sits on Intune.
Configuration Manager's annual release cadence then begins September 2026 with a focus on stability rather than new features.
When every slider reads Intune and pilot metrics hold in production, devices without continuing Configuration Manager dependencies have the Configuration Manager client removed through an Intune app configuration policy, and site infrastructure reclamation starts.
After the team reclaims site infrastructure, it must manage the Cloud PCs and session hosts joining the Intune estate.
The Intune tenant you just matured for physical endpoints is the same tenant Cloud PCs and supported session hosts enroll into. Windows 365 lands on Intune from day one, Azure Virtual Desktop pulls in through Intune once host pools are configured for it, and both benefit from the policy discipline the migration built.
Windows 365 Enterprise Cloud PCs enroll into Intune automatically during provisioning, and Microsoft requires the Intune admin center as their management plane, so teams manage Windows 365 with Intune from day one.
Every policy you scoped to "All Devices" during migration will therefore land on Cloud PCs the day you provision them, unless you exclude them with an assignment filter on the Model property (starts with "Cloud PC"). Teams that built deliberate policy targeting during the migration should verify that filter is in place; where targeting stayed broad, policies can land on the first Cloud PC.
Azure Virtual Desktop can be managed through the Azure Portal, PowerShell, and Microsoft Intune. Azure Virtual Desktop session hosts enroll through Entra hybrid join with co-management, or through Entra join by enabling Intune enrollment ("Enroll the VM with Intune") at host pool creation. Microsoft has made Intune user-scope configuration for multi-session hosts generally available on Windows 10 and 11, while Windows Server session hosts remain outside Intune and keep Group Policy.
Many enterprises use Windows 365, Intune, and Azure Virtual Desktop together, with Intune managing Cloud PCs and supported session hosts. For teams running both cloud desktop services, Microsoft frames the goal as managing "Cloud PCs and physical devices side-by-side" in a single view.
Nerdio Manager centralizes Windows 365 management, Intune policy assignments, and Azure Virtual Desktop host operations in one console.
Nerdio Manager runs on top of native Microsoft services and adds the policy versioning and multi-environment console this migration keeps demanding. Whenever an administrator edits a policy in Nerdio Manager or in native Intune, Nerdio Manager backs it up automatically. Those versioned backups give the team policy-level restore points during the weeks when settings change fastest.
Brad Ransbury, Systems Administrator for the City of Corona, described the change in day-to-day work: "Before Nerdio, we had to jump through multiple clicks in Azure or even rely on PowerShell scripting. Now, it's just a few clicks in an intuitive GUI, and we're done."
For a team midway through decommissioning, the practical result is one console covering the estate they just rebuilt, with restore points for the policies still changing week to week.
The first quarter can follow this sequence.
Evidence from each pilot wave determines when sliders move. Configuration Manager decommissioning then becomes a scheduling exercise instead of a leap. As Configuration Manager settles into annual, stability-focused releases, each slider moves the estate toward where Microsoft ships new work.
Once the SCCM to Intune migration is complete and the Configuration Manager client comes off, Cloud PCs and session hosts start joining the same Intune tenant, and the management surface grows just as your team's Configuration Manager muscle memory stops applying. A management layer that spans Windows 365, Intune, and Azure Virtual Desktop shortens that learning curve.
Get a demo to see how Nerdio Manager works across your Windows 365, Intune, and Azure Virtual Desktop environment, or try it free in your Azure tenant.
Intune can replace SCCM for day-to-day Windows endpoint management, with specific exceptions. Configuration Manager remains the recommended tool for bare-metal OS imaging through task sequences, air-gapped environments, and Windows Server management, and Intune's Win32 app model has no equivalent for complex multi-step task sequences.
For programs relying on manual policy and application work, organizations can plan against 8 to 14 weeks for mid-market fleets, 9 to 18 months for full programs, and 12 to 36 months for large-enterprise GPO migration.
Co-management is a staged handoff in which Microsoft Intune and Configuration Manager manage the same Windows device. Seven workload sliders move authority gradually from Configuration Manager through Pilot Intune to Intune.
They stay under their current management authority until you switch the corresponding workload. Policies with MDM equivalents migrate through Group Policy analytics into Settings Catalog profiles, while applications must be assessed and, where needed, repackaged for a supported Intune app type such as Win32, LOB/MSI, MSIX, or Microsoft Store deployment.
Learn more about Nerdio Manager