Zebra handheld deployment India warehouses: what Indore taught us about firmware variants
Three weeks into a Zebra handheld deployment India warehouses contract in early 2026, we hit a wall I had not seen on any rollout plan I had ever written. Eighty MC2200 units, twelve sites across Maharashtra and one in Madhya Pradesh, ninety days on paper. The picking error rate at our first three branches had already dropped 38 percent. The client was happy. I was, for a Wednesday in March, almost relaxed.
Then Indore went quiet. Not loud quiet. The kind where the dashboard still shows green and only the picker on the floor notices that her handheld has not synced a manifest since 6.30 in the morning. By the time someone called the helpdesk it was 2 PM. Twenty two units in one branch were effectively bricked. I keep coming back to that afternoon when I think about how MDM disasters actually start.
The 90 day plan looked clean on the spreadsheet
The 3PL was a mid sized FMCG distributor running twelve warehouses for a large beverages major. Picking still happened on paper at six of those branches. Their COO had finally signed off on a Zebra fleet rollout after two failed pilots with cheaper Android handhelds. The shortlist landed on the MC2200, paired with SOTI MobiControl as the management layer (SOTI MobiControl documentation).
Plan was orthodox. Procurement in two batches. Imaging at our Pune lab. Enrollment via QR code at each branch. SOTI policies pushed remotely. Risk columns covered connectivity, training and warranty escalation. They did not cover firmware variant within the same SKU. That omission is on me.
Pune, Aurangabad and Nashik felt like a quiet win
The first three branches went live across an eight day window. Field engineers stayed on site for 48 hours. Pickers got two short training sessions. The thanda chai on the warehouse floor at Aurangabad on day five tasted like the deployment was going to be the easy one. Picking error rates dropped between 31 and 41 percent across the three branches in the first fortnight.
Senior ops on the client side flagged one thing. They wanted Indore pushed earlier because it was their highest volume FMCG hub. I had slotted Indore for week four, partly because the branch manager was new and partly because the local LAN had been flaky during the site survey. Future Arjun, if you are reading this: do not push a tier two hub to later in the plan just because the survey week was awkward.
Get my free 4-hour quote 200+ businesses across India trust Sirius Star. Response within 8 hours.
Zebra handheld deployment India warehouses: what Indore taught us about firmware variants
Indore was a jhamela from day one of week three. The handhelds arrived at the branch on a Monday morning. The local engineer ran enrollment via QR code as he had at the other branches. SOTI MobiControl reported all twenty two devices as enrolled. The policy push fired. Everything looked correct on the console.
Arre, the policy push had silently failed on twenty of the twenty two. The handhelds were enrolled, but the SOTI agent was running against an Android baseline our policy bundle did not have a code path for. By Tuesday lunchtime the warehouse was dispatching against memory, paper printouts and one supervisor with a clipboard. By Wednesday morning the WMS partner had escalated to the client COO and the COO had escalated to me.
The root cause took us about nine hours to find. The first procurement batch had shipped with what Zebra internally calls A10 firmware on the MC2200 baseline. The second batch, shipped from a different authorised distributor to meet our timeline, was A11. SOTI MobiControl was compatible with both at the marketing layer. Our policy bundle was not. We had built and tested it against A10 only because our staging shelf in Pune was an A10 unit.
| Firmware | Android base | SOTI policy result | Behaviour on floor |
|---|---|---|---|
| A10 (batch 1) | Android 11 | Policies applied cleanly | WMS flow worked, picking 31 to 41 percent faster |
| A11 (batch 2) | Android 11 with vendor patch | Agent enrolled, profile silently rejected | Device usable as a torch and not much else |
The WMS partner had a fair point during the Thursday call. We should have caught this on staging. Achha, but the truth was our staging shelf had one MC2200 and one OS version, because procurement had not flagged the batch split, and because nobody in my team had asked. The shelf was honest. It just was not representative.
The recovery cost six days and one quiet finance call
Fix itself was almost dull once we knew what we were looking at. Bas, we paused the next two enrollment batches. Pulled three units back to Pune, rebuilt the policy bundle for the A11 vendor patch, ran a 36 hour soak test on the shelf, then re-pushed to Indore. Branch was back on the WMS by the following Wednesday.
Harder part was the finance call. The 3PL contract had a clean service level clause for delayed go live at any branch. Approximately INR 14.2 lakhs in credit, against a project budgeted at a little over a crore. The 3PL COO was reasonable because everything else had been on time. He made one observation I have not forgotten. He said the cost of getting it right was less than the cost of writing the credit, and he was correct on both counts.
The Intune documentation calls firmware-against-policy compatibility out for Windows endpoints too, and the lesson generalises. We had also evaluated Samsung Knox as a parallel option, where the same firmware variant problem shows up differently but does not disappear.
Get my free 4-hour quote Honest scoping call. No card. No contract. Response within 8 hours.
Four rules I would send back to Day 0
One. Treat firmware variant as a first class risk in the project sheet. Cross check the MDM compat matrix against every PO batch, every time. The DPDP rules for data handling are less forgiving each quarter, and a misconfigured handheld is just one more endpoint nobody can attest to.
Two. Build the staging shelf with at least two firmware variants per SKU. Even if procurement says the order is a single batch, hold one slot for the firmware your vendor will quietly ship if the original distributor cannot deliver.
Three. Do the tier two branch first, not last. Indore is harder than Pune. The connectivity is patchier. The branch manager is newer. If your rollout fails somewhere, you want it to fail at the harder branch on week one, with the team still on site.
Four. Run a 24 hour shadow before you switch the WMS flow. Two pickers on the new handheld. Two on the paper sheet. Compare dispatch logs at end of shift. If they match, you are clear. If they do not, you have a Thursday call on day one instead of day twenty one.
For the playbook on how MDM costs add up across a real Indian fleet, see our 90 day MDM bake off. For the buyer’s frame, see Samsung Knox vs SOTI and how to choose MDM India. For fleet finance, our device as a service explainer has the working numbers. The full Zebra range we deploy is on our Zebra industrial barcode printers and handhelds page.
P.S. Arjun here. We have seen exactly this firmware variant pattern hit two other warehouse rollouts in the last twelve months, both in tier two cities. The shelf is honest. The branch is honest. Procurement, with the best intentions, sometimes is not. If you are six weeks away from a Zebra or SOTI rollout, ask the Sirius Star team for the firmware variant checklist before you sign the PO, not after. Future you will thank past you.
Get my free 4-hour quote 200+ businesses. 17+ years in IT. Response within 8 hours.
