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: 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.
