Deploying 6,000+ devices for a UK General Election

An election has a fixed date. Every other deployment I had run allowed some negotiation on timing — this one did not. That single fact decided the whole design: the pipeline had to be judged on its worst day, not its average one, and it had to make partial failure visible early enough to still be fixable.

The volume was 6,000+ devices spanning Windows, macOS, iOS, Android, and VR hardware. Mixed estates are where device tooling usually breaks down, because each platform has its own enrolment model and its own failure modes.

Enrolment was manual and sequential — a technician took a device, worked it through configuration, and moved to the next. At roughly 400–500 devices a month this was survivable. It had three properties that made it unusable at election volume:

• Throughput was tied to headcount. The only way to go faster was more technicians doing the same manual work.
• Failures were silent. A device that dropped out mid-enrolment looked identical to one not started yet. Nobody found out until someone physically checked.
• There was no record. With no per-device history, a question like "what configuration did this unit actually receive?" had no reliable answer.

I replaced the sequential process with a staged pipeline. Devices enter a queue and are processed in batches, with each unit tracked independently through the stages of its own enrolment.

• Queued, batched enrolment. Throughput became a function of batch scheduling rather than how many people were on shift.
• Per-device status tracking. Every unit has an explicit state. "Not started", "in progress", and "failed" are three different things, and the difference is visible without touching hardware.
• Automatic retry. Most enrolment failures at this scale are transient — a network blip, a service timing out. Retrying automatically removed the largest category of manual intervention.
• Red-flag alerting. Retry hides transient faults, which means it can also hide real ones. Devices that failed repeatedly were escalated rather than quietly re-queued.
• Role-based access. Technicians, supervisors, and administrators see and do different things. Bulk and destructive operations sit behind the appropriate role.
• Audited change history. Every state change is logged, so the configuration history of any individual device can be reconstructed after the fact.

Logging was designed alongside the pipeline rather than added to it. Secrets are never written to logs, and access to operational data is layered by role — the audit trail is only useful if it can itself be trusted.

The pipeline could not sit on top of three separate management platforms. Android, iOS, and macOS were each administered separately, which meant three consoles, three sets of conventions, and no single view of the fleet.

I consolidated them into a single Miradore-managed system. The operational gain was not the tooling itself — it was having one place where a device's state is authoritative, which is a precondition for automating anything across the estate.

High-volume imaging generates traffic patterns that corporate networks are not designed to absorb. I redesigned the network topology to separate the imaging and WDS network from corporate traffic.

This solved a capacity problem and a security problem at once: imaging traffic stopped competing with day-to-day business use, and devices in a partially configured, not-yet-hardened state were no longer sitting on the same segment as production systems.

Sustained throughput moved from roughly 400–500 devices per month to over 1,000, and the election deployment delivered 6,000+ devices across all five platforms with zero critical failures.

The throughput number is the one people ask about, but the more useful outcome was that the deployment stopped being opaque. At any point during the run it was possible to say how many devices were done, how many were in flight, and which specific units needed a human — which is what actually made a fixed deadline manageable.

Three things generalised beyond this deployment. Make failure states explicit and distinguishable, because "unknown" is the state that costs you time. Retry aggressively but alert on repeat failures, or automation quietly absorbs problems you needed to see. And consolidate the source of truth before automating on top of it — automation built over a fragmented estate mostly automates the fragmentation.