Migrating frontline mobile devices: Identity considerations for assigned and shared devices
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 previous articles in this series, we focused on understanding the reality of your frontline device estate and preparing for real-world testing through stakeholder alignment. One of the most critical areas to get right during the testing phase is identity and security, particularly given the often fast-paced, shift-based nature of frontline work, where organizations must account for the distinct requirements and challenges of devices assigned to a single individual versus devices shared across multiple users or shifts. Identity decisions directly affect security posture, sign‑in experience, operational support overhead, and worker productivity. Getting them wrong is one of the most common reasons pilots stall or fail. This article explores how to think about identity on frontline devices by distinguishing between assigned and shared usage models, clarifying when individual sign-in is required, and highlighting patterns to avoid such as shared accounts and passwords. Start by distinguishing device usage models Frontline mobile devices generally fall into one of two broad categories. Assigned devices Assigned devices are issued to a specific individual, often for the duration of their role. These devices: Typically require persistent access to user‑specific data Align with user‑based identity, Microsoft Entra ID Conditional Access, and audit controls. Enable greater accountability and traceability by associating activity with an individual user rather than a shared credential. Common examples include: A doctor using an individually assigned clinical tablet, where uninterrupted access to patient data and clinical systems is essential and actions must always be attributable to a named identity A field engineer assigned a single device that retains configuration, credentials, and offline content across jobs and locations An inspector or supervisor using an assigned device for approvals, reporting, and decision‑making that requires traceability Shared devices Shared devices are used by multiple people across shifts or tasks. These scenarios introduce additional identity complexity and generally fall into two distinct models. Shared devices without user sign-in (task or kiosk-based) Some frontline devices exist to perform a narrow, often repetitive task and don’t require sign in with a user account. Typical examples include: Retail price-check devices used on the shop floor to scan an item and display its current price or stock availability, with no need for access to personal or user-specific information Environmental monitoring devices used to read and record temperature or humidity in a storage area, ward, or vehicle, where the task is simple, repetitive, and not tied to an individual user identity Warehouse or facility scanning devices used for a narrow operational task such as scanning an asset, bin, or location code to confirm status, location, or completion of a step in a process In these cases: Devices are locked down to a specific task No user-specific data is stored, and access is limited to the minimum required for the task “When a device is truly task-only, removing sign-in friction is a huge win, but only if we’re aware what data the device can access. When things like patient context or personalized tasks enter the picture, identity becomes required” - Sucheta Gawade, Microsoft MVP Shared devices with individual user sign-in Organizations are increasingly digitizing and modernizing frontline workflows end-to-end. Paper processes and simple apps give way to connected systems, manual handovers are replaced with digital task lists, and workers begin to rely on mobile devices as their primary interface from completing tasks. As roles evolve, workers are expected to: Receive tasks, schedules, and updates digitally Communicate with supervisors and peers using collaboration tools such as Microsoft Teams Capture information at the point of work rather than transcribing later Interact with workflows that are increasingly automated or assisted by AI, such as guided steps, data validation, or suggested actions This shift delivers clear productivity and quality benefits, but it also means access must now be tied to individual identity to protect sensitive data, support auditability, and prevent information from being carried over between users. Common scenarios include: Retail store associates rotating across shifts, moving from paper schedules and verbal handovers to digital task lists, real-time communications, and collaboration tools such as Microsoft Teams Nurses sharing mobile devices in a hospital ward, where paper notes and whiteboards are replaced with secure access to patient-linked applications, care coordination tools, and role-based alerts Logistics workers signing in to shared devices to complete role-based tasks, capture data at the point of work, and interact with AI-assisted workflows. Don’t use shared credentials, always prefer individual sign-in Shared credentials may seem like a shortcut in frontline environments, but they undermine accountability and make policy enforcement and incident response significantly harder. “Shared credentials feel ‘efficient’ until your first incident. You lose auditability, Conditional Access becomes meaningless, and investigations turn into guesswork. Individual identity is the only scalable model.” -Sucheta Gawade, Microsoft MVP If access involves corporate systems or sensitive data, each worker should use their individual credentials to sign in, even on a shared device. Identity decision checklist for frontline devices Use the checklist to validate identity choices and confirm that the overall security posture matches the way the device is used. Decision area Indicators Use individual sign-in Users access personal or role-specific data. Auditability or compliance is required. Conditional Access or multifactor authentication (MFA) must be enforced. Applications rely on user identity. Use kiosk-style or device-only identity Devices perform a single task. No user-specific or sensitive organizational data is accessed. Workflows are entirely device-centric. Speed and simplicity outweigh personalization. Avoid entirely Shared usernames or passwords. Reused local accounts across shifts. MFA exclusions that weaken security without compensating controls. Choosing the right sign‑in experience The challenge in frontline environments is balancing: Security requirements Speed of access Ease of use across shifts “Frontline setups may fail because the sign-in flow doesn’t match reality. If authentication takes 60 seconds and the worker has to do it 30 times a shift, they’ll find a workaround.” -Sucheta Gawade, Microsoft MVP Typing complex usernames and passwords repeatedly during a shift is often impractical on mobile devices. QR code authentication is one effective option for shared frontline devices, but it’s not the only supported approach. For other supported methods, see Microsoft Entra authentication methods overview. QR code authentication Microsoft Entra QR code authentication is designed for frontline workers to sign-in efficiently on shared Android and iOS/iPadOS devices without repeatedly entering usernames and passwords. Note: For individually assigned devices, phishing-resistant, passwordless authentication methods are the recommended approach, such as Passkeys. QR code authentication enables workers to sign in using a unique QR code and a personal numeric PIN. This approach: Eliminates typed usernames and passwords Preserves individual identity Works well for shared devices with frequent user turnover Integration with Microsoft Intune, Managed Home Screen and Conditional Access QR code authentication should always be: Scoped to specific users and devices Combined with Conditional Access policies Evaluated during real‑world testing to ensure the right balance of usability and security Security posture and Conditional Access for frontline devices Individual identity is a critical foundation for stronger security posture, but it’s not enough on its own. Frontline device security also depends on management, data and app protection, session handling, and access policies that reflect the actual usage model. Conditional Access is an important part of securing frontline environments, but its effectiveness depends on aligning policies to the actual device and identity model in use. To ensure that the QR code authentication method can only be used by the frontline workers it’s intended for, create a custom authentication methods policy, which you can use in a dedicated Conditional Access policy. That Conditional Access policy should then be scoped to the group of users (frontline workers) who should log on using the QR code authentication method, and have the Require authentication strength control configured, which targets the custom authentication strength for "QR Code" which was previously created. During real‑world testing: Validate that design and controls support the intended usage model Ensure policies don’t block legitimate workflows Confirm sessions, access, and user targeting behave as expected These decisions should also be validated in practice: can users sign in and out reliably across shifts, is personal data cleared between sessions, and does the chosen experience match the pace of frontline work? Summary This article walks through how identity choices shape security, usability, and day-to-day success for frontline mobile devices. It explains the difference between assigned and shared devices, when individual sign-in is needed, and why shared credentials can create risk. It also highlights QR code authentication and Conditional Access as practical ways to keep each worker’s identity protected while making sign-in simple enough for fast-paced frontline workflows. What’s next in the series In the next article, we’ll focus on Microsoft Intune enrollment models, exploring how different enrollment approaches support—or constrain—the identity and usage patterns discussed here, including their role in protecting session identity, enforcing the intended sign-in model, and preventing one user’s access or data from carrying over to the next. As always, we welcome your feedback and experience. If you’ve navigated identity decisions for shared or frontline devices, share your advice and lessons learned in the comments, or reach out to us on X @IntuneSuppTeam. For more guidance across frontline scenarios, explore our broader From the Frontlines series on frontline worker management with Microsoft Intune. Join our community! Discuss real-world scenarios, get expert guidance, connect with peers, and influence the future of Microsoft Security products. Learn more at aka.ms/JoinIntuneCommunity.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.
