Frontline Mobile Migration to Intune: A Shift-Ready Operational Playbook

Migrating a frontline mobile fleet is not the same project as migrating corporate laptops. Shared handhelds in warehouses, retail, healthcare, and field operations have shift-based uptime requirements, certificate-dependent Wi-Fi, line-of-business apps with per-device licensing, and no tolerance for "enroll it tomorrow."

Microsoft's Intune Customer Success team published frontline-first migration guidance in March 2026. This playbook turns that guidance into sequencing you can run: infrastructure prerequisites, pilot rings by site, certificate and Wi-Fi ordering, app validation gates, and rollback paths that do not leave a shift without a working device.

Use with the Intune hub, Conditional Access policy map, and Intune device not syncing troubleshooting.

Who This Playbook Is For

Intune engineers migrating Android or iOS frontline devices from another MDM
Infrastructure teams responsible for Wi-Fi, RADIUS, and certificate services
Operations managers who own shift continuity during device changeovers
Identity teams aligning Conditional Access with newly enrolled shared devices

How Frontline Migration Differs From Laptop Migration

| Factor | Corporate laptop | Frontline mobile | |---|---|---| | Ownership | Usually one user per device | Shared across shifts | | Downtime window | Business hours with spare laptop | Minutes between handovers | | Network | Corporate Wi-Fi or VPN | Often certificate-locked store Wi-Fi | | Apps | Standard Office + LOB | Scanning, inventory, task apps with device binding | | Success metric | User productive same day | Device returned to pool functional before next shift |

Phase 0: Prerequisites Before Touching Devices

Confirm infrastructure before migration day:

| Prerequisite | Validation | |---|---| | Intune licences for frontline devices | Count devices + spare pool in scope | | Apple ABM / ASM or Android Enterprise enrolled | Corporate-owned enrollment path confirmed | | Intune Certificate Connector or NDES | Test certificate issued to lab device | | Wi-Fi and VPN profiles built in Intune | SCEP/PKCS profile deploys on lab hardware | | Conditional Access reviewed | Shared devices and break-glass accounts documented | | Source MDM export | Full device list, apps, profiles, certificates |

Do not start user migration until a lab device completes: enroll → receive Wi-Fi profile → receive cert → install critical LOB app → passes sign-in to required backend.

Phase 1: App And Profile Inventory

Application register

For each app on the source MDM platform:

| Field | Notes | |---|---| | App name | | | Platform | iOS / Android | | Deployment type | Required / available / kiosk | | Per-device license? | Some scanning apps bind to serial | | Store vs LOB package | Intune packaging path | | Offline requirement? | Warehouse dead zones |

Profile register

| Profile | Dependency | |---|---| | Wi-Fi (WPA2-Enterprise) | Certificate profile must deploy first | | VPN | Often certificate or per-app | | Restrictions / kiosk | May block enrollment if mis-sequenced | | Email / Teams | Usually after network connectivity confirmed |

Map dependencies explicitly. The most common frontline outage is Wi-Fi profile deploying before the device trusts the RADIUS certificate.

Phase 2: Certificate And Wi-Fi Sequencing

Recommended order:

Deploy trusted root and SCEP/PKCS certificate profiles to pilot group
Deploy Wi-Fi profile referencing the same certificate template
Confirm device connects automatically without manual cert install
Deploy VPN if required by LOB apps
Only then migrate enrollment from source MDM

Test on one device per site where RADIUS policy differs. Retail and warehouse SSIDs often use different VLANs and cert templates.

Phase 3: Pilot Ring Design

Ring 0 — Lab and IT

3–5 devices per platform (iOS/Android)
Full profile and app stack
Deliberate aeroplane-mode and Wi-Fi drop tests

Ring 1 — Single low-risk site

One store or warehouse with onsite champion
Migration window outside peak volume (not pre-holiday, not inventory week)
Spare device pool on site equal to 10% of fleet minimum

Ring 2 — Regional rollout

Repeatable runbook per site
Same-day rollback: re-enroll to source MDM or swap to spare if Intune path fails

Ring 3 — Enterprise completion

Only after Ring 2 shows < agreed failure rate (define upfront, e.g. 2% per site)

Phase 4: Migration Day Runbook (Per Device)

Remove device from source MDM (or wipe per vendor procedure)
Enroll into Intune via ABM/ASM or Android Enterprise workflow
Wait for Wi-Fi and certificate profiles — confirm connectivity before handing to worker
Confirm required apps show Installed in Intune
Worker signs into LOB app and completes one real transaction (scan, pick, clock-in)
Record serial, site, migration time, and technician in the register

If step 3 fails, swap to spare device and troubleshoot offline — do not hand a non-networked device to frontline staff.

Phase 5: Reliability And Rollback

Rollback triggers

Device cannot join store Wi-Fi within 15 minutes of enrollment
Critical LOB app missing or failing license check
Shared device login flow broken for next shift

Rollback options

| Option | When | |---|---| | Spare device swap | Fastest restore of shift continuity | | Re-enroll to source MDM | If migration window can extend | | Wipe and re-provision | If only Intune state is corrupt |

Keep source MDM licenses active until Ring 2 completes.

Reporting And Evidence

After each ring:

PowerShell

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

Get-MgDeviceManagementManagedDevice -Filter "operatingSystem eq 'iOS' or operatingSystem eq 'Android'" |
    Select-Object deviceName, operatingSystem, complianceState, lastSyncDateTime, managementAgent |
    Sort-Object lastSyncDateTime -Descending

Compare device count against site inventory. Gaps indicate incomplete enrollment or devices still on source MDM.

Prevention Checks

Maintain spare pool per site as operational standard, not migration-only
Version-control Wi-Fi and cert profiles; test before RADIUS cert renewal
Document per-app device licensing so Intune assignment groups stay accurate
Revisit Intune compliance not evaluating if shared devices show stale compliance

Source

This operational playbook is based on the official Intune Customer Success frontline migration post published by Microsoft on March 30, 2026, extended with certificate sequencing, pilot rings, and shift-continuity steps for enterprise administrators.