A private 5G or LTE project rarely fails because somebody selected the wrong radio. It fails because a promising technology decision was allowed to outrun the operational, commercial and physical realities of the site. To fix a failing private network rollout, stop treating the symptom first. Establish what the network was meant to change, where the failure is occurring, and who owns the decision to correct it.
For a port, factory, farm, warehouse, venue, local authority or automated vehicle operation, a private network is not an end in itself. It must improve safety, productivity, control, resilience or the economics of a connected service. If it cannot do that consistently, more access points, a new dashboard or another vendor workshop will not resolve the underlying issue.
Start with the promised operational outcome
The most useful recovery question is straightforward: what specific workflow was this network expected to support better than Wi-Fi, public mobile coverage or a wired alternative?
The answer needs to be measurable. It may be continuous video uplink from AI cameras, reliable command and control for automated vehicles, coverage for lone-worker devices, asset tracking across a large outdoor estate, or connectivity for EV charging and energy-monitoring equipment. “Better coverage” is not a sufficient requirement. It gives every supplier room to declare success while users continue to experience failure.
Compare the original business case against what is happening now. Are devices dropping off in known locations? Is video latency unacceptable only at shift change? Are vehicles losing session continuity at handover points? Is the network available, but the application is not? Separating the business failure from the radio failure is the first recovery milestone.
A rollout can be technically healthy and still be commercially unsuccessful. If operations teams have reverted to manual processes, if device onboarding takes days, or if the support model depends on one specialist contractor, the programme has not reached production readiness.
Find the constraint before changing the design
Private networks are multi-layer systems. A problem observed on a handheld terminal may originate in radio planning, spectrum configuration, the SIM profile, a device firmware setting, the local core, identity management, firewall rules, cloud routing or the application itself. Teams lose time when each party investigates only its own layer.
Create one incident view that follows a real user journey from device to application. Take a failing camera, sensor, vehicle or tablet and test it in the exact environment where it is expected to work. Record signal quality, throughput, latency, packet loss, handovers, authentication events and application response at the same time. A speed test alone is almost meaningless for a mission-critical use case.
Coverage is not the same as usable service
A radio survey may show signal across a site while the service remains unusable. Metal racking, moving stock, containers, machinery, reinforced structures and changing weather conditions can alter the radio environment significantly. Indoor-to-outdoor transitions and vehicle cab environments are frequent trouble spots.
Coverage also needs to be evaluated against the traffic pattern. A site may support a modest number of smartphones yet struggle when dozens of cameras begin sending high-resolution uplink traffic. The uplink budget, antenna placement, band choice, backhaul and local processing design must reflect the actual workload, not a generic coverage heat map.
Do not assume that densification is automatically the answer. Additional radios can improve capacity in one area while creating interference, handover complexity and a more expensive operating model. Sometimes repositioning antennas, changing sector orientation or moving compute closer to the edge produces a better result at lower cost.
Spectrum and device capability need checking together
Spectrum decisions are often made early, while the chosen devices arrive much later. That is risky. Industrial routers, cameras, gateways, trackers and vehicle modems vary widely in supported bands, carrier aggregation, uplink capability, power class and software maturity.
Check the deployed spectrum against every production device SKU, including replacement units and future variants. Confirm that device certification, SIM provisioning, access point names, quality-of-service policies and firmware are aligned. A network cannot compensate for a modem that does not properly support the intended band or feature set.
This is particularly relevant where organisations have mixed estates: legacy LTE equipment, new 5G devices, third-party sensors and specialist hardware sourced through operational teams. A controlled device acceptance process is slower at the start, but far cheaper than investigating intermittent failures across hundreds of endpoints.
Recover the architecture, not just the radio layer
Private network projects often stall at the point where connectivity has to integrate with the wider estate. The network may be live, but cameras cannot reach their analytics platform, autonomous systems cannot access control services, or enterprise security rules block required traffic.
Map the end-to-end architecture in plain language. Identify where traffic enters and leaves the private network, where identities are checked, where data is processed and retained, and which teams own each boundary. This needs to include LAN and WAN connectivity, cloud services, edge compute, operational technology networks, mobile core functions and security controls.
A common issue is an over-engineered design created for a theoretical future state. Local breakout, edge computing and network slicing can be valuable, but only where the use case needs them and the organisation can operate them. For some sites, a simpler managed core and clear routing model will deliver greater reliability. For others, particularly low-latency vehicle control or security video, local processing is essential. It depends on the consequence of delay or service loss.
Security must be designed as part of recovery rather than introduced as a late compliance exercise. Segment device classes appropriately. Define how credentials are issued and revoked. Establish who can make configuration changes, how remote access is controlled and what happens when a device is lost or compromised. Private does not automatically mean secure.
Put operational ownership where it belongs
Many rollouts fail after acceptance because nobody owns the service across supplier boundaries. The radio vendor says coverage is within design parameters. The systems integrator says the application is working. The enterprise IT team says the firewall is compliant. Operations says the service cannot be relied upon. All can be correct, and the customer still has a failing network.
Assign a single service owner with authority to coordinate technical, commercial and operational decisions. That person does not need to perform every task, but they must own the outcome. Define service levels that users recognise, such as camera availability during critical hours or successful completion of vehicle missions, alongside conventional network measures.
The operating model should cover monitoring, incident triage, escalation, change control, spares, device lifecycle management and field access. It should also state what is monitored proactively. Waiting for warehouse staff or event operators to report a failure is not a support strategy.
This is where a well-designed pilot differs from a production service. A pilot can survive on goodwill and specialist intervention. A production network needs repeatable processes, named responsibilities and enough documentation for the operation to continue when the original project team has moved on.
Reset supplier conversations around evidence
When a rollout is under pressure, suppliers may propose additional equipment, professional services or a redesign before the facts are clear. Some changes will be necessary, but expenditure should follow evidence.
Ask each party for the assumptions behind its proposed fix: expected traffic demand, propagation model, device capability, application requirements, availability target and operational responsibility. Test those assumptions against measured site data and real workflows. If no one can connect the recommendation to the failure mode, it is not yet a recovery plan.
Commercially, revisit contracts as well as technology. Confirm what is included in support, who is accountable for integration defects, how acceptance is defined and whether licences, spectrum arrangements or managed-service costs still make sense at the intended scale. A technically recoverable deployment can still be the wrong commercial model.
Christian Borrman’s approach to project recovery is built around this operator-level discipline: make the problem visible across technical and commercial boundaries, then take the smallest credible action that restores a usable service.
How to fix a failing private network rollout without restarting it
A full restart is sometimes justified, particularly where the original use case was never viable or the architecture cannot meet a critical safety requirement. More often, the better route is a controlled reset. Freeze non-essential expansion, protect the service that users depend on, establish a verified baseline and correct the highest-impact constraint first.
Avoid declaring victory when a demonstration works in a quiet corner of the site. Run acceptance testing during normal operations, with production device volumes, real user movement and realistic application loads. Test failures deliberately: loss of backhaul, power interruption, device replacement, software updates and handovers between coverage zones. The aim is not perfection. It is to understand the service boundaries and operate confidently within them.
A private network earns its place when the people running the site stop discussing the network and start relying on the outcome. That is the point at which recovery becomes progress.
