Instant Disaster Recovery: Move Your Applications Without Changing a Single IP
Disaster recovery has quietly become a compliance problem as much as a technical one. Under the EU’s Digital Operational Resilience Act (DORA), in force since January 2025, financial entities must demonstrate and test their ability to withstand and recover from ICT disruption, with business continuity, disaster recovery and failover explicitly in scope. Healthcare, government and critical infrastructure sit under similar pressure. It’s no longer enough to have a DR site; you have to prove it works and that you can fail over cleanly.
Yet many organisations, including some very large ones, still have DR plans that are, in practice, barely functional. The single most common weak point is also the least obvious: how traffic actually moves to the recovery site.
The hidden weakness in most DR plans
Most DR designs replicate applications and data to a second datacenter or cloud region. That part gets plenty of attention. The question that gets less attention is: when disaster strikes, how do users and systems get redirected to the recovery site?
The usual answer is DNS. You change a DNS record (or let a global server load balancer do it) to point your hostname at the DR site’s IP address. It works, slowly. DNS failover is bounded by TTLs and resolver caching. Even the fastest, best-tuned setups take a couple of minutes to converge, and in the real world some resolvers ignore your short TTLs entirely and keep sending users to the dead site for far longer. During those minutes, you’re down.
Worse, DNS failover does nothing for anything that doesn’t use DNS in the first place: site-to-site VPNs, partner integrations locked to a specific IP, legacy protocols and machine-to-machine connections that hard-code addresses. For those, “just change DNS” isn’t a slow fix, it’s no fix at all.
A different approach: move the IP, not the DNS
There’s a cleaner way to fail over, and it operates one layer down, at the internet routing layer instead of at DNS.
Instead of changing which address a name points to, you keep the same IP address and change where that address lives. Your provider-independent IP space is announced from your primary site; when you need to fail over, the same space is announced from the recovery site. The internet’s routing tables update to send traffic to the new location automatically.
From the outside world’s perspective, nothing changed. Traffic is still going to the same IP address, it has no idea the workload physically moved to a different building, city or cloud. There are no DNS records to update, no TTLs to wait out, no caches still pointing at the dead site. Failover is effectively instant.
This is sometimes called IP-based GSLB (global server load balancing), and it is fundamentally more robust than the DNS-based GSLB that most appliances offer, precisely because it doesn’t depend on DNS behaving itself.
Why this matters for compliance and testing
Regulators increasingly want more than a documented plan, they want evidence you’ve tested it and that recovery is fast and reliable. DORA, for example, expects firms to run failover tests and progressively more demanding resilience exercises. A DR design that depends on DNS propagation is hard to test convincingly and harder still to guarantee a recovery time on, because you don’t control how the world’s resolvers cache your records.
Routing-based failover gives you a recovery mechanism you can demonstrate, time and repeat with confidence. The cutover is deterministic and near-instant, which makes both the test and the audit conversation dramatically simpler.
Real-world uses
Datacenter-to-datacenter DR. A financial-services software provider runs its applications across two of its own datacenters and uses IP failover to move between them. When a failover event happens, no IPs change and no DNS is updated, the applications simply come up at the other site and traffic follows.
Cloud migration and vendor lock-in. Because the IP belongs to you rather than to any datacenter or cloud provider, you can move workloads between environments without renumbering. That same portability quietly reduces lock-in: your address goes with you.
Multi-site operations. Organisations with many locations, each needing resilient, unchanging connectivity for payments, security systems or monitoring, can standardise on a single approach to keeping critical addresses alive through any disruption.
Where DR meets hand-holding
There’s an honest caveat worth stating: DR is daunting for a lot of teams, and smaller organisations increasingly carry the same resilience expectations as large enterprises without the same specialist staff. Replicating applications, keeping them in sync, deciding how to fail over and how to fail back, it’s a lot. The right partner does more than hand you connectivity; they can host the recovery site, own the routing and failover, and help design the whole flow, so DR stops being a project you don’t have the people for and becomes a service you can actually rely on.
Consolidating hosting, routing and failover with one provider also removes hops and hand-offs. Every additional vendor in a DR chain is another dependency that can fail at the worst moment. Fewer moving parts, controlled end to end, is simply more resilient.
The takeaway
If your disaster recovery plan depends on DNS to redirect traffic, your recovery time is at the mercy of resolver caches you don’t control, and anything hard-wired to an IP won’t fail over at all. Moving the IP instead of the DNS record makes failover instant, testable and complete. In a world where regulators want proof, not promises, that’s the difference between a DR plan on paper and one that actually works.
Facing a DR or resilience requirement or a compliance deadline? Talk to our team about routing-based failover and DR hosting built for regulated workloads.
