SCCM to Intune Migration: The Step-by-Step Guide for 2026

Why migrate from SCCM to Intune in 2026

System Center Configuration Manager (SCCM, later MEMCM and then Configuration Manager) is still the backbone of Windows endpoint management in most large Quebec organizations. It works, it's mature, it knows everything. So why migrate?

There are three solid reasons in 2026: most work now happens off the corporate network (remote work, mobility), yet SCCM is built for devices connected to the LAN; Microsoft's newer security mechanisms (Defender for Endpoint, Conditional Access, Zero Trust) are natively orchestrated through Intune; and rolling out Windows 11 with Autopilot is dramatically simpler through Intune.

But migrating doesn't mean "tear everything down and rebuild from scratch." Microsoft designed two mechanisms - Cloud Attach and Co-management - precisely to enable a gradual transition, one workload at a time.

The three possible approaches

Depending on your maturity and your constraints, there are three possible paths:

• Cloud Attach (fast, low risk): SCCM stays in charge of everything; you simply attach the Azure AD tenant to gain cloud capabilities (Endpoint Analytics, Conditional Access based on SCCM compliance). No operational changes.
• Co-management (the preferred route): SCCM and Intune manage devices jointly, and you shift workloads from SCCM to Intune one at a time. During the transition, Intune takes authority over each workload you move.
• Intune Full Cloud (the end state): every workload is managed by Intune and SCCM is decommissioned. New devices are provisioned through Windows Autopilot and never touch SCCM.
• Our default recommendation: Cloud Attach → gradual Co-management → Intune Full Cloud, over 9 to 18 months depending on size and complexity.

Phase 1 - Cloud Attach (2 to 4 weeks)

Cloud Attach is the simplest step: you connect the SCCM site to the Azure AD tenant through the Cloud Management Gateway and turn on co-existence. Nothing changes on the devices - they keep receiving their policies from SCCM.

Immediate benefits: Endpoint Analytics (visibility into fleet health), Tenant Attach (you can see your devices in the Intune console without them being managed there), and the ability to trigger Intune actions on SCCM-managed devices.

Technical prerequisites: Configuration Manager Current Branch version 2002 at minimum for Tenant Attach, and version 2111+ for full Cloud Attach (2309 or newer is recommended to get the latest capabilities). Azure AD Hybrid Join must be operational, and Cloud Management Gateway DNS resolution is required.

Phase 2 - Co-management, workload by workload

Once Cloud Attach is in place, you start shifting workloads. Microsoft defines seven main ones (sometimes listed as eight, depending on whether the Office Click-to-Run apps are counted with Client apps or separately), and each can be migrated independently:

• Compliance policies (usually migrated first - low risk, with an immediate Conditional Access payoff).
• Device configuration (BitLocker policies, Edge configuration, Defender, and so on).
• Endpoint protection (Defender for Endpoint, antivirus).
• Resource access policies (Wi-Fi, VPN, certificates).
• Windows Update policies (Windows Update for Business → no more on-prem WSUS).
• Office Click-to-Run apps (Microsoft 365 Apps deployment through Intune).
• Client apps (the most complex - Win32 app repackaging).
• Office macros and add-ins.
• Recommended approach: one workload every 2 to 4 weeks, with a pilot on 50 to 100 devices before the broad rollout. Save the complex workloads (client apps) for last.

Phase 3 - Application repackaging

This is where the migration slows down the most. SCCM has relied on .msi packages and custom applications for 15 years. Intune uses a different format: the Win32 app (.intunewin), created with the Microsoft Win32 Content Prep tool.

Our method: extract the SCCM application inventory (often 200 to 800 applications in a large organization), rank by how heavily each is used (how many devices have it installed), repackage the top 80 applications by usage (covering 95% of users), retire obsolete applications, and handle the long tail for the rest.

For complex applications (Adobe Creative Cloud, AutoCAD, in-house line-of-business apps), we use PSAppDeployToolkit (PSADT), which remains the go-to tool - it works just as well under Intune as it does under SCCM.

Intune governance: the classic pitfalls

Intune is not SCCM. Operational habits have to evolve:

• No boundaries: Intune runs over the internet, not the LAN. Rethink large-scale distributions (a 4 GB patch × 5,000 devices at once does not behave the same way on the network).
• No dynamic collections built from SQL queries: you use dynamic Azure AD groups with a different syntax. Plan a training session for your SCCM operators.
• A declarative model: Intune doesn't push, it declares the desired state. The device pulls its policy at the next check-in (every 8 hours by default). There's no instant "refresh policy."
• Reporting is less rich out of the box: Endpoint Analytics plus the Power BI Intune Data Warehouse partly close the gap, but they need to be set up.
• The co-management toggle: in practice, a workload you've moved is hard to move back to SCCM. Always validate with a broad pilot before the full rollout.

From the field: 1,200 devices in 9 months

An illustrative engagement: a large Quebec firm with 1,200 users (professional services, SCCM infrastructure in place since 2014).

Timeline: 1 month for Cloud Attach plus Endpoint Analytics. 2 months piloting co-management on 80 IT and power-user devices. 4 months gradually shifting the 8 workloads, two at a time. 2 months wrapping up: decommissioning WSUS, repackaging the final 60 applications, and training Tier 1 support.

Result at 12 months: Intune Full Cloud on every device, SCCM decommissioned, and Autopilot operational for all new devices (zero-touch deployment). Time to provision a new device dropped from 4 hours to 35 minutes. The number of SCCM/WSUS/MDT servers to maintain went from 6 to 0.