SCCM to Intune: why the migration is harder than Microsoft makes it look
Every Microsoft partner event has a slide showing the clean migration path from Configuration Manager to Intune. The reality in customer environments is considerably messier.
Let me describe a customer conversation I had last month.
They're a 600-user organisation, have been running SCCM (System Center Configuration Manager, now rebranded as Microsoft Endpoint Configuration Manager) since about 2014. It's deeply embedded. Software deployments, patch management, hardware inventory, OSD sequences for reimaging machines, software metering, compliance baselines. Seven years of technical debt in task sequences and collections.
They want to move to Intune. Microsoft's documentation and partner programmes make it sound achievable in a project. We're eighteen months in and we're not done.
This isn't unusual. Here's what it actually involves.
The app packaging problem
This is the thing that stops most migrations in their tracks. SCCM deployments typically use MSIs, application models, or PowerShell scripts in various states of documentation and currency. Intune primarily works with Win32 apps, wrapped in the IntuneWin format, or MSIX.
The wrapping process is straightforward. The problem is that you have to assess every application (you might have 200-400 in a mature SCCM environment) and determine:
- Is this app still needed?
- Is the version still supported?
- Does it have a modern installer available, or is it a legacy MSI from 2012 that requires special handling?
- Does it have dependencies that also need packaging?
- Does it have conflicts with other apps that need managing?
That's not a technical problem; it's a project management problem. It requires business involvement, application owners, and vendor engagement. Microsoft's migration docs don't cover this because Microsoft doesn't know your applications.
The co-management complexity
Microsoft's recommended path is co-management: run SCCM and Intune in parallel, gradually shift workloads from one to the other, until you can decommission SCCM. This is technically sound. In practice, it creates a period of genuine complexity where you have two management planes, policies from both systems potentially conflicting, and a support team that needs to know both.
Co-management is not a migration; it's a migration path. The migration takes longer because you have to run both systems while you move things across.
What actually works
I've learned to scope these projects based on what I can actually deliver, not what Microsoft's slide says:
Start with new devices. Get Autopilot and Intune working perfectly for new device onboarding before you touch the existing estate. This gives you a clean baseline and prevents the existing complexity from infecting your new deployment.
Don't try to migrate everything at once. Pick a pilot group, get them to full Intune management, learn from that experience, then expand. The knowledge you gain from the pilot is worth more than the time you spend.
Deal with the app packaging problem early. Don't let it be the thing that holds up everything else six months in. Run an app rationalisation exercise at the start of the project.
Set realistic expectations with the customer. The Microsoft slide shows eighteen months as a successful migration timeline. For a 500+ user organisation, that's often realistic. For larger or more complex environments, it's optimistic.
The technology isn't the hard part. The organisational change management and the sheer volume of existing complexity is the hard part. Microsoft's documentation doesn't prepare you for that because it can't. It's specific to your environment.
