The Unplugged Safety Net: Rehearsing 4G Failover for UK Business Networks

Resilience is frequently purchased as a line item. A backup router arrives, a SIM is inserted, the device is mounted in a communications cabinet and the matter is considered closed. The assumption is that the secondary path will take over when the primary connection fails. In practice, failover is not a product feature that can be relied upon because it appears on a quotation. It is an operational behaviour that must be rehearsed, observed and recorded.

For UK SMEs, the stakes are practical rather than theoretical. Card payments, cloud telephony, email, remote access to files and the ability to receive inbound calls all depend on a chain of equipment, subscriptions and settings. A 4G backup can preserve some or all of those services, but only if the surrounding dependencies have been considered. A router in a cupboard is not a safety net until someone has proved that it catches.

Define what working means before testing

A failover test should begin with a short list of services that matter to the business. These might include inbound and outbound calls, card terminal connectivity, access to a cloud finance system, email, remote desktop access or a line-of-business application. It is rarely necessary to replicate the full capability of the main connection. What matters is agreeing the minimum operating state and the acceptable level of degradation.

That definition prevents a common mistake: treating a speed test as proof of resilience. A backup link may deliver enough bandwidth for voice calls and payments while being unsuitable for large file transfers or video conferencing. If staff expect the backup to behave exactly like the primary line, they will report a successful failover as a failure. Set expectations in advance and write them down.

Choose a safe test window and a clear rollback

Failover testing should be treated as a change, not an experiment. Select a quiet period, avoid month-end and payroll processing, and tell the people who depend on the affected services. Confirm who is authorised to disconnect the primary line, who will monitor the backup and who can restore normal service if the test does not go to plan.

A useful rehearsal covers more than one failure mode. The primary connection can be lost at the carrier, at the router or at the power supply. Testing only by unplugging the wide area network cable at the router may not reveal what happens when the router itself fails or when mains power is interrupted. Start with a simple carrier-loss test, then schedule separate checks for equipment and power failure. Keep the first test short, perhaps thirty to sixty minutes, and extend later tests once the basics are proven.

The SIM is a subscription with limits

Mobile data allowances are not unlimited in the way that staff may assume. Many business SIMs have monthly caps, fair-use policies, speed restrictions or contention ratios. A backup link that is adequate for occasional voice traffic may be exhausted quickly if thirty employees remain connected to cloud applications for a full working day.

Before testing, calculate a realistic daily data requirement for the services in scope. If ten staff each use one gigabyte during an outage, a ten-gigabyte allowance will not last a working day. Check what happens when the allowance is reached: does the connection stop, slow down or incur charges? Confirm whether the contract includes a static IP address, whether inbound connections are possible and whether the provider prioritises business traffic. Signal strength should be measured inside the building at the intended router position, not in the car park. Test at a busy time of day, because mobile performance varies with local demand.

CGNAT, VPNs and inbound services

Most mobile data connections use carrier-grade network address translation, commonly known as CGNAT. This means the backup connection usually has no dedicated public address that the outside world can reach. Services that depend on port forwarding, such as an on-premises phone system, a remote support route into a server or a hosted camera platform, will not simply resume when the primary line drops.

Outbound services are usually less affected, but they are not immune. Cloud telephony, email and web applications generally work through CGNAT. Virtual private networks may connect, but some IPsec tunnels encounter maximum transmission unit issues over mobile networks. Split tunnelling, DNS settings and IP allowlists can also behave differently when the public address changes. The test should therefore include a remote worker connecting through the backup path, a cloud application login and a voice call in both directions. If the business relies on site-to-site connectivity, test that explicitly rather than assuming that a working internet connection is enough.

Power is part of the failover path

The backup router needs electricity. So does the switch that connects it to staff devices, the wireless access points and the handsets. If the mains supply fails, a router on an uninterruptible power supply may provide connectivity while the rest of the network is dark. The UPS should be sized for the equipment it actually supports, and its runtime should be tested under load rather than taken from a label.

Check that the backup router, the core switch and any telephony equipment are connected to the UPS. Confirm that PoE handsets and access points remain powered. Label the sockets and keep a simple diagram in the communications cabinet. If the UPS is monitored, verify that alerts reach the person who can act on them. A battery that has never been tested is a placeholder, not a control.

Telephony routing deserves its own rehearsal

Hosted voice services can continue over a 4G backup if the network, power and handsets remain available. The test should confirm inbound calls reach the right destination, outbound calls connect and voicemail or call forwarding behaves as expected. If the organisation uses an on-premises PBX, check whether a failover route exists and whether it activates automatically or requires manual intervention.

Staff should know how to use the backup arrangement without improvising. Emergency calling deserves particular care: do not dial 999 or 112 as part of a test. Confirm with the provider how emergency calls are routed over the backup path and make sure the agreed procedure is documented. The objective is confidence, not a live incident.

Keep evidence that is useful later

A failover test produces more than a pass or fail. It creates an evidence file. Record the date and time, the test lead, the services in scope, the failure simulated and the result. Keep screenshots of router status pages, speed tests, call logs and any error messages. Note the SIM data used and take photographs of the setup if cabling or power arrangements have changed.

That record has practical value. It supports conversations with the connectivity provider when a service does not perform as sold. It gives insurers and auditors something concrete when they ask how business continuity controls are verified. It also prevents the same faults being rediscovered at the next renewal. A short template is enough: what was tested, what happened, what was fixed and who owns the remaining action.

Turn the rehearsal into a routine

A single successful test is a snapshot. Schedule a light check each quarter and a fuller rehearsal at least once a year, or after a change of router, SIM, provider, phone system or office layout. Add monitoring for the backup link so that a failed SIM or a flat UPS battery is noticed before an outage. Review the 2026 arrangement whenever the primary contract is renewed.

The aim is not to create paperwork for its own sake. It is to replace an assumption with a known operating state. A backup connection that has been tested, documented and understood is a genuine resilience measure. One that has never been switched on is simply an unplugged safety net.