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
Certificate delivery appropriate to the chosen CA	Validate AD CS connector/NDES, third-party CA or Cloud PKI requirements; these are different architectures
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 a site migration until an Intune-enrolled pilot has obtained its trusted roots, client certificate and Wi-Fi configuration over an approved bootstrap connection, then installed and validated its critical apps. Intune cannot deliver these profiles to a device that is only enrolled in the source MDM. See trusted profile dependencies and SCEP infrastructure choices.

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 pilot sequence:

Prepare matching trusted-root, client-certificate and Wi-Fi profiles in Intune; validate CA/RADIUS dependencies and permissions.
Preserve source-MDM configuration, required application data and a working spare. Confirm the platform's supported migration method, reset requirements and recovery access.
Move an approved pilot device into Intune using a bootstrap network or cellular path that remains usable without the old MDM certificate.
Verify certificate issuance, server trust and Wi-Fi profile delivery. Intune assignment order alone is not a guaranteed delivery order.
Prove production Wi-Fi/VPN and application access before removing the bootstrap path or handing over the device.

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)
Size the spare pool from shift demand and observed pilot failure/recovery duration; 10% is only an example planning assumption

Ring 2 — Regional rollout

Repeatable runbook per site
Recovery: use a validated spare first; re-enrolment to the source MDM may require a reset and cannot be promised within the same shift

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)

Follow the approved platform-specific migration procedure; preserve required data, verify recovery/activation access and obtain change approval before any retire or wipe
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 authorised test transaction in the application’s test workflow (avoid creating a real order or clock entry merely to validate)
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'" -All |
    Select-Object deviceName, operatingSystem, complianceState, lastSyncDateTime, managementAgent |
    Sort-Object lastSyncDateTime -Descending

Compare device count against site inventory. Investigate gaps before declaring incomplete enrolment: reconcile device IDs, paging, ownership and reporting delays. The Graph example reads management metadata and requires an approved SDK installation and consented read permission.

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.

Correction record

10 September 2026 — Reviewed against documentation: Corrected certificate delivery before enrollment, bootstrap connectivity, delivery-order assumptions, destructive migration safeguards and paged inventory.