Skip to content
All services
Solution · Multi-cloud rationalization

Multi-cloud you can explain. And consolidate the rest.

Three cloud bills, two storage buckets, and a Kubernetes cluster you cannot quite explain. The rationalization scope maps workload-to-cloud topology, quantifies cross-cloud egress, and gives an honest keep-or-collapse call per workload — then ships the consolidation in fixed-fee waves.

The shape of this engagement

Most multi-cloud is accidental, not architectural. An acquisition brought a workload. A "let us try" experiment never got rolled back. A team's procurement quirk created a second provider relationship. Five years later, three clouds are running and nobody can articulate why each workload lives where it does.

The rationalization scope starts by mapping reality — what workload runs where, what writes to what, what the cross-cloud data-flow looks like, what the egress bill is. Then per workload, an honest call: keep here for a named reason, collapse to the primary cloud, or replatform entirely. Genuine multi-cloud needs exist; they are also rarer than the current footprint suggests.

What typically gets surfaced

  • Accidental multi-cloud. Workloads on a second cloud with no remaining reason to be there. Collapse is straightforward.
  • Cross-cloud egress hotspots. Warehouse-to-app traffic, app-to-app integrations, or backup replication running across clouds and burning 4-12% of the total cloud bill in egress alone.
  • Kubernetes portability claims that do not hold. EKS or GKE clusters depending on cloud-native IAM, ALB / GLB controllers, and cloud-native storage classes. Real portability cost is usually 3-5x what the team estimates.
  • Genuine data-residency forcing. Sovereign-cloud requirements (EU, Australia, India) that legitimately need workload split. These stay; the report names them explicitly.
  • BCP at the wrong level. Teams running multi-cloud for "cloud provider outage" risk when the actual outage probability and blast radius does not justify the architectural tax.

What you receive

  • Workload-to-cloud topology map (current state) with data-flow direction per workload pair.
  • Egress cost quantification against your existing billing exports — by source-destination cloud pair.
  • Per-workload keep-or-collapse recommendation with cost delta, complexity rating, and the regulatory or operational reason driving the call.
  • Sequenced consolidation plan: which workloads move first, what the wave dependencies look like, what the parallel-run window is per wave.
  • Execution quote for the recommended consolidation (separate fixed-fee scope).

How to start

Multi-cloud rationalization typically starts with a Discovery Sprint scoped to your specific footprint. Book a 30-minute call and we will scope the Sprint against your cloud-account topology and rough workload count. For the broader FinOps cut alongside the rationalization, see the FinOps and cost reduction service.

Questions buyers actually ask

Before you book a call.

Is multi-cloud always the wrong answer? ▾
No, but it usually is. Genuine multi-cloud needs (regulatory data residency forcing different sovereign clouds, true vendor risk where one cloud provider is contractually unacceptable, BCP at the cloud-provider level) are rare. The more common pattern: a workload ended up on a second cloud because an acquired team brought it, or because a "let us try X" experiment never got rolled back, or because one team had a procurement quirk. Discovery names the actual reason for each workload and recommends keep-or-collapse per workload.
What does the rationalization analysis actually produce? ▾
A workload-to-cloud topology map showing what runs where today, what writes to what, what the cross-cloud egress bill looks like, and which workloads are genuinely tied to a specific cloud vs portable. Per workload: keep-or-collapse recommendation with the cost delta, the migration complexity rating, and the regulatory or operational reason if any. Output is a deck + sheet + execution plan, same shape as the X-Ray output.
How much does cross-cloud egress typically cost? ▾
For a typical mid-market multi-cloud setup, egress sits in the 4-12% of total cloud bill range. The biggest single line item is usually warehouse-to-app egress where the analytical warehouse lives on one cloud and the operational app lives on another. Discovery quantifies this exactly against your existing billing exports.
Do you handle the actual consolidation execution, or just the analysis? ▾
Both. The Discovery scope produces the rationalization plan; Execution scopes carry out the consolidation work in fixed-fee waves. Typical consolidation Execution: 8-20 weeks depending on how many workloads need to move and how operationally entangled they are. Both phases are fixed-fee.
What about Kubernetes and containerized workloads — do those make multi-cloud easier? ▾
In theory yes, in practice it depends on how much cloud-specific infrastructure the cluster depends on. EKS clusters using AWS-native IAM, ALB controllers, EFS for storage, and Secrets Manager are not really portable. GKE clusters with Workload Identity, Cloud DNS, and GCS-CSI are not really portable either. Discovery enumerates the cloud-specific dependencies per cluster — the portability claim is usually thinner than the team believes.
What if our finance team or board wants multi-cloud for vendor negotiation leverage? ▾
Honest answer: the leverage is real but usually overpriced. A "credible threat to move" needs a portable architecture, which costs ongoing engineering investment. For most mid-market teams, the negotiation savings do not exceed the architectural tax. We will say so in the Discovery report. If your situation genuinely warrants the portability investment, the report names what it would cost to build and maintain.