The same DR tool, pointed at a different target, will not give you the same numbers. Plan around that, or get caught by it.
A common setup: replication between two data centres over a private circuit, recovery points measured in seconds. It's proven, everyone's comfortable, the figures get quoted with confidence. Then the DR target moves to public cloud, the same tool is reused, and the assumption travels with it. We'll get the same numbers.
You won't, and it's worth knowing why before it reaches an SLA.
Data centre to data centre, the tool replicates at the hypervisor level over a path you control. To a cloud target the mechanics change underneath you. Replication lands in object storage rather than a hypervisor. At failover there's a conversion step with no equivalent in the like-for-like setup, turning that stored data into disks the platform can boot. And the path is now public, so throughput and latency vary in ways a dedicated circuit doesn't.
None of that makes cloud DR worse. It makes it different. The recovery figures you proved between two data centres are not the figures you'll get to cloud, and quoting the old ones into a new design is how you end up defending a target you were never going to meet.
A second trap hides in the same conversation. "Near-zero recovery point" sitting next to "cold standby at DR" is two requirements that can't both hold. If the machines are powered off at the DR site, recovery is measured from the moment they boot and the data is applied, not from seconds ago. Cheap and fast are in a fight, and someone has to say which one wins.
The honest move isn't a bigger promise. It's a smaller one you can keep. Don't commit hard recovery figures to a cloud target you haven't tested. Run a real failover, measure it, agree that as the baseline, then watch for drift. A measured number you can stand behind beats a confident number borrowed from a different architecture.
Same tool, new target, new numbers. Prove them before you promise them.