A severed fibre line outside a client’s office is never the ISP’s fault and always the ISP’s problem. The client does not experience a third-party civils contractor putting a digger through a duct. They experience their card machines stopping, their VoIP phones going silent and their cloud applications disappearing, and they experience all of it under your logo.
Cellular failover exists for precisely this gap between fault and accountability. For ISPs and MSPs it has become one of the most straightforward managed services to attach to a business connection: a 4G or 5G path that takes over when the fixed line fails, sold as a continuity service with recurring revenue attached. Designing it well, however, involves more decisions than putting a SIM in a router, and the failure points are consistent enough to be worth setting out properly.
The basic architectures
Cellular failover for fixed-line services follows three broad patterns, in ascending order of resilience and cost.
Cold standby. A cellular router or dongle sits powered off or disconnected, and someone enables it when the primary line fails. Cheap, and almost always a false economy: recovery depends on a human being present, the hardware is unproven at the moment it is needed, and the SIM may have sat dormant long enough to need attention itself.
Warm standby with automatic failover. The cellular path is configured in the router or firewall as a secondary WAN, continuously registered on the mobile network but passing no meaningful traffic until the primary fails health checks. The device fails over automatically, typically within seconds to a couple of minutes depending on detection settings. This is the standard pattern for most business sites and the right default for an MSP productising failover.
Active-active. Both paths carry traffic continuously, with SD-WAN or load-balancing logic steering flows by policy. Strongest continuity and the only pattern that also proves the backup path daily by using it, at the cost of higher data consumption and more sophisticated equipment.
Whichever pattern applies, the design discipline is the same: the backup path must be tested on a schedule, not discovered during an outage. Automated periodic failover tests, even brief ones, turn the backup from an assumption into a measurement.
The SIM strategy matters more than the router
The hardware conversation usually dominates failover design, and it is the wrong place to spend most of the attention. The router is a commodity decision. The SIM strategy determines whether the backup path is actually independent of the failure you are protecting against.
Two principles carry most of the weight.
Network independence. If a site’s fixed line and its backup SIM ultimately depend on the same operator group’s infrastructure, certain failure modes take both down together. More commonly, a single-network SIM simply has weak coverage at some percentage of client sites, which surfaces as a fleet of backup connections that work in the postcode lottery’s favour or against it.
Multi-network behaviour at the moment of failure. A SIM built on Multi-IMSI technology with non-steered network selection can attach to the strongest available network at each site rather than following a fixed preference list. For a failover estate spread across many locations, this converts site-by-site coverage variance from a survey problem into something the SIM resolves itself. It also matters during regional network incidents, when the ability to attach to an alternative network is the difference between a working backup and a second simultaneous outage.
For ISPs and MSPs deploying failover across a national or international client base, this is the strongest argument for sourcing SIMs from a provider whose multi-network access is structural rather than negotiated site by site. OV SIMs provide access across 600+ networks in 180+ countries on a single agreement, with network selection designed to favour the strongest available signal.
Planning the data, honestly
Failover data consumption is spiky by nature: near zero for months, then a working day’s full traffic during an outage. Pricing it requires modelling both states.
The quiet state is not actually zero. Health checks, keepalives, router management traffic and periodic failover tests all consume small amounts continuously, and they are worth estimating because they determine whether the cheapest dormant-style tariffs survive contact with reality. The active state depends entirely on what the site does: an office of cloud-application users consumes a very different outage-day than a site that mostly needs card payments and email to survive.
Pooled data across the failover estate is usually the right commercial shape. Most sites consume almost nothing in a given month while a handful consume heavily, and a shared pool absorbs that variance far better than per-SIM allowances sized for the worst case. It also gives the MSP a single number to manage and price against. Some teams additionally apply traffic policies during failover, deprioritising bulk traffic such as backups and updates so the cellular path serves the applications that matter, which both improves the outage experience and contains the data bill.
The failure points that catch teams out
A short field-tested list, because failover estates fail in repeatable ways. Antenna placement inside metal comms cabinets, where signal goes to die, discovered only during the first real outage. Failover health checks pointed at a target that can be reachable while the wider internet is not. Backup paths that work for outbound traffic while inbound services, VPNs and static-IP-dependent systems quietly break because nobody designed for the cellular path’s addressing. SIMs suspended by a provider’s dormancy policy after months of intended silence. And estates with no monitoring on the backup path itself, so a dead cellular connection is invisible until the day it was needed.
Every one of these is cheap to prevent at design time and expensive to discover live. A deployment checklist that covers signal survey, health-check targets, inbound service behaviour, dormancy terms and backup-path monitoring removes most of the category.
Productising it
For the channel, failover works best packaged as a continuity service rather than a SIM resale: hardware, connectivity, monitoring, scheduled testing and reporting under a single monthly fee. The connectivity component should come from a partner that supports the operating model behind that product. Through OV ONE, built in-house by OV, partners manage the whole failover estate from one platform, automate provisioning and suspension through documented APIs, set data caps and alerts per SIM or per pool, and see real-time session state when a client calls, which is the visibility a service desk needs to say something more useful than “it should be working”.
The simplest way to evaluate fit is empirical. Request a free IoT SIM trial, put SIMs into your standard failover hardware at a few representative sites, and measure attachment behaviour, failover timing and signal performance before committing the product line to any provider.
Frequently asked questions
How fast does 4G failover take over when a line fails?
With automatic failover configured, cutover typically completes within seconds to a couple of minutes, governed mainly by the router’s failure-detection settings rather than the mobile network. Sessions that cannot survive an IP change may need to re-establish, which is why testing with the site’s real applications matters more than the headline cutover time.
Is one shared backup SIM model viable across many client sites?
Yes, and pooled data across the estate is usually the most efficient commercial structure, because most sites are dormant in any given month while a few consume heavily. The pool absorbs that variance and gives the provider a single consumption number to manage and price against.
Does failover need a static IP on the cellular path?
Only when inbound services, site-to-site VPNs or IP-allowlisted systems must keep working during an outage. Many sites run outage operations on outbound connectivity alone. Where fixed addressing is needed, options such as private APN configurations should be part of the design conversation with your connectivity provider rather than an afterthought.
Can 5G be used for failover instead of 4G?
Yes, where coverage and hardware support it, and the design principles are identical. For most business continuity purposes 4G LTE remains entirely sufficient for the applications that matter during an outage, and multi-network access generally contributes more to real-world resilience than the radio generation does.
