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

In addition to operational alignment, technical readiness across supporting IT teams is required to ensure testing reflects production like conditions.

Technical and support stakeholders

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.

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:

1. 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)
     
     
2. 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
     
     
3. 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
     
     
4. 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.