Why Disaster Recovery Should Be Designed Around Workload Availability, Not Workload Location
For the better part of the last decade, the IT industry has been asking the same question:
Where should this workload live?
The answers have varied: public cloud, private cloud, on-premises, edge. But the conversation has remained remarkably consistent. We have spent years debating location. Cloud became the default answer. Move applications to the cloud. Move storage to the cloud. Move backup to the cloud. Move disaster recovery (DR) to the cloud.
Cloud deserved much of that enthusiasm — fundamentally changing how organizations collaborate. It enabled remote work, expanded geographic resilience, and made data accessible. Accessible far beyond the walls of a single office or data center. Cloud solved a real problem.
But it seems we may have confused accessibility with availability, somewhere along the way. Those two things are not the same thing.
Cloud didn't fail. We simply expected it to solve a problem it was never designed to solve on its own. DR has never been about where workloads live. It's about ensuring workloads remain available — or can become available again quickly enough to keep the organization in business. That distinction is becoming increasingly important as organizations generate more data, adopt AI, and support users working from everywhere.
The future of resilience won't be determined by where data is stored. It will be determined by how intelligently organizations design the architecture around it.
Many Have Been Optimizing the Wrong Thing
DR strategies have for years focused on protecting data. Replication. Backup. Copies. Geographic redundancy. Those remain essential capabilities. But protecting data and keeping a business operational are not the same objective.
A successful backup tells you your data survived. It doesn't tell you how quickly your people can get back to work. A replicated dataset can exist while users wait hours - or days - for access. The real objective has never been just about protecting storage. It's also about maintaining availability.
That shift in thinking changes the conversation. Instead of asking where data should live, organizations should be asking what the workload actually needs to remain operational.
Accessibility Solved Yesterday's Problem
Cloud transformed collaboration. It allowed organizations to work from anywhere. It removed geographic barriers. Those advantages remain undeniable. But every architectural decision creates tradeoffs.
Organizations managing AI datasets, engineering models, healthcare imaging, media assets, and other data-intensive workloads now routinely work with tens — or even hundreds — of terabytes and even petabytes of information.
At that scale, something interesting happens. Storage often stops being the bottleneck. The bottleneck has become moving the data. Organizations embraced cloud collaboration because we thought it solved accessibility. But many ultimately encountered the same operational challenges: growing storage and data management costs, upload and download bottlenecks and costs (ingress and egress), cloud repatriation (i.e., getting into the public cloud is often far easier than getting out; repatriation can expose substantial technical, financial, and contractual friction).
Again, not suggesting cloud was the wrong answer. It simply means the industry kept solving yesterday's problem while a new one quietly emerged.
The Biggest Risk Isn't Only Losing Data
It's also about losing time.
Think about how many workflows still begin with moving information. Upload it. Download it. Synchronize it. Replicate it. Copy it again. Each movement consumes bandwidth. Each copy consumes storage. Each transfer introduces another dependency. Everything affects recovery.
For organizations working with massive datasets, moving information has quietly become one of the largest obstacles to maintaining business continuity.
That's not a cloud problem. It's an architectural problem.
Perhaps the better question isn't: "Where should the data live?"
Perhaps it's: "Why are we moving the data at all?"
Design Around the Workload
Every workload is different. A financial transaction system has different availability requirements than an AI training environment. Medical imaging behaves differently than office documents. Media production has different recovery objectives than a virtual desktop infrastructure.
Treating every workload the same doesn't simplify DR. Quite the opposite. It often makes it more complicated. Instead, organizations should begin with the workload itself. What level of performance does it require? How quickly must it recover? Who needs access? How often does the data change? How large is it?
Only after answering those questions should the infrastructure conversation begin. Sometimes cloud is the right answer. Sometimes local infrastructure is. Often it's both.
Architecture should follow the workload - not the other way around.
The Future of Disaster Recovery Starts with a Different Question
The next generation of DR won't be defined by where organizations store data. It will be defined by how effectively they keep workloads available. That requires a different mindset. Not cloud-first. Not on-premises-first. Architecture-first.
For years, the industry has asked: Where should this workload live? The organizations leading the next decade will ask something entirely different: Regardless of where it lives — how do we keep this workload continuously available?
That's a subtle change in wording… but it's a profound change in thinking.
One question is about infrastructure. The other is about resilience and business continuity. And that's where the future of DR begins. The right plan has the added benefit of great economic/resource efficiencies too.
