Moving from Configuration Manager, often called SCCM or MECM, to Microsoft Intune is a change in how endpoints are operated. Start with the outcome: more reliable remote management, a simpler provisioning process or fewer dependencies on local infrastructure. This checklist helps IT teams scope the transition and prepare a useful conversation with an Intune consultant.
1. Build an inventory that supports decisions
A device count is not enough to estimate a migration. Record the business owner, importance and dependencies of each application and configuration area. An application used by a small specialist team may need more preparation than a widely deployed standard tool.
Decide what to retain, replace or retire. Copying every historical exception into Intune can reproduce the operational problems you wanted to solve.
- Devices: platform, join state, location, ownership and shared-use scenarios.
- Applications: owner, licence, installation method and dependencies.
- Configuration: group policy, certificates, VPN, Wi-Fi, printing and security controls.
- Operations: patching, reporting, recovery procedures and support ownership.
2. Agree workload ownership and the co-management approach
Co-management allows Configuration Manager and Intune to manage supported Windows devices together. Workload settings determine which platform manages specific capabilities, and a pilot collection can limit the initial transition. Tenant attach provides a different integration; seeing a device in the Intune admin centre does not establish that its workloads have moved.
Record the current and intended owner of each workload. Review overlapping policies as well: adding an Intune profile does not automatically remove conflicting settings from another management source.
- Select the first workload according to dependencies and business impact.
- Define the pilot collection, target groups and exclusions.
- Document the capabilities that will remain in Configuration Manager.
- Assess device join state separately from MDM enrolment.
3. Validate applications rather than just copying packages
Existing SCCM packages can provide useful source material. Each application still needs a review of silent installation, user or SYSTEM context, detection, prerequisites and restart behaviour. Validate upgrades from the installed version as well as installation on a clean endpoint.
Separate packaging checks from business acceptance. A successful installation result does not demonstrate that the user can open the application, reach its services and work with the required configuration.
- Test installation, upgrade and removal through the intended deployment process.
- Check detection before installation, after installation and after removal.
- Run functional checks with a standard user and the relevant network access.
- Document a workable recovery path for an unsuccessful rollout.
4. Choose a representative pilot and define its exit criteria
An IT-only pilot can miss the conditions that matter in production. Include different departments, device types, networks and working patterns. Agree the evidence needed before the next group is enrolled.
Use measures such as required application availability, correct compliance evaluation and the ability to complete business tasks. Set thresholds and an observation period that fit the organisation; a generic success percentage is not a substitute for risk assessment.
- Include remote work, limited connectivity and restart scenarios.
- Validate certificates, business applications and Microsoft 365 access.
- Give the service desk a support guide and track recurring incidents.
- Agree who can pause deployment and how affected users will recover.
5. Make operational handover part of the migration
Expand deployment only when the pilot provides enough evidence. Each group needs an owner, a verification step and a recovery option. Tell users what will change, what they need to do and how to get support.
Retiring Configuration Manager requires a separate dependency review. Remaining applications, updates, server management, reports and recovery processes may still rely on it. A device appearing in Intune is not a decommissioning criterion.
- Hand over targeting, exceptions and policy decisions to the operations team.
- Assign ownership for application updates, compliance and patching.
- Check remaining dependencies before retiring infrastructure.
- Record accepted limitations and the follow-up work still required.
What should you prepare for an initial scoping call?
Bring an approximate device inventory, the size of your application portfolio and a short description of the current management setup. Explain the deadline, available internal capacity and the issues that consume the most engineering time.
TechLake supports migration assessment, application packaging, pilot validation and implementation for organisations in Belgium. The first discussion establishes what your team will own and where additional endpoint engineering capacity will help.