Migrating frontline mobile devices: Aligning stakeholders before real-world testing
By: Carol Burns - Principal Product Manager | Microsoft Intune and Sucheta Gawade, Microsoft MVP (Azure & Security / Intune) Practitioner perspective from Sucheta Gawade, Microsoft MVP (Azure & Security / Intune), with deep experience in secure frontline mobility, including regulated healthcare environments. In the previous article, we focused on understanding the reality of your frontline device estate - what devices you have, how they’re used, and which tasks they must support. Now that discovery is complete, the next step is to assess what you’ve found and align your people and processes before beginning real‑world testing with Microsoft Intune and representative users and devices. This is where you turn discovery into an actionable plan your team can execute in real operational conditions. Many organizations refer to this stage as a Proof of Concept (POC) or pilot. In this article, we use these terms to describe limited real‑world validation of frontline workflows with representative users and devices, rather than internal IT feasibility testing. Use the pilot to confirm that users can reliably complete critical tasks in live operational environments before wider rollout. Translate discovery into decisions Discovery produces facts, but readiness requires decisions. Before beginning real‑world testing with representative users and devices, your team should be able to answer questions like: Are we migrating “as‑is,” or do we plan on correcting identity and usage anti‑patterns such as shared credentials or personal use on corporate devices? Which workflows are non‑negotiable and must work on day one, and which can be improved later? Do we need to refresh hardware now, or can we migrate current devices and plan standardization at refresh time? What are our top constraints (OS support, connectivity, etc.)? A useful way to structure discovery output is to categorize findings and determine whether they support limited real‑world testing or require further alignment before proceeding. Pre‑requisites for real‑world testing typically include clear ownership of devices and apps, supported OS versions, and a manageable device or OEM mix. Items that often require alignment before real‑world testing include shared devices without a defined shared‑device model, shared credentials or unclear authentication approaches, personal use on corporate devices (which affects wipe/re‑enroll decisions), certified app or peripheral constraints, and network or certificate dependencies that could impact enrollment and compliance. Identify the stakeholders you must align (and why) Real‑world testing of frontline workflows depends on more than technical readiness. A clear stakeholder map helps surface operational dependencies early and ensures that limited validation activities can be conducted safely without disrupting day‑to‑day work. Not every environment requires all of the roles listed below at this stage, but these are the most common stakeholders needed to support limited real‑world testing of frontline workflows. Operational stakeholders Stakeholder Why they matter What to align Operations / business leadership Define frontline outcomes and approve change windows. Critical workflows, downtime tolerance, shift patterns, pilot locations, operational sign‑off criteria. Funding owners / procurement Discovery often uncovers refresh or licensing gaps. Device and accessory funding, carrier plans, spares, and standardization strategy. Change management Testing may introduce new sign‑in flows or device behaviors. Communications plan, support readiness, rollback and escalation processes, exception management. In addition to operational alignment, technical readiness across supporting IT teams is required to ensure testing reflects production like conditions. Technical and support stakeholders Stakeholder Why they matter What to align Endpoint or Microsoft Intune owners Build policy, enrollment, apps, and compliance. Device categories, management models, policy approach, rollout waves. Architecture team Ensure alignment with enterprise standards. Reference architecture, lifecycle approach, dependency mapping. Microsoft Identity / Microsoft Entra team Underpins Conditional Access and shared‑device patterns. Authentication model, shared device sign‑in patterns, break‑glass scenarios. Network team Enrollment depends on connectivity and certificate flows. Wi‑Fi (EAP‑TLS), proxies, segmentation, roaming, known dead zones. Security / risk / compliance Define guardrails and exceptions. Wipe policies, logging, least privilege, auditability. App owners / vendors Critical frontline workflows depend on app behavior. Compatibility, offline behavior, deployment approach. Support / service Desk Manage user impact during testing. Runbooks, escalation paths, enrollment troubleshooting, shift‑based support. Project management (large environments) Coordinate testing across teams. Timeline, risk tracking, cross‑team communications. Readiness checklist before real‑world testing Real‑world testing often produces limited value when it focuses primarily on Microsoft Intune enrollment rather than operational use. Enrollment is a starting point, but the goal of this stage is to confirm that critical frontline workflows function reliably end‑to‑end in production‑like conditions. Readiness area Questions to consider before real‑world testing Licensing Do you have the correct Intune licenses for the devices or users in scope? Are any add-ons needed? Identity Is Microsoft Entra configured for your enrollment approach? Are Conditional Access policies ready for real‑world testing? For shared devices, what sign‑in model will you use? Stakeholder alignment Who owns the success criteria? Who approves the testing scope and change window? Who funds required accessories or device refresh? Operational readiness Who provides day‑to‑day support for test devices? What is the escalation path for a broken critical workflow? What is the rollback or recovery plan? Device lifecycle decisions Will you test by migrating existing devices as‑is, replacing end‑of‑life devices first, or using testing to define the future standard? OEM and ecosystem readiness Are the devices still supported by the OEM? Are required peripherals supported? Do rugged or certified requirements limit device options? Lack of clear ownership for testing success criteria is a common cause of inconclusive pilots, particularly where operational workflows span multiple teams. Decide what your real‑world testing must validate Real‑world testing often produces limited value when it focuses primarily on enrollment rather than operational use. Enrollment is a starting point, but the goal of this stage is to confirm that critical frontline workflows function reliably end‑to‑end in production‑like conditions. Real‑world testing should validate high‑value operational outcomes, ensuring: Critical workflows function end‑to‑end Scanning, inventory, delivery confirmation, POS, etc. Session transitions match shift patterns Offline or degraded‑mode behavior works as expected (where relevant) Security works without disrupting operations Compliance and Conditional Access do not block legitimate frontline activity Wipe and recovery processes are realistic for shared devices App protection controls align with user experience Supportability is operationally viable Device reset and re‑enroll processes are documented Troubleshooting steps are known and repeatable Escalation paths exist for frontline‑impacting incidents Representative device scenarios are included Include the different frontline scenarios identified during discovery, such as: Shared vs assigned devices Different OEM models or OS versions Sites with known connectivity constraintso Common peripherals that may introduce migration risk (for example, scanners or printers) Plan for future standardization (without delaying testing) You may need to begin real‑world testing using the environment you have today. However, this stage can also be used to identify patterns that may shape future procurement and standardization decisions without delaying validation activities. Practical prompts to add to your planning: If you could reset procurement going forward, would you reduce OEM or device model sprawl? What might your target “approved device set” look like for the next refresh cycle? Which procurement models could support consistent enrollment, warranty coverage, and access to spares across shifts? Standardization doesn’t need to be a prerequisite for real‑world testing, but it can become a valuable outcome of the migration effort over time. Moving from assessment to real‑world testing After you’ve aligned stakeholders, clarified dependencies, and defined what your real‑world testing must validate, you’re ready to move from assessment to limited operational testing with representative users and devices. The key takeaway is this: discovery tells you what’s real, but readiness determines whether you can safely test it in live operational conditions. As always, we welcome your feedback and experience. If you’ve already tested frontline workflows in operational conditions, what advice would you give organizations preparing for this stage? Share your thoughts in the comments below or reach out to us on X @IntuneSuppTeam. Explore the From the frontlines: Frontline worker management with Microsoft Intune series for additional guidance on managing frontline workers and devices.Migrating Frontline Mobile Devices: Understanding the reality of your estate
By: Carol Burns - Principal Product Manager | Microsoft Intune and Sucheta Gawade, Microsoft MVP (Azure & Security / Intune) Practitioner perspective from Sucheta Gawade, Microsoft MVP (Azure & Security / Intune), with deep experience in secure frontline mobility, including regulated healthcare environments. Frontline devices have evolved from a small set of task-specific tools into the way day-to-day work gets done. As new workflows, apps, locations, and teams get added over time, device estates expand quickly, making it harder to maintain consistency and visibility. For many organizations, the reality of the estate isn't easy to keep track of. Devices may have been purchased locally, inherited through acquisitions, shared across teams, or left unused in lockers. They may be repurposed for new workflows or kept running far longer than originally planned. This creates a gap between what teams think they have, how they expect devices to be used, and what happens in the field. “Frontline estates aren’t complex because teams don’t care, they’re complex because operations evolve faster than governance.” -Sucheta Gawade, Microsoft MVP If teams don’t close this gap early, it tends to show up during pilots and cutover: devices fail in real conditions, frontline teams revert to workarounds, and the migration slows down through rework, exceptions, and avoidable disruption. To understand the estate, teams need to start by determining what the business needs devices to do and not just who happens to use them. Start with what devices need to do While some devices are assigned to individual users, many are shared across shifts, used for specific tasks, or operate without a fixed user at all. Designing a migration around users or roles can obscure what really matters: the job the device must perform, when it must be available, and the impact if it isn’t. Anchoring on business needs helps teams: Focus on outcomes rather than ownership models Simplify stakeholder conversations Make clearer tradeoffs, when required, around user experience, productivity and security One simple way for teams to gather this information is by mapping business tasks to what devices must reliably do. Business Task What the device must do When it must work Impact if unavailable Take payment for goods Run secure POS applications Store open hours Lost revenue Pick inventory Scan bar codes quickly and accurately During shifts Orders delayed Document patient observations Capture and submit clinical data During care delivery Delayed or incomplete care This framing applies equally across retail, healthcare, manufacturing, transport, logistics and utilities. It creates a shared language between IT, operations, and security - one that is grounded in business impact rather than tooling. Once business needs and intended device usage are clear, the next step is understanding how those devices support frontline work day to day. Understand how devices are used in practice Frontline usage patterns often diverge from what business owners and IT expect. Devices may be shared across shifts or used by alternate users. They may also be repurposed to support new workflows or kept running beyond their intended lifecycle, all without IT or executive oversight. These gaps are best identified by partnering with operational and business owners to validate real-world usage through quick workflow walk-throughs, targeted questions, and a review of how devices are accessed and supported day-to-day. Some helpful questions: How are devices shared? When are they offline or unavailable? What workarounds exist to keep critical tasks moving? It’s also critical to confirm whether corporate-assigned devices have been used for personal activity. Personally used devices may also be treated as work devices, whether authorized or otherwise. This affects wipe and re-enroll decisions because personal use can introduce data retention, user impact, and acceptance risks. Intended usage Actual observed use Notes/Workarounds Assigned device Shared across the shift Shared credentials used Always connected Intermittent Wi-Fi Offline workarounds Single-app device Multi-app usage Local exceptions for multiple apps This is also where identity assumptions surface, particularly in environments where devices are shared but access shouldn’t be. “Identity reality matters: shared devices should not mean shared credentials. Migration is often the right moment to address this. Otherwise, teams simply re‑platform the same risks.” -Sucheta Gawade, Microsoft MVP Teams often uncover important dependencies at this stage. For example, some frontline workflows rely on constant connectivity, while others must function reliably in low‑bandwidth or offline conditions. Similarly, older operating systems or unsupported device models may still be in active use because replacing them has operational or budgetary implications. Understanding these realities early helps teams avoid designing for ideal conditions that don’t exist in the field. Ground plans in device inventory Inventory is most valuable when it supports planning decisions, not when it aims for completeness. For frontline migrations, teams need decision relevant information rather than a perfect asset register. Understanding how devices are procured and funded across the organization is important. For example, whether devices are purchased centrally through IT or sourced locally by business/departments. Procurement paths often explain why inventory is fragmented and help determine who owns refresh cycles, warranties, and enrollment readiness. At a minimum, this includes: Device types and OEMs OS version ranges and supportability Whether devices are active, dormant, or missing How devices align to business-critical tasks Where specialist or certified devices are required such as intrinsically safe or ruggedized devices This helps surface ecosystem considerations early: Are required apps and services supported on the OS versions in use today? Do OEMs still support the hardware? Do environment constraints affect enrollment, updates, or day‑to‑day operation? These questions are not about selecting solutions yet. They’re about understanding constraints that will shape options later. With business needs understood, usage patterns mapped, and inventory validated, teams are ready to start designing approaches that work in frontline conditions. Migration is also a good opportunity to plan for standardization and set a future procurement standard. Even if you migrate the current estate as-is, defining an approved OEM or model catalog for future purchases improves consistency. It can also accelerate troubleshooting and strengthen lifecycle governance as devices reach end of support. What we’ve learned The key lesson is simple: validate reality before designing anything. Teams that invest time here: Reduce rework during pilots Avoid late‑stage surprises Have stronger conversations with operational, security, and platform stakeholders “We don’t declare success at enrollment. We declare success when a frontline workflow can run end-to-end with predictable support.” -Sucheta Gawade, Microsoft MVP In future articles, we’ll look at how these insights shape design decisions. In the meantime, we’re interested in hearing what gaps you’ve uncovered between intended and actual device usage in your frontline environments. Leave a comment below or reach out on X @IntuneSupportTeam.Migrating frontline mobile devices: A frontline-first approach to moving to Microsoft Intune
Frontline organizations consistently tell us that unified management is the goal but the challenge is getting there without disrupting day-to-day operations. Smartphones, Android handhelds, rugged scanners, and shared tablets now sit at the center of how retail stores run, how clinicians deliver care, how supply chains move, and how field workers’ complete work. These devices are mission critical, and any disruption is immediately felt on the ground. To strengthen security, reduce costs, and simplify operations, many IT architects and administrators are now evaluating or planning to move to Intune. This new series, “Migrating Frontline Mobile Devices - is designed to help. We’ve worked side by side with frontline customers, observing what works, where projects stall, and how small decisions early on can dramatically improve outcomes later. The articles in this series distil those lessons into practical guidance for teams who are considering, planning, or actively migrating devices. Frontline devices serve different needs and follow different operational rhythms than knowledge worker devices. Frontline migrations aren’t the same as standard knowledge-worker migrations and treating them as such often leads to operational problems or rollout delays. This article explains what the difference means in practice and how it shapes planning for successful frontline migrations. Why failures hurt more on the frontline A failed knowledge worker enrollment is an inconvenience. A failed frontline device enrollment or non-functioning device can affect revenue, disrupt essential services, and in some industries compromise safety. When a device is unavailable, critical work halts immediately: Pickers can’t complete scanning tasks Cashiers can’t take payments Health practitioners can’t document or prescribe care Drivers can’t dispatch Production lines stop Workers can’t perform required safety or compliance actions What we’ve learned: Frontline migrations must be coordinated with business and operational leaders; store managers, shift supervisors, clinical leads, and supply chain teams because they decide what is required and when devices can be taken offline. Why mobile frontline device migrations are different The operational impact of failure is higher on the frontline because frontline devices operate in very different environments to knowledge worker devices. Knowledge worker devices usually run in stable, well understood environments with known device catalogues, predictable lifecycles, assigned users, and steady connectivity. Frontline devices operate in conditions that introduce unique design and migration challenges. The environments they run in directly affect how and when a device can be enrolled or updated. Devices may run in low bandwidth or intermittent connectivity environments, making enrollment flows and policy delivery harder to complete reliably. Some operate in high-risk industrial or clinical settings where devices can only be taken offline during narrow operational windows. Others return to charging racks between shifts, meaning migrations must align with shift changes rather than user availability. Many run in kiosk or locked task modes tied to a single workflow, so even small configuration changes can disrupt critical tasks if not planned carefully. These environmental and operational realities show up across the entire device lifecycle from provisioning to updates to support. To make the differences clearer, here’s a concise comparison of frontline and knowledge worker devices: Category Frontline devices Knowledge worker devices Devices Smartphones, handhelds, rugged devices, scanners, wearables, tablets Laptops, desktops, smartphones OS and patch posture Often older versions; inconsistent patch levels due to operational constraints Typically, current OS or N-1; regular security patching cycles Ownership Shared, shift-based or individually assigned depending on role Individually assigned Network conditions Variable, often constrained Generally stable Provisioning Zero-touch essential User-led viable Updates Highly controlled Standard update cycles Apps Task-specific, time-sensitive updates Broad, less time critical updates Workflow impact Operationally critical Productivity-focused Typical usage scenarios Point-of-sale, healthcare, barcode scanning, delivery routing, inventory checks Email, productivity tools, collaboration, creative workflows Failure impact Immediate operational issues Localized user disruption Standard knowledge worker migrations are designed for predictable conditions such as consistent users, steady connectivity, current OS levels, and a governed device lifecycle. Frontline fleets rarely match this baseline, so their migrations require planning and design that reflects actual device state and use. A migration is a design moment, not just a technical step A migration offers an opportunity to reassess business needs, tighten governance, simplify and modernize app delivery, and confirm assumptions about how devices are used. It’s also a chance to raise your frontline security, aligning devices with Zero Trust principles. In successful frontline migrations: Teams build in time for design, evaluation, and piloting. Early alignment across stakeholders supports smoother execution and reduces the risk of disruptive rework later. Understand your estate before designing the migration Frontline migration projects always reveal something unexpected. Common patterns include: Mixed iOS/Android versions and multiple original equipment manufacturers (OEM) such as Samsung, Zebra, Honeywell, Apple and more. Devices running outdated OS versions or custom OEM images. Devices that haven’t checked in for months, often sitting unused in cabinets. App delivery paths reliant on sideloading or site specific packages with no update mechanism. Multiple active mobile device management (MDM) systems inherited through acquisitions or decentralized teams. Most migration issues that appear later in the project can be traced back to decisions made before anyone understood what existed in the field, how devices were being used, or what the business needed them to do in the future. What we’ve learned: Migration success improves dramatically when teams validate device inventory, usage patterns, and business requirements before choosing an enrollment method and designing configuration profiles. Real-world data turns assumptions into facts and avoids costly rework. Plan for identity – even if devices don’t use it today Many frontline devices run with shared logins or no user at all. Intune fully supports these scenarios, but identity gaps - shared credentials, app only authentication, and managed access patterns - often emerge over years of organic growth. These gaps can show up during migrations as both user experience issues and security risks. What we’ve learned: Even if you’re not ready to modernize frontline identity or introduce Microsoft 365 tools for workers, consider laying out the foundation. Mapping which users or roles should have identities, simplifying and securing access, and aligning devices to Microsoft Entra foundations will future proof your estate. What’s coming next in the series This series will explore the areas that consistently shape successful frontline mobile migrations the steps, patterns, and design decisions that matter most in real frontline environments. Over the coming weeks we’ll cover themes such as: Understanding your frontline estate - what exists today, how devices are used, and the realities that shape migration decisions Designing for frontline conditions - identity foundations, shared device patterns, kiosk considerations, and reliable enrolment flows Designing for frontline device scenarios - single user, shared, rugged, kiosk, and high-risk operational models Consolidating to a single Intune tenant - simplifying governance, policies, and operating models Getting the ecosystem right - apps, connectivity, certificates, and the infrastructure dependencies that influence reliability Executing the migration safely - pilots, phasing, cutover windows, and planning for 24/7 operations Life after migration - monitoring, support readiness, and ongoing operational ownership We’ll share practical guidance, common friction points, and patterns we’ve seen work across industries. Future articles will include perspectives from Microsoft Product Managers and community experts with hands-on experience managing large scale frontline device estates. Look out for the next article in the series - Understanding the reality of your estate. We’d love to include your perspective. If you have questions, scenarios, or experiences you want this series to address, share them in the comments below to help shape the upcoming articles, or reach out to us on X @IntuneSuppTeam. Our goal is simple: To help you migrate frontline mobile fleets to Intune without disrupting the business.
