What most disaster recovery plans still get wrong

If you’ve worked on a disaster recovery plan, you’ve likely focused on restoring infrastructure. But many organizations discover that getting systems back online doesn’t automatically mean employees can get back to work. The issue usually isn't the technology—most organizations recover infrastructure exactly as designed. The challenge is that recovering systems and maintaining business continuity aren’t the same thing. 

When disruption happens, employees don't care whether a data center has failed over successfully. They care whether they can access the applications and information they need to do their jobs. 

That’s where many disaster recovery plans fall short. They answer the question, "Can we recover our systems?" when the business is really asking, "Can our employees still work?"

The disaster recovery challenges you can’t afford to overlook 

Most organizations encounter the same three disaster recovery challenges. Access becomes the bottleneck. 

Infrastructure may recover, but employees still can’t get back to work if the supporting services they rely on aren’t available. Identity providers, virtual private networks (VPN), remote access gateways, or load balancers can all become dependencies of the recovery plan. If those services aren't included in the failover strategy, applications may be available while users remain locked out. 

Recovery slows when employees can’t access the tools and services they need, even after the infrastructure is back online. Security becomes the next challenge. 

Temporary exceptions, relaxed security controls, or bypassed conditional access policies may help employees get back online faster, but they can also introduce unnecessary risk during an already stressful event. 

Recovery plans should enable business continuity without compromising security. 

Modern work has changed the recovery model 

Many disaster recovery strategies were designed around employees working from corporate offices on managed devices connected to trusted networks. But today's workforce expects secure access from multiple locations, networks, and devices.  

Recovery strategies built around a traditional office model often don’t reflect how people work today. As a result, employees may still be unable to access the applications they need even after systems are restored.

A different way to think about disaster recovery 

A successful recovery strategy isn’t defined by how quickly infrastructure comes back online. It’s defined by how quickly employees can get back to work. Start by asking a different question: How will employees continue working while recovery is underway? 

That shift in perspective changes how you design your recovery strategy. 

Organizations running Citrix often discover that components such as NetScaler gateways, StoreFront, and supporting databases become critical dependencies during failover. If those components fail with the primary site, applications may recover before users can reach them. 

Organizations relying on Azure Virtual Desktop face a different challenge. While Azure provides regional resiliency options, many deployments still require additional architectural planning to provide resilience beyond a single region. 

An alternative architectural approach is to separate the access and control planes from the infrastructure itself. With Horizon Universal Broker, for example, the brokering layer runs in a cloud-hosted control plane rather than being tied to a single data center. Users connect through the same URL whether their desktop is running on premises, in Amazon Web Services (AWS), Azure, or a recovery site, making failover largely transparent from the user's perspective.

A lesson from the field 

One financial services engagement reinforced this way of thinking. 

The project began as a disaster recovery initiative, but the conversation quickly shifted from infrastructure resilience to employee productivity. The goal was more than just recovering systems—it was also ensuring employees could continue working without changing URLs, reconnecting through different gateways, or waiting for IT. 

A geographically distributed Horizon deployment using centralized brokering, global entitlements, and cross-region failover helps employees stay connected when a disruption affects a single location. By separating user access from any single site, employees continued working while recovery operations occurred in the background. 

Organizations often find that once user access is no longer tied to a single location, disaster recovery conversations shift from restoring infrastructure to maintaining productivity. 

Let’s continue the conversation 

If you'd like to explore the architectural patterns behind access-centric disaster recovery in more detail, watch the webinar replay. Explore real-world customer scenarios, lessons learned from the field, and practical design considerations for building more resilient digital workspaces.