Packaging knowledge
Moving SCCM packages to Intune
What survives the move from SCCM to Intune, what must be rebuilt and which order keeps the rollout moving.
Two models, one goal
Configuration Manager and Intune can manage the same devices side by side. Microsoft calls this co-management: the device has the ConfigMgr client and is enrolled in Intune, and you decide per workload which side holds authority. That is the usual route when not everything moves on one day.
For packaging it means: you do not rebuild everything at once, you move app management when the foundation is ready.
What carries over
The installer stays the same. What is new is the wrapping: install command, uninstall command, detection and return codes. An SCCM package that only knows a command and a program file often has no usable detection — that has to be defined anew.
Payload and silent parameters are usually reusable.
What is rebuilt
Four things are new: assignment (groups instead of collections), detection, return code handling and documentation. Treat these four as “migration” and you underestimate the work; treat them as a rebuild and you do too much.
Order and fallback
First bring devices into a manageable state, then a small pilot group, then workload by workload. For apps: start with packages that have no dependencies and uninstall cleanly.
Keep the old assignment available until the new one demonstrably works on enough devices.
Choosing the first packages
Good candidates: small MSIs, clear detection, no dependencies. Bad candidates: packages with unknown script logic, no documented uninstall, or nobody left who assigns them.
---