Multi-cloud by accident vs. multi-cloud by design: A CTO’s guide

Ask most CTOs why their company runs workloads on two or three cloud providers, and the honest answer rarely involves the word decided. It involves the word happened.

An early engineer preferred AWS because the console was friendlier back in 2017. A data team stood up a project in Google Cloud because BigQuery was the obvious choice for the analytics work. Then an acquisition closed, and with it came a whole environment nobody had designed, and an accidental multi-cloud.

Being in multiple clouds is a fact about your infrastructure whereas, going multi-cloud is a decision about your architecture. The first describes where your workloads sit. The second describes why they sit there, on purpose, for a reason you could defend in a board meeting.

Josef Bárta, Chief Architect at Revolgy, describes the pattern from memory:

Usually people end up accidentally in multi-cloud for legacy reasons. There were some early movers in the cloud space, then other cloud providers came, oftentimes providing better service, or even just more user-friendly, easier to get going with, which pulled a lot of people in.

Then the acquisitions start. “A CTO or VP of engineering is a big AWS fan, and all of a sudden you’ve got your main setup nice in Google, and you’ve got your leftovers in AWS. Then before you manage to consolidate it, another acquisition comes, and again a new environment with new vendor lock-in issues. It can be just endless.”

There is a second way to arrive at multiple clouds.

• A company runs customer-facing workloads across two providers so a single data center outage never takes the product down.
• A regulated business builds a genuine exit path off a US hyperscaler because a contract or a national regulator requires one.
• A company selling software that customers deploy inside their own infrastructure builds it to run on whichever cloud that customer is already on.

Each of those is a specific, current, defensible reason, and the architecture is built around it from the start.

From a spreadsheet of cloud spend, the two situations look identical. Both show up as “we run on AWS and Google Cloud.” Only one of them is costing you something beyond the invoice.

This piece covers how to tell accidental multi-cloud and designed multi-cloud apart, what to do about the parts with no reason, and how to build the parts that do have a reason so they hold up instead of quietly becoming the next mess.

When multi-cloud is the wrong decision versus the right one

Decide what you’re actually running: a 5-question audit for accidental vs. designed multi-cloud

Open a spreadsheet with two columns: the cloud or workload on one side, the reason it’s there on the other. Work through these five questions for every provider and every major workload running on it.

“We don’t know” is a valid entry and the most useful finding this audit produces.

1. Can you name the one thing this cloud does that the others can’t?

Not “does well.” A team on AWS running BigQuery for analytics has a real answer, because nothing else in their stack offers the same integration between the warehouse and Google’s AI tooling. A stray S3 bucket left over from an acquisition three years ago is an artifact and not a capability. The test is whether removing this cloud would force you to rebuild something, or simply mean deleting something nobody has touched since the migration that never finished.

2. If this cloud disappeared tomorrow, would you know why it existed?

Imagine an actual page at 3am telling you this account is gone. Is the response “here’s what we lose and here’s why we accepted that risk,” or a scramble to work out what was even running there?

Teams that chose multi-cloud answer this in one sentence, because they made the tradeoff on purpose and wrote it down somewhere, even if that somewhere is a comment in a runbook.

3. Is there a single person who could explain this cloud’s purpose without checking anything?

Ownership decays faster than infrastructure. An account set up by an engineer who left eighteen months ago, inherited by whoever had admin access at the time, signals an accidental setup regardless of how well it currently runs.

A cloud with a current owner stays intentional, because someone is accountable for justifying it at every budget review. A cloud with no owner just persists.

4. Did the decision to be here predate the reason you’d give for it now?

This catches retroactive justification. “We’re multi-cloud for resilience” holds up if it was the reason from the start, with a load balancer and a failover plan built around it. It holds up much less if it’s being invoked for the first time in response to this audit, three years after an acquisition put the workload there.

The architecture tells the truth even when the explanation doesn’t.

5. What does this cloud cost you beyond the bill?

Engineering time spent context-switching between consoles and IaC dialects. A security review that now covers a second identity model. An on-call engineer holding two sets of alerting conventions. Spend and performance visibility split across two dashboards. None of it appears on a cost report, but all of it appears in how slow the team feels six months later.

Every row ends up in one of two buckets: a documented, current reason, or no reason found. That split is the input for everything below.

For everything with no reason: how to decide what to consolidate

The instinct to consolidate everything immediately costs almost as much as the instinct to never touch it. Run each no-reason item through this sequence.

1. Check for a hidden dependency first. Search your support tickets and contracts for the workload’s name. Contracts and support history surface the one legacy API a single enterprise customer still depends on.
   
2. Price the overhead before you price the migration. Estimate the ongoing cost of keeping it against the cost of removing it, in engineer-hours on both sides. Consider the unit economics of business units like cost per customer, per project, and per team. Two engineer-days a month is a different decision from two engineer-hours a quarter.
   
3. Look for a trigger that’s coming anyway. A contract renewal, an end-of-life date, or re-architecture work already scheduled. Migrating as a standalone project is expensive. Migrating as a rider on work you were already doing is close to free, and it’s the most underused lever in the whole exercise.
   
4. Assign one owner and one date, even when the decision is “not yet.” An undecided item with an owner and a review date gets revisited. An undecided item with neither becomes permanent by default.
   
5. Don’t consolidate into the biggest cloud by default. If the item is cheaper or more capable where it currently sits, moving it for tidiness trades a real advantage for an aesthetic one.

Some items migrate, some get a documented decision to stay, and a few turn out to have a reason the audit missed. That last group joins the next section.

For everything with a real reason: how to architect it so it doesn’t become a mess anyway

Plenty of companies with a defensible reason for two clouds still end up with the same operational mess as the accidental case. Because the execution is not planned. Here are the best practices to make it happen:

Standardize infrastructure as code, and let it differ where it has to

Terraform should define every resource across every cloud you deliberately run. The code will not look the same across providers, and forcing identical modules across different services creates its own mess. What matters is that nothing exists only as a manual console change living in one engineer’s memory.

As Josef puts it: “You will be writing a different Terraform for Google, different Terraform for AWS. It’s the software that’s the difficult bit.” The infrastructure layer is where clouds are allowed to look different. The layer above it needs discipline.

Keep the application layer portable, and be honest about what portability costs

Container-based compute like Cloud Run carries little lock-in, because the thing inside the container doesn’t care which cloud schedules it. A provider-specific serverless model built tightly around one event system buys actual capability and makes portability much harder to claim later. The mistake is claiming the portability of the first while building the second, and discovering the difference when you try to move something.

Treat the data layer as the real constraint

Compute is portable in a way data rarely is. SQL databases scale vertically well and horizontally poorly, so there will always be a single authoritative instance handling writes no matter how many clouds you span. The workable pattern is a primary in one cloud with read replicas or a standby in the other, and a tested failover procedure. Be honest about what that failover looks like.

Josef says:

It’s never going to be completely seamless. You can play around with caches, degrade the service instead of taking it down completely, but it’s still a little bit of a jolt.

Plan for that jolt through graceful degradation and caching, rather than promising a clean cutover the database can’t deliver.

A 90-day plan to convert accidental multi-cloud into a decided estate

Days 1 to 20: Build the honest inventory

• Week 1. Pull the account and workload list from your billing consoles. Cross-reference against your identity provider to catch accounts provisioned outside normal channels, which is where acquisition-era leftovers hide. The list will be longer than anyone expects.
  
• Week 2. Run the five-question audit against every line, and score how confident the person answering actually is. A confident “here’s why, and here’s who owns it” is different from a shrug written down to fill the cell. Flag every low-confidence answer.
  
• Week 3. Interview the people closest to the low-confidence items. Someone from an acquired company’s original engineering team usually knows exactly why a service still runs where it does, and that never made it into a wiki. This is the highest-leverage conversation in the whole 90 days, because it turns guesses into facts.

Deliverable at day 20: A confidence-scored inventory with every account and major workload marked “documented reason” or “no reason found,” an owner on every row, and a short list of genuinely unresolved items.

Days 21 to 60: Decide and start moving

• Days 21 to 35. Run the dependency check and the overhead-versus-migration pricing on every no-reason item. Cross-reference the list against contract renewals, end-of-life notices, and re-architecture work already planned. Anything lining up with a trigger in the next two quarters gets bundled into that work.
  
• Days 36 to 45. Make the decisions in a single working session with real authority in the room. Every item leaves with one of three outcomes: migrate, with an owner and a target date; keep for now, with a documented reason and a review date no more than two quarters out; or escalate. Zero undecided items leave the room.
  
• Days 46 to 60. Execute the lowest-risk migrations first. Start with items that have no live customer dependency, both to build momentum and to catch process problems on low-stakes work. Publish progress weekly, because visible progress is what keeps this from losing executive attention to whatever crisis arrives that quarter.

Deliverable at day 60: Every no-reason item has a decision and an owner, the low-risk migrations are done or moving, and the rest have decided dates.

Days 61 to 90: Architect the deliberate estate to last

• Days 61 to 70. Audit infrastructure-as-code coverage across every multi-cloud workload. Anything still configured by hand in a console gets treated with the same priority as migration work, because undocumented manual configuration is how the next sprawl starts.
  
• Days 71 to 80. Trigger a data layer failover in a controlled window and measure what customers experience. It will not be seamless. Design the customer-facing degradation deliberately rather than discovering the jolt during a real outage.
  
• Days 81 to 85. Consolidate monitoring and security visibility onto a single cross-cloud platform. This is the point where the operational cost of running multiple clouds either drops or stays exactly where it started.
  
• Days 86 to 90. Set the standing governance. Assign one owner accountable for the estate’s rationale. Schedule a quarterly review of the inventory itself, checking that every reason is still true and every owner is still accountable. Bring the five questions into your M&A and hiring processes, so the next acquisition or the next strong-willed hire’s cloud preference gets tested before it becomes tomorrow’s no-reason item.

Deliverable at day 90: A documented estate with IaC covering every workload, a tested failover path, unified cross-cloud visibility, and a governance process that catches the next accidental cloud early.

Ninety days is not enough time to migrate everything, and it doesn’t need to be. It is enough to replace a drifting cloud footprint with one where every part has an owner, a reason, and a review date.

Seeking expert help with re-architecting multi-clouds with Revolgy

An external architect has no stake in whether a cloud’s reason holds up, no relationship to protect with the engineer who made the call, and no instinct to be generous to a decision made on their own watch.

Revolgy has run this process across customers on all ends:

• Companies where the honest answer was full consolidation,
• Companies where the right call was to properly architect a deliberate multi-cloud setup for the first time,
• Companies where the best advice was to change nothing, because the setup was accidental in origin and no longer costing anything worth the disruption of fixing.

Revolgy runs free 45-minute 1:1 working sessions with senior architects. Bring the audit spreadsheet, even half-finished, or bring the one cloud account you can’t yet explain. Within 24 hours of the session, you receive a structured summary of the gaps identified and the recommended next steps.

Frequently asked questions

How do I know if my company is in multiple clouds by accident?

Check whether you can name a specific, current business reason for each provider, along with a clear owner accountable for that reason. The absence of a documented reason and a named owner, rather than the fact of running more than one cloud, is what signals an accidental setup.

Should I consolidate down to one cloud provider?

Only where no active business or regulatory reason exists for the extra provider. And only after pricing the overhead of keeping it against the total cost of migrating away. This is a workload-by-workload decision, not a one-size-fits-all decision.

Can I run the same database across two clouds at once?

Not in the way many teams assume. SQL databases require a single authoritative instance handling writes regardless of how many clouds you use, so a genuine multi-cloud data setup means a primary in one location with read replicas or a standby elsewhere, plus a tested failover procedure.

Is BigQuery Omni a way to become multi-cloud with my data?

No. Omni runs BigQuery’s compute inside your existing AWS or Azure environment to query data where it already lives, which is a cost and egress optimization. Your authoritative data strategy should be decided separately from whether you use it.