Table of Contents
TL;DR
A transformation that modernizes your systems without modernizing your ability to recover them has made the company faster and more fragile in the same motion. Disaster recovery was my responsibility through both transformations at a major national retailer, and actual disasters tested the plans. What the disasters taught: recovery is a property of the current environment, so every system the transformation changes is a recovery plan the transformation has invalidated.
Disaster recovery was one of my responsibilities at the major national retailer, and I held it through both transformations, which gave me a vantage point most transformation stories lack. We had 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 is the principle the disasters drilled into me. A disaster recovery plan is not a document about recovery in general. It is 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 rather than 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 was not 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 is our plan when the vendor is the disaster,” which is a different plan, needing different thinking, and it does not write itself.
And we tested, because the disasters had cured us of trusting untested claims. A recovery plan that has never run is a hypothesis with a binder. Some of ours failed their first tests, which is 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
Testing is 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: actually restoring from the backups, actually 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 not optional housekeeping; it is the moment the new environment’s recovery stops being a document and becomes a demonstrated capability. We scheduled those tests as part of each migration’s closure, which meant no system was declared transformed while its recovery remained a hypothesis.
The question for executives
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 is 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 cannot fake.
For more from this series, see the The Digital Transformation Hub: real transformations, lived from the inside, decades before the term existed.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.