Moving from SCCM to Intune: a 6‑week pilot plan

What changes when you leave SCCM and why you need a pilot

SCCM (ConfigMgr) usually covers several functions at once: application and update deployment, Windows imaging, hardware and software inventory, reporting, remote actions and some security. When you move to modern device management (Intune), goals stay similar but approaches and control points change. More logic moves into cloud policies, and familiar scenarios need to be reassembled.

These areas typically behave differently:

• Application deployment. Instead of collections and task sequences you rely on groups, assignments and installation requirements.
• Windows updates. Rather than SCCM’s centralized cycles, Windows Update for Business and update policies play the key role.
• Provisioning new PCs. Instead of reference images and PXE many organisations move to Windows Autopilot and post-setup configuration.
• Inventory and reporting. Data is collected differently, reports look unfamiliar, and it’s important to know in advance which answers you need.
• Remote support. Tools and processes change: rights, auditing and expected response times.

A pilot is essential because the risk is not only technical. A wrong assignment or policy can impact people: VPN access may fail, a business app may not install, encryption might be enforced unexpectedly, and support will see a surge in calls.

A good pilot verifies not only “does Intune work” but whether the new model is sustainable in daily operations. In a mixed organisation (office, remote, branches) it’s especially important to ensure devices can be provisioned and repaired without visiting a central office.

Measure pilot success concretely:

• key apps install and update without manual steps;
• a new device becomes ready to work within predictable time;
• inventory and reports answer the needed questions (who, what, where, condition);
• support can handle common incidents under the new process;
• users barely notice the transition, aside from sensible improvements.

Pilot boundaries: devices, users, scenarios

Pilots often fail not due to technology but because boundaries are fuzzy. If you don’t agree up front which devices and people participate, which scenarios you test and what is out of scope, the team will start arguing mid-project and results won’t match expectations.

Pick 2–3 typical device classes that are actually used daily: office desktops, laptops for mobile work and a couple of touchscreen AIOs. If you have specialised workplaces (registration terminals, classrooms, uncommon peripherals), include one clear subtype to avoid drowning in drivers and exceptions.

Include users with different working conditions: office, one or two branches, several remote employees. Decide separately about privileged accounts; usually they are excluded from the first wave or included in a limited way with separate rules.

To keep the pilot manageable, document boundaries:

• which models and device classes participate and counts per group;
• which scenarios are tested (new issuance, replacement, updates, access to corporate resources);
• what is out of scope (rare apps, critical servers, nonstandard drivers, lab setups);
• change window (dates, times, who approves downtime and communications);
• rollback rules (when and how to return to previous management, who decides).

A simple example: 30 devices (20 desktops, 8 laptops, 2 AIOs) and 3 user groups (office, branch, remote). Everything outside this set is moved to the next phase, even if there’s pressure to “add one more case.”

Target model: co-management or full transition

The chosen model defines how the migration goes and how much risk you accept in the pilot. There are two basic paths: co-management (some workloads in SCCM, some in Intune) or full transition where Intune becomes the main tool and SCCM is retired.

Co-management is usually safer to start with: workloads are shifted gradually while critical processes remain where they are stable. Full transition is faster in the long run but requires stricter standards in the pilot: fewer exceptions, clearer device and app requirements.

It often makes sense to move items first that deliver quick value and rarely conflict with current settings:

• basic configuration policies (Wi‑Fi, VPN, Windows settings);
• compliance and conditional access checks;
• Windows updates via update policies;
• baseline protection (for example, Defender settings).

Main pilot risk is dual control. If the same settings are applied from SCCM and Intune, behavior becomes unpredictable: settings “flip,” reports diverge and users complain. Practical rule: each workload should have one owner and one single source of truth. Anything you’re not moving should be explicitly left in SCCM.

Keeping SCCM around makes sense if you have complex OSD and task sequences, local distribution points for large packages, offline segments or sites with unstable internet, and apps that cannot yet be reliably packaged for Intune.

A good pilot result is a clear workload matrix: what’s already in Intune, what remains in SCCM and why.

Team and roles: who’s responsible for what

Pilots fail more often from unclear responsibilities than from Intune itself. Agree in advance who makes decisions, who changes settings and who is accountable to users.

A minimal team usually includes:

• pilot owner (IT manager) — sets boundaries, schedule, time budget and final decision;
• MDM/Intune engineer — configures enrollment, profiles, policies, compliance and monitors configuration drift;
• application engineer — owns the catalog, packaging, dependencies, requirements and update plan;
• security specialist — approves baseline measures (encryption, passwords, Defender, conditional access) and agrees exceptions;
• helpdesk — takes tickets, records symptoms, escalates and verifies fixes.

To avoid breaking the pilot, define a simple change process. For example: the MDM engineer edits profiles only via a request; the app engineer publishes apps only after testing on 2–3 devices; exceptions (e.g. temporarily disabling a compliance requirement) are approved by security and the pilot owner.

Assign business sponsors from departments to choose participants, confirm app criticality and help manage feedback.

Provide a single feedback channel (email, form or chat) and document SLAs: pilot critical incidents — response within 2 hours, noncritical — within the business day. This reduces noise and makes results easier to measure.

Basic environment readiness before the pilot

Before starting the pilot, remove common technical blockers. If you skip preparation, the pilot becomes a post-mortem instead of a scenario check.

First, verify identities and access. Ensure pilot user accounts are active and groups (user and device) reflect your plan: who gets apps, who gets policies, who has admin access. Confusion between "device vs user" often breaks assignments in the first days.

Next — network. Devices must reliably reach cloud management services, and proxies or TLS inspection must not swap certificates on critical paths. With strict filtering, pre-approve exceptions for Windows autopilot services, app store access and compliance checks. Otherwise you’ll see "it works here but not there" failures.

Certificates and Wi‑Fi/VPN profiles deserve special attention. If you plan automatic network setup, decide how access is validated: certificates, credentials or hybrid. Prepare trust chains and verify devices can connect to Wi‑Fi before user sign-in if that’s required.

Define the security model from the start in a minimal form: who is Intune admin, who may change policies, how temporary rights are granted for the pilot, how test and production assignments are separated and where change logs are stored.

Example: in a branch some users work through a proxy with TLS inspection. Without agreed exceptions Autopilot may hang on registration and apps may not install. It’s better to uncover this in preparation than during week three.

Inventory: devices, apps, dependencies and reports

Inventory in a pilot is not for pretty tables — it shows what will break in migration: devices that aren’t ready, apps relying on rare installers, and security settings tied to local exceptions.

Start with an SCCM extract by device. For the pilot focus on Windows versions, join type (domain, hybrid, cloud), disk encryption status, client health and how often devices check in. A common issue: laptops in user hands report irregularly and distort the picture.

Analyse apps not just as a list but by context. For each app record the business owner, criticality, usage frequency, installer source and a clear update method. Risk often comes from single-person knowledge (e.g. an obscure browser plugin).

List dependencies separately: plugins, printer/scanner drivers, firewall rules, antivirus exceptions, certificates and local components (e.g. VC++ libraries). These items are often invisible in a simple list but break app launches.

Agree on the reports you need so business and security accept pilot results:

• pilot device coverage and percent successfully managed;
• compliance (encryption, password, updates);
• status of key app installations and errors;
• list of exceptions (antivirus, firewall) and who approved them;
• incidents: what failed to install and time to remediation.

Collecting this set up front makes the pilot measurable rather than a feeling of “it seems to work.”

Applications: packaging, deployment, updates

Pilots often fail because of applications. To migrate apps from SCCM to Intune, classify them: MSI, silent EXE, Store apps, PowerShell scripts. Browser extensions are often easier to manage via policies rather than installers.

You need a single packaging and detection standard. Without it you’ll get repeated installs, endless deployment attempts and messy reports. Agree on rules: consistent names and versions, a business owner, and a clear detection rule (file, registry or MSI product code). Record dependencies immediately, otherwise you’ll be troubleshooting "doesn’t start" instead of validating management.

Limit the pilot app set to daily essentials: office suite, 1–2 browsers, VPN client, video conferencing, security agent (EDR/AV/encryption depending on your stack).

Plan updates before first deployment. Decide who owns each version, how testing happens (e.g. on 10–20 pilot devices) and what rollback looks like. In SCCM rollback was often "reinstall by collection"; in Intune have the previous package ready and a clear rollback trigger.

Practical scenario: a VPN update causes some users to be unable to connect after reboot. With correct detection rules you can quickly separate "not updated" from "updated but broken" and rollback only the problematic group. These situations reveal whether the migration is ready for real load.

Images and device provisioning: from task sequences to Autopilot

In SCCM organisations often rely on custom images to bake in drivers, baseline settings and software. When moving to Intune, a different approach usually wins: a standard Windows image and policies/apps layered on top. Keep a custom image only for strict constraints, like offline deployment in closed networks or rare drivers that are hard to install post-setup.

For new devices the logic changes: use an Autopilot profile, automatic Entra ID join, naming rules and group assignment. The user powers on the device, signs in and the device receives needed policies and apps automatically.

For existing devices avoid interrupting the workday. Start with gentle enrollment, validate compatibility and migrate settings in stages: first baseline security, Wi‑Fi/VPN, then apps, and only after that stricter restrictions.

Replace task sequences step-by-step. Break them into stages (settings, apps, updates, post-configuration), move settings into Intune policies, software into Win32 packages, and implement conditional steps with groups and dynamic assignments. Decide how you’ll handle drivers and updates (Windows Update for Business, OEM tools). Accept that Autopilot cannot reproduce every SCCM pre-OS scenario one-to-one.

Policies, compliance and security in the pilot

Don’t migrate every SCCM policy verbatim. The goal is to ensure baseline security and manageability work reliably, and that compliance rules affect resource access as intended.

Start with a minimal, verifiable set that delivers clear outcomes:

• BitLocker: encryption enabled, recovery keys saved, removable media rules if needed;
• Windows Update: updates enabled, reboot windows communicated to users, critical patches delivered on time;
• Firewall: enabled on all profiles without unnecessary exceptions;
• Local administrators: a transparent list and exclusion of personal accounts;
• Baseline protection: enable built-in Windows security mechanisms without deep tuning on the first pass.

Then enable compliance and test its link to access. A practical pilot approach: if a device is unencrypted or out-of-date it can sign in, but access to email or internal apps is limited until remediation. This shows the value of control without paralyzing work.

Check Wi‑Fi/VPN profiles and certificates early — they often cause failures where a device appears managed but cannot connect.

For privileged users set stricter rules: separate devices for admin tasks, no default local admin, and require compliance before accessing critical consoles. For example, an admin may reach infrastructure consoles only from a device with encryption, up-to-date patches and firewall enabled.

Pilot example: a mixed organisation under real load

Imagine a pilot in a 200-device company: 150 office laptops, 30 in branches and 20 remote. This is a good cross-section: different networks, support channels and typical everyday tasks that break an "ideal" migration.

App reality usually looks like: 10 mandatory for everyone (browser, office suite, messenger, EDR, VPN), 15 on request (CAD, accounting, plugins) and several legacy/problematic apps. Mark problematic ones as risk: old MSI, custom installers without silent mode, apps requiring local privileges.

Small operational details visible only in live operation hurt the most. Build time into the pilot to test VPN (auto-connect, certificates, working offsite and after password change), printing in branches, drivers (docks, Wi‑Fi, cameras, scanners), legacy MSI behavior and real admin needs.

Organise support so the pilot doesn’t become chaos. Give participants one support path and log each incident uniformly: ticket template (device, network - office/branch/home, what changed, time), required logs (Intune Management Extension, install events, error screenshots), a "30 minutes diagnostics" rule and fast rollback to SCCM for critical roles if downtime is unacceptable.

If part of the fleet is locally manufactured (for example, GSE.kz), include them as a separate pilot group to surface driver and provisioning nuances before full scale-up.

6-week pilot plan: week by week

Run the pilot so each week you add exactly one new complexity and immediately record what breaks and how it was fixed.

Week 1. Close inventory: device models in pilot, critical apps, dependencies (VPN, certificates, drivers, plugins). Choose user groups (e.g. two departments and an IT group), assign roles (pilot owner, app packager, security, support), and prepare baseline policies and exception rules.

Week 2. Enroll the first 10–20 devices. Enable the minimum: enrollment, baseline profiles, email access and Wi‑Fi/VPN. Collect issues in one place and each day close 1–2 root causes rather than symptoms.

Week 3. Package and deploy the top 10 apps (the ones users need daily: office tools, browser, VPN, e-document solution). Configure updates and installation checks. Expand to 30–50 devices and test how support handles the request flow.

Week 4. Add Autopilot: new device flow and reimage flow. Expand to 1–2 branches to test network, time zones, local printers and offsite operation.

Week 5. Move additional workloads: complex apps, security policies, baseline hardening. Fix critical bugs (for example, VPN conflict with updates or a driver install failure).

Week 6. Gather metrics and decide on scaling. Document wave plans: who moves first, constraints and rollback plan. Example: include accounting only after 95% successful installs of their two key apps before the next wave.

Success criteria and metrics: how to know the pilot worked

A pilot succeeds when you have numbers and a clear path: either proceed to scale or return to remediation. Agree thresholds up front: which values are acceptable and which block rollout.

Devices and policies

Look beyond registration to time-to-ready. Useful metrics:

• successful enrollment and baseline policy application (percent of devices);
• time from first user sign-in to "all mandatory software installed";
• share of devices with policy or profile errors (and which errors repeat);
• number of manual IT interventions per 10 devices.

If 6 of 30 pilot laptops need manual fixes for the same policy, that’s a sign to redesign or add exceptions.

Applications, support and security

For apps measure not only install success but root causes: dependencies, rights, reboots, legacy versions. Track user tickets and their types. "Didn’t install" and "don’t know what to do" need different fixes.

Must-haves for security in the pilot:

• encryption is enabled and does not break workflows;
• compliance passes for most devices without mass exceptions;
• OS and security updates are applied on schedule;
• all deviations are documented as conscious exceptions, not “it just happened.”

A go/no-go decision is easiest with a table: passed, failed, fix-before-scale (with date and owner).

Common mistakes and how to avoid them

Failures usually start from small, unspoken things that grow into policy conflicts, install failures and user frustration.

First trap — dual management without clear boundaries. When the same setting is applied via SCCM (or GPO) and Intune devices get mixed commands. Settings flip, reports diverge and support can’t identify the source.

Set simple rules before the pilot:

• separate responsibilities: which policies/apps stay in SCCM and which move to Intune;
• use separate collections/groups for the pilot to avoid affecting others;
• pick 1–2 critical scenarios and stabilise them before expanding.

Second mistake — migrating apps without owners. Without an owner you often find missing installers, unknown licenses, unclear update rules and slow vulnerability response. Assign an owner to each pilot app and agree SLAs for releasing new versions and confirming compatibility.

Third problem — a pilot that’s too broad. Trying to cover every device type and all software usually delays everything. A representative subset is better: 2–3 PC models, 2 departments, 10–15 apps including one complex app.

Two more common causes: underestimated network and lack of rollback/communication plans. Example: an employee in a branch can’t enroll, apps fail to install and they lose a workday.

Minimum readiness: a 30–60 minute rollback scenario, a short user memo and a network check before the pilot (cloud service access, proxy, SSL inspection, peak-hour bandwidth).

Short checklist and next steps after the pilot

Before declaring the pilot successful, walk through a short checklist. It highlights everyday risks: installs, updates, encryption and support tickets.

What should be defined and verified before and during the pilot:

• roles assigned (pilot owner, app packager, security, support), pilot groups approved, app list and rollback rules;
• enrollment works, baseline policies apply, encryption and updates enabled, compliance is monitored;
• apps have detection rules, installation logging and an update procedure (who tests, where results are recorded, what to do on failure);
• support has a short guide: how to collect diagnostics, how to check device status and 2–3 recovery scenarios (e.g. reinstall corporate VPN or re-enroll device);
• a scaling plan is agreed and time for packaging remaining apps is budgeted (packaging is often over half the work).

After the pilot avoid a big-bang switch. Move in waves: for example 50 devices, then 200, then a whole office. If the pilot shows two critical apps install unstably, finish packaging and testing before expanding.

If you need help with the pilot and scaling, you can engage GSE.kz as a systems integrator to assist from planning and security policy to workstation/server preparation and 24/7 support organisation. Note: GSE.kz is mentioned as a vendor rather than a link.