---
title: "Multicloud is a negotiating position"
url: "https://kyberfusion.com/blog/multicloud-is-a-negotiating-position"
description: "Running on two providers is rarely cheaper day to day. It is worth doing anyway, because the ability to leave is what determines the price of staying."
---

# Multicloud is a negotiating position

August 19, 2026·3 min read·Editorial team

A compute sled with four coloured lights on a small wheeled cart parked between two server racks

Multicloud is usually sold as resilience and usually justified on price, and it is mediocre at both. Two providers means two sets of tooling, two security models and two bills, and the day-to-day cost is genuinely higher than picking one and committing. It is still worth doing, for a reason that has nothing to do with either: **the credible ability to leave is what sets the price of staying.**

## What committed spend actually buys

The discount is real and so is the trap. Committing to a volume in exchange for a lower rate is straightforwardly good business — until the moment you want to renegotiate, at which point the commitment is the reason you cannot.

The mechanism is elegant. Discounts encourage consolidation. Consolidation deepens integration. Integration raises the cost of leaving. And a higher cost of leaving means the next discount does not have to be as good, because everyone in the room knows what the alternative would cost.

None of this requires bad faith from the provider. It is what any rational seller does with the leverage the structure hands them.

## What portability is actually worth

Here is the framing that changes the conversation internally: portability is not an architectural preference, it is an option, and options have a price.

Running a real workload on a second provider costs something every month. What it buys is the ability to say, credibly, that you could move — and the difference that makes to a renewal is usually far larger than the running cost of the option.

The word doing the work is _credibly_. A migration plan in a document is not an option. A workload that already runs somewhere else, that someone actually operates, is.

## What portable actually requires

Not the lowest common denominator. That is the standard objection and it produces bad systems: refuse every managed service, reimplement everything, spend the savings on engineers.

The useful version is narrower.

**Describe workloads by requirement, not by location.** What capability, what latency, what jurisdiction, what deadline. A workload specified that way can be placed anywhere that meets it — which is exactly what a grid needs in order to place it at all.

**Keep data portable even where compute is not.** Managed compute is easy to leave. Data in a proprietary format with egress costs attached is not, and that is where lock-in actually bites.

**Use managed services deliberately.** Some are worth the dependency. Write down which ones and why, so the choice is a decision rather than an accumulation.

**Test the exit annually.** Not plan it — run it. A day of work that turns “we could move” from a belief into a measurement.

## Why a grid makes this easier

Everything above is work that each organisation currently does alone, badly, and repeatedly.

A grid does it once. Workloads are described by requirement because that is the only way the grid can place them. Capacity from your own hardware, a European provider and a hyperscaler appear in the same terms, so comparison is arithmetic rather than a project. And the switching cost that makes committed spend such effective leverage drops, because moving work is what the system does normally rather than an event.

The point is not to stop using large providers. It is to buy from them from a position where the answer to a price increase can be something other than paying it.

-   multicloud
-   procurement
-   lock-in
-   portability

## Keep reading

-   [From a node on your shelf to a node in the network](https://kyberfusion.com/blog/from-your-shelf-to-the-network)
-   [One request, end to end: from a card to the cloud and back](https://kyberfusion.com/blog/one-request-end-to-end)