Disaster recovery was one of my responsibilities at the major national retailer, and I held it through both transformations. That gave me a vantage point most transformation stories lack. We’d some disasters. Real ones, the kind that convert your DR documentation from a compliance artifact into a set of claims about to be tested. Some claims held. Some taught us things, including the discovery of a critical server under a desk in accounting that no plan had ever heard of.
Recovery is a property of the environment
Here’s the principle the disasters drilled into me. A disaster recovery plan isn’t a document about recovery in general. It’s a precise set of claims about a specific environment: these systems, on this hardware, with these dependencies, restored in this order, from these backups, within this time. Change the environment and the claims silently expire, and the plan keeps looking exactly as authoritative on the shelf.
Now consider what a transformation is: the deliberate, wholesale changing of the environment. Every system we moved to the new platform, every function we lifted to SaaS, every integration we rebuilt was a page of the DR plan quietly invalidated. A transformation is, among everything else it is, the largest disaster-recovery-plan destruction event a company ever voluntarily runs.
Which forces the choice in the title. Either recovery is transformed alongside the systems, plans rewritten, backup architectures rebuilt for the new platforms, restoration sequences re-derived from the new dependencies, or the company exits the transformation more modern and less recoverable than it entered, holding documentation for an environment that no longer exists.
What transforming recovery looked like
In our program, DR work rode inside the transformation instead of trailing it. When a function moved, its recovery moved as part of the same effort: new backup coverage before old coverage lapsed, restoration procedures rewritten against the new platform, dependencies re-mapped because the new world’s restoration order wasn’t the old world’s.
The SaaS moves changed the recovery question entirely, from “how do we restore this” to “what does the vendor guarantee and what’s our plan when the vendor is the disaster,” which is a different plan, needing different thinking, and it doesn’t write itself.
And we tested, because the disasters had cured us of trusting untested claims. A recovery plan that’s never run is a hypothesis with a binder. Some of ours failed their first tests, and that’s the point of testing: failures found in an exercise cost embarrassment, and failures found in a disaster cost the company.
A transformation is the largest disaster-recovery-plan destruction event a company ever voluntarily runs.Share on X
Why is testing where recovery becomes real?
A word on what “tested” means, because the term gets stretched. Reading the plan in a conference room is a review, and it catches missing pages. A tabletop exercise, walking the team through a scenario hour by hour, is better, and it catches wrong assumptions: the restore step that depends on a person who would be evacuated, the vendor contact who left two years ago.
But the tests that changed our plans were the ones that touched systems: restoring from the backups, failing over, on a schedule, against a clock. Those are the tests that discover the backup that completes nightly and restores nothing usable, and that discovery is only survivable when it happens in an exercise.
Post-transformation, the first live restoration test of each migrated system is the moment the new environment’s recovery stops being a document and becomes a showed capability. We scheduled those tests as part of each migration’s closure. That meant no system was declared transformed while its recovery remained a hypothesis.
What should executives ask about disaster recovery?
If your company is mid-transformation or recently finished one, ask this in your next steering meeting: which of our disaster recovery plans have been rewritten and tested against the new environment, and which still describe the old one? The answer tends to be illuminating, because DR is the workstream most easily deferred, it produces nothing visible when things go well, and its absence is only discovered on the worst day available.
The transformation books executives write almost never contain a recovery chapter, and it’s a marker of how rarely the authors carried that responsibility. The ones who did, and who can say what the disasters taught them, hold material their competitors can’t fake.
For more from this series, see The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
