A distribution center running a fleet of Zebra handhelds on the Warehouse Management mobile app got a call from the floor supervisor in late July: barcode scans on inbound receiving were suddenly failing on about a third of devices, right after an over-the-air Android update pushed through despite the fleet being enrolled in Intune with update deferrals configured. The IT team opened a support ticket. The answer that came back wasn’t a patch. It was a reminder that the app on those devices, version 3, had been out of support since May, and the fix wasn’t going to be a hotfix to V3. It was going to be the V3 to V4 migration the team had scheduled for “sometime in Q3” and then quietly let slide.
That scenario is playing out at more distribution operations than Microsoft’s release notes would suggest, because the framing around this migration has made it sound smaller than it is. Under the hood, this isn’t a UI refresh. Microsoft rebuilt the Warehouse Management mobile app from scratch, moving it off Xamarin, a framework Microsoft itself retired from general support back in 2024, and onto React Native. That single architectural fact explains almost everything else about why this migration behaves differently from a normal app update, and why solution architects planning a fleet rollout need to treat it as an infrastructure project rather than an app-store bump.
Why This Isn’t a Simple App Update
Xamarin’s own end of life is the real driver here, not a desire to add dark mode. A framework built on Mono and .NET for cross-platform mobile development, Xamarin stopped receiving Microsoft support in May 2024, which put every product still built on it, including the warehouse app, on a clock. React Native gets Microsoft a modern, actively maintained foundation, and it shows up concretely in the release cadence: since V4’s staged rollout completed in early 2026, point releases have shipped roughly monthly, each carrying real functional changes rather than just security patches.
The rewrite also changed the authentication stack, replacing legacy libraries with MSAL and OneAuth, and that change has consequences that have nothing to do with barcode scanning. On Windows, the redirect URI registered in Azure AD app registrations needs to include ms-appx-web://microsoft.aad.brokerplugin/{clientId} for the broker flow to work. For on-premises deployments authenticating through AD FS, both Windows and Android need new redirect URIs registered before a single device can sign in to V4, which means this migration touches identity configuration owned by a different team than the one running the warehouse floor, and that handoff is where a lot of rollouts stall.
What Actually Breaks During a V3 to V4 Migration
Three things trip up fleet migrations that the high-level release notes gloss over, and all three are worth budgeting time for before a rollout window opens rather than during it.
The first is device eligibility. V3 supported Android 5 and later, while V4 requires Android 7. Any handheld still running Android 5 or 6, which is not unusual in a warehouse fleet with a five-to-seven-year hardware refresh cycle, simply cannot run V4 and has to keep running V3 until it’s replaced. That forces a mixed-fleet reality during the transition window: V3 and V4 can run side by side on different devices without conflict, but they cannot coexist on the same device, so the migration has to be planned and executed per device, not as a single global cutover.
The second is the iOS experience, which behaves noticeably worse than Android or Windows during migration. On those two platforms, connection settings carry over automatically from V3 to V4 as long as the device was already on V3 version 3.0.8 or later before the switch. On iOS, none of that carries over. Every connection has to be manually reconfigured after installing V4, and Device Code authentication, which a lot of iOS deployments relied on, isn’t supported in V4 at all; iOS is limited to username and password. The practical workaround worth building into a migration plan is generating QR codes or JSON configuration files ahead of time for each site or device group, so floor staff aren’t hand-typing server URLs and warehouse codes on a phone screen during a go-live window.
The third is the support-window structure itself, which changed again after V4 launched. Starting with version 4.1.1.0, Microsoft introduced a rolling twelve-month support window, effective May 2027, meaning only V4 releases published within the previous twelve months are eligible for support at any given time. A fleet migrated to V4 in early 2026 and left untouched will fall out of that support window well before 2027 arrives, so the actual deliverable of this project isn’t “get to V4.” It’s “get to V4 and keep a patch cadence going,” which is a different kind of ongoing commitment than most IT teams budget for an app migration.
A Practical Migration Sequence
The sequence that has worked cleanly across the fleet migrations worth learning from starts with an inventory, not an install. Pull every device’s current OS version and current app version before scheduling anything, because that inventory determines three separate migration paths: devices already eligible for direct upgrade, devices that need a V3 update to 3.0.8 or 3.0.9 first to preserve their configuration, and devices that need hardware replacement before they can run V4 at all.
For the Android and Windows devices in the first two paths, the upgrade itself is close to routine: push the V4 install through Intune or another MDM tool without uninstalling V3 first, since choosing the in-place upgrade path is what preserves the existing connection settings. Stage this in waves by site or by shift rather than as a single fleet-wide push, because the one-time reauthentication requirement per device means a help desk fielding sign-in questions from three hundred devices simultaneously is a bad night for everyone involved, whereas fifty devices at a time is manageable.
For iOS, treat it as its own project inside the larger migration rather than an afterthought. Confirm every affected user has username and password credentials provisioned before the cutover, since Device Code won’t be available as a fallback. Build the QR code or JSON configuration files in advance, and consider disabling auto-update on iOS devices until those configuration artifacts are ready, so a device doesn’t land on V4 mid-shift with no way to reconnect.
Keep the rollback path in mind but don’t lean on it as a safety net for the whole fleet. Individual devices can be downgraded to V3.0.9 if V4 surfaces a blocking issue during testing, which is useful for a pilot group, but Microsoft has been clear that once a region has fully migrated, that region-level rollback isn’t available. Pilot on a genuinely small, representative slice of the fleet, not just the devices sitting on IT’s desk.
Closing the Loop After Go-Live
The migration doesn’t end when the last device reports in on V4. Recent point releases have shipped capability that’s worth actively adopting rather than ignoring once the fleet is stable: a ProGlove arm scanner bridge for hands-free scanning workflows, editable client settings that let enterprise environments enforce TLS 1.2 and forced sign-in policies centrally, and expanded barcode format support including GS1 batch number separators that some receiving workflows depend on. None of that shows up automatically; it requires staying inside that rolling twelve-month support window Microsoft built into the V4 support model, which means assigning someone ownership of the update cadence the same way a team would own patch management for any other production system.
Routeget has run this exact device-inventory-first sequencing for several clients moving mixed Android and iOS fleets this year, and the pattern holds: the migration itself is mechanical once the inventory and identity prerequisites are sorted out. What actually determines whether it goes smoothly is whether someone treated it as an ongoing operational commitment from the start, rather than a one-time app-store update to check off a list.
#WarehouseManagementApp #DynamicsSCM #MobileFleetMigration #XamarinToReactNative #ERPGovernance #SupplyChainAutomation
No comment yet, add your voice below!