You can sign off a DR design in this region and have it out of date before you've deployed it.
Procurement here runs long. The better part of a year for anything material is normal, sometimes well beyond. You scope the architecture, price it, walk it through the committees. Somewhere in that gap, the ground moves.
The part people miss is where it moves. Not the DR tool. The platform underneath it.
Most resilience tooling doesn't stand on its own. It plugs into a virtualisation platform at a low level, sitting in the write path. That integration exists at the platform owner's discretion, and platform owners have worked out that the ecosystem sitting on top of them is leverage rather than a courtesy. The hooks that third-party tools rely on get changed, deprecated, or quietly closed with each major version.
So you have two roadmaps to track and you own neither. The tool vendor will adapt. They usually do. But "usually" runs on their schedule, not your go-live. If the platform reaches the version that breaks the old integration while you're still in procurement, you deploy into a gap: the design you signed off no longer behaves the way the proposal promised.
This isn't an argument against the tools. It's an argument for a question that rarely makes the DR scope. What does the platform owner's roadmap do to this design over the next year or two, and what happens to us if their timeline and ours collide?
In a faster market you'd absorb it. Here the cycle is long enough that the platform can shift underneath you mid-purchase. That isn't a tooling problem, it's a sequencing one, and it belongs in discovery, not the post-mortem.
On paper, the best design in the room. In practice, a version behind before it's real.