Leaving a Hyperscaler: The Exit Costs Procurement Misses

Most cloud business cases model the way in carefully and the way out not at all. Procurement compares unit prices, negotiates a commitment, signs. The exit appears in the file as a clause nobody reads until the day somebody wants to leave.

This piece lists what an exit actually involves, so you can price it before signing rather than discover it during a migration.

The line everyone knows: egress

Moving data out of a provider's network has historically been charged by the gigabyte, and it is the cost people quote when they discuss lock-in. It is real, but it is also the easiest cost to estimate: you know roughly how much data you hold, and the provider publishes a rate card.

It is also the one cost that European regulation is actively removing for customers who fall within its scope. The Data Act (Regulation (EU) 2023/2854) has applied since 12 September 2025, according to the European Commission. The Commission states that switching charges, including data egress charges, are to be fully removed from 12 January 2027, with a transitional period from 11 January 2024 during which providers may still charge costs. The regulation's Article 29 says it directly: from 12 January 2027, providers of data processing services shall not impose any switching charges, and between 11 January 2024 and 12 January 2027 they may impose reduced switching charges.

Two cautions. First, read what the ban covers: charges for switching. It does not cover everything a migration costs you. Second, the rules are not frozen. A Digital Omnibus package proposes amendments to the Data Act, and a July 2026 legal analysis describes a Council compromise text still under negotiation. Among the proposals: transitional relief for some contracts concluded on or before 12 September 2025, and an express permission for proportionate early termination penalties in fixed-term contracts. These are proposals, not law, according to the sources cited below. Check the current text with counsel on the day you sign.

What the switching rules require of contracts

Article 25 of the regulation sets minimum content for contracts on data processing services. Two points matter for procurement: the customer must be able to start switching within a notice period capped at two months, and the switch must happen without undue delay and within a mandatory maximum transitional period of 30 calendar days, during which the provider keeps the service running. Article 30 adds technical duties: for infrastructure services, the provider must take all reasonable measures to facilitate functional equivalence, and where no common specifications exist it must export all exportable data in a structured, commonly used and machine-readable format on request.

Note the phrasing. "Reasonable measures" and "exportable data" leave room. Whether your workload is exportable, and what functional equivalence means for a service built on a provider's proprietary component, is exactly what you should ask about before the contract exists.

The cost that does not appear on any invoice: proprietary APIs

Your applications call managed databases, queues, identity services, serverless runtimes and machine-learning platforms. Every call is a line of code written against an interface that exists on one platform. Leaving means rewriting those calls, retesting them and re-establishing the behaviour you relied on, including the failure modes you never documented.

Estimate it by inventory, not by intuition:

List every managed service in production, with the number of applications that call it.
For each, mark whether an open or widely implemented alternative exists (a standard database engine, a standard message protocol) or whether the interface is proprietary.
For the proprietary ones, ask the owning team how long a replacement would take. Write down the answer. It will be uncomfortable.

Skills and organisation

Your engineers have spent years learning one provider's console, tooling, identity model and quirks. Your runbooks, alerting and incident habits are built on them. A migration is also a retraining, with the productivity dip that implies and the risk that the people who understand the old platform are not the people who will be asked to build the new one.

Include in the exit estimate: training time, parallel running of two platforms, on-call coverage during cutover, and the cost of retaining specialists you might otherwise let go.

Contract terms that decide the price

Read these before the commercial discussion, because they are cheaper to change before signature:

Commitment structure. A multi-year spend commitment continues whether or not you are still using the platform. Ask what happens to unused commitment when you migrate, and whether it can be redirected to other services.
Early termination. What does it cost to leave before the end of the term? Given the proposals above, expect providers to argue for the right to charge proportionate penalties.
Data return. In which formats, how quickly, and at whose cost? Does the format include configuration and metadata, or only raw data?
Deletion. How and when is your data deleted after exit, and what proof do you receive?
Parallel running. Can you run old and new platforms at once during migration without penalty? Ask about this explicitly, since a migration without overlap is a migration without rollback.
Price changes. How much notice, and what right to exit, if prices or terms change mid-contract?

Turning this into a number

Build a one-page exit estimate and attach it to the purchase decision. Columns: data movement, application rewrites, retraining, parallel running, contractual penalties, project management. Fill each with a range and a named owner of the estimate. Where you cannot estimate, write "unknown" and treat it as a risk, not as zero.

The goal is not to make leaving cheap. Some of the best platforms have high exit costs and are still the right choice. The goal is to take that cost knowingly, so that the day you want to leave is a project and not a crisis.