When a device rollout falls behind, the instinct is to push harder on the same plan. That rarely works, because the plan is usually why it stalled.
If you’re mid-rollout with sites waiting and leadership asking for a new date, the next week matters more than the original schedule. You need an honest picture of where things stand, a fix for the real bottleneck, and a date you can actually hit.
This post covers how to re-baseline a rollout that’s behind, what can run in parallel and what can’t, how to add staging capacity, and when outside help makes sense.
Stop and re-baseline before you ship more
Before another device goes out, find out exactly where every device and every site stands. Shipping more through a broken process only multiplies the cleanup.
Count devices by state. How many have been ordered, received, staged, shipped, delivered, and confirmed working at the site? The gaps between those numbers show where the rollout is stuck.
Do the same for sites. Some will be fully live, some partly live, and some still waiting. That list becomes the basis for the new plan, and it’s the first thing leadership will want to see.
Find the bottleneck that’s actually holding you up
Most stalled rollouts have one main constraint, and everything else waits behind it. Fixing anything other than that constraint won’t move the date.
If devices are piling up before staging, the constraint is setup capacity. If staged devices are sitting in boxes, it’s shipping or site scheduling.
If sites have devices that don’t work, it’s the build or enrolment, and if nothing has arrived, it’s sourcing. The post on why device deployments fail walks through each failure point and how to tell them apart.
What can run in parallel and what has to happen in order
Rescuing a rollout is mostly about separating the work that’s waiting for something from the work that could start now.
| Can run in parallel | Has to happen in order |
|---|---|
| Fixing the standard build while staging continues for sites that don’t need the fix | Confirming the build works before staging the devices that depend on it |
| Site readiness checks for upcoming waves | Shipping to a site only after it’s confirmed ready |
| Help desk briefing and training materials | Retrieving old devices only after new ones are confirmed working |
| Ordering missing accessories | Re-enrolling devices that dropped out of management before reissuing them |
Automating more of the setup is often the fastest parallel fix, since it raises throughput without adding people. The piece on automating mobile device setup for speed and scale covers where to start.
Stand up a proper staging line
If setup capacity is the constraint, treat staging as a production line, not a side task. A dedicated space, dedicated people, and a fixed process will move more devices than a technician fitting setups between tickets.
- One documented build per role, frozen until the rollout is done
- A checklist every device passes before it’s packed
- Devices batched and labelled by site and role
- One test device per batch powered on and checked against the site’s setup
- A daily count of devices staged, so you can measure real throughput
That daily count is what lets you set a believable date.
Protect the line from interruptions. If the same people are also answering support calls, staging slows every time the phone rings. Even a few days of dedicated time, with tickets routed elsewhere, can clear a backlog that has been building for weeks.
Check site readiness before the next wave
A rollout can recover at the staging end and stall again at the site. Before each wave ships, confirm that the site is ready to receive and use the devices.
Check coverage where devices will actually be used, who will receive and charge them, and whether staff know the new workflow. Canadian rollouts add their own checks, such as carrier activation across provinces, travel time to remote sites, and French-language setup for Quebec locations. The site survey FAQ for IT deployments lists what to confirm before devices arrive.
Keep the sites working while you recover
A stalled rollout puts sites in an awkward middle state. Some have new devices that don’t work yet, some have old devices that were supposed to be gone, and some have a mix.
Keep the old devices in service until the new ones are confirmed working at that site. Pulling them early turns a schedule problem into an operations problem. Tell each site what’s happening, when its wave is now due, and who to call if something breaks in the meantime.
Here’s what actually happens when this step is skipped. Sites start inventing their own workarounds, sharing devices, borrowing from other locations, or setting devices up themselves. Every workaround becomes something you have to undo later, so clear communication now saves real cleanup.
Set a new date leadership will believe
A credible date comes from measured throughput, not optimism. Take the devices staged per day once the line is running, divide the remaining devices by that rate, and add time for shipping, site checks, and the problems you haven’t found yet.
Present the plan in waves rather than one end date. Leadership can see which sites go live when, and you can show progress every week. The post on planning a mobile device rollout covers how to phase waves.
Report against the plan every week, including what slipped and why. A plan that’s updated honestly is easier for leadership to support than one that’s quietly missed.
Then hit the first wave on time. One delivered promise rebuilds more confidence than any revised plan.
When outside staging help makes sense
Sometimes the honest answer is that your team can’t stage fast enough without dropping everything else. That’s the point where outside capacity is worth a look.
Outside staging fits when the bottleneck is setup volume, the deadline is fixed, and your team is also running day-to-day support. We stage, configure, kit, and ship devices from our own Canadian facility through our staging and deployment service, which adds capacity without pulling your team off everything else.
Just know that it won’t fix a broken build or an unready site on its own. If the constraint is sourcing or site readiness, fix that first, or extra staging capacity will only produce boxes that wait.
Questions we hear about stalled rollouts
Should we pause a device rollout that’s behind schedule?
Pause shipping long enough to re-baseline and confirm the real bottleneck, then restart in waves. Continuing to ship through a broken process multiplies the cleanup. A short pause to fix the build or add staging capacity usually costs less than fixing devices that are already in the field.
How do I estimate a new rollout completion date?
Measure how many devices your team actually stages per day once the process is running, divide the remaining devices by that rate, and add time for shipping, site checks, and contingency. Present the result as site-by-site waves rather than a single end date, so progress is visible every week.
What is the most common cause of a stalled device rollout?
Setup capacity is the most common constraint, especially when devices are configured by hand. Other common causes are late hardware or accessories, a build that doesn’t work at the site, and sites that weren’t ready to receive devices. Finding which one is holding you up comes before choosing a fix.
Where to start
Count every device by state and every site by status today. The gap in those counts shows you the bottleneck. Fix that one constraint, measure your real throughput, and give leadership a wave-by-wave date built on what your team has proven it can deliver.