Multi-Cloud Isn't a Project. It's a Side Effect.

Every team that’s tried to go multi-cloud has hit the same wall: it was never really a software problem. The code was fine. What broke was the architecture.

At a membership platform I worked on, a failover meant to improve reliability instead sent every customer an email about rewards and gift cards from years past — because the offset state tracking who’d already been notified didn’t migrate with the failover. The result wasn’t a minor bug. It was a resend to the entire consumer base, and a cost to the business in the millions.

The instinct after an incident like that is to plan the “proper” multi-cloud project: a dedicated effort, estimated at a year of engineering time, to make failover state consistent across providers. That’s the traditional path — and it’s exactly the wrong frame.

Here’s the reframe: multi-cloud isn’t a target you build toward. It’s a side effect of a more fundamental decision — building durability-first. When state, retries, and recovery are guarantees of the execution layer rather than logic your team hand-rolls per cloud, failover stops being a year-long architecture project. With Temporal’s durable execution model, what was estimated at a year became a matter of enabling replication with a single click.

You’ll leave with a different mental model: multi-cloud as a test of your architecture’s fundamentals, not a project you fund separately.