The Cloud You Can't Afford to Leave — and the January Deadline That Changes the Math

On May 29, 2026, a trade publication ran a story about a word I had been hearing in client calls for two months: tokenmaxxing. It is the habit of running every possible task through an AI model so your usage numbers look impressive — and it had just collided, very publicly, with the bill. Meta and Amazon had reportedly pulled internal leaderboards that ranked employees by how many AI "tokens" they burned, because people had started chasing the score instead of the work. Uber and Microsoft were said to have blown through entire annual AI budgets in a matter of months.

I read that story and thought about a conversation I'd had the week before with a mid-size operations leader who was staring at a cloud invoice that had quietly doubled. She wasn't asking me how to optimize it. She was asking a question I'd almost never heard a customer ask out loud in ten years of this work: "What would it actually cost us to leave?"

That question is everywhere right now. After a decade of "cloud-first by default," a record share of companies are seriously pricing the exit. And when they do, most of them discover the same uncomfortable thing she did: the cloud was never built to keep you with quality alone. It was built so that leaving is expensive.

So what do you do when the thing you can't afford to keep is also the thing you can't afford to leave?

What actually happened — and why everyone is asking the exit question at once#

Three separate pressures arrived in the same eighteen months, and together they turned "cloud cost" from a back-office line item into a board-level topic.

The AI bill came due

For most of the last decade, cloud spending grew quietly in the background. Then generative AI arrived, and the meter started spinning at a speed nobody had budgeted for. Think of it like a rental car that bills by the mile. For years your team drove normal distances. Then everyone got handed an AI assistant that, for a single complex task, can consume ten to fifty times the "miles" of an ordinary request — and "agentic" workflows, where the AI runs many steps on its own, can run that figure far higher.

The result was sticker shock at scale. One industry survey in 2026 found that 40% of enterprises overspent their planned cloud AI budget. A separate analysis estimated that across the industry, expensive graphics processors — the specialized chips, called GPUs, that run AI — sit at roughly 5% utilization on average, which is the technology equivalent of leasing a whole parking garage to store one car. The named casualties made headlines: companies burning a year's AI budget in months, and the late-May backlash against "tokenmaxxing" that followed. None of those numbers are audited financials — they come from earnings-call commentary, vendor surveys, and tier-one tech reporting — but the direction is not in dispute. The bill got big enough that finance noticed.

The repatriation wave got real — but it's smaller than the headlines

Once finance notices, somebody asks whether the work has to live in the cloud at all. That's "repatriation" — moving a workload from a public cloud back to your own servers or a private data center. The phone book version: you've been renting a furnished apartment, and you start doing the math on buying a house for the rooms you actually live in.

The survey numbers are striking. A Barclays CIO survey found a record share — reported around 83% — of technology leaders planning to move some workloads back from public cloud. An IDC study put the figure near 80% of enterprises expecting to repatriate some compute or storage within a year. But here is the part the headlines skip, and the part I want you to hold onto: the same IDC research found only about 8% of organizations moving entire workloads off the cloud. This is not an exodus. It is selective re-balancing — companies finally putting each workload on trial and asking it to justify where it lives. Plenty of credible analysts argue the big repatriation percentages are misleading precisely because they get read as "everyone is leaving" when net cloud spending is still growing.

The lock-in became visible

The third thing that happened is subtler, and it's the one I want to spend the rest of this post on. When companies actually tried to price the exit — not to leave, just to understand their options — they ran straight into a toll booth most of them had never looked at directly. They discovered that the cost of leaving the cloud had quietly become a number large enough to keep them from leaving even when the math said they should. That's not a billing detail. That's the whole shape of the relationship, and almost nobody had drawn it on a page before this year forced them to.

For a decade, that toll stayed invisible because nobody had a reason to test the door. The cloud was growing, budgets absorbed it, and "we'll deal with it later" was a perfectly rational answer. The AI bill is simply what made "later" arrive. So before we talk about what to do, it's worth understanding exactly what that toll is made of — because it's not one charge, it's two, and only one of them shows up on your invoice.

The Exit Tax — the toll you didn't know you'd signed up for#

Here is the structural fact that makes cloud different from almost any other vendor relationship you have.

Cloud providers charge you very little to put data in, and a meaningful amount to take data out. That outbound charge is called egress. Picture a self-storage unit where moving your boxes in is free, but every box you carry out costs a few dollars — and you only find out at the loading dock. On the big three providers, egress runs roughly eight to twelve cents per gigabyte after a small free allowance. For a few terabytes that's an annoyance. For a data-heavy or AI-heavy operation, it's a number that can stall a migration before it starts.

But egress is the small part. The bigger toll is what I'd call architectural lock-in. When you build on a cloud's proprietary managed services — its particular database, its particular serverless functions, its particular data pipelines — you're not just renting capacity. You're wiring your house with one manufacturer's outlets. Leaving doesn't just mean carrying your boxes out; it means rewiring every room before anything works in the new place. That rewiring — the engineering time to rebuild on a different foundation — is usually the real cost of leaving, and no invoice line shows it to you in advance.

The cloud was never priced to keep you in with quality alone. It was priced to make leaving expensive — and for a decade, that worked.

This is why the right mental model isn't "vendor." It's closer to "landlord." A good vendor keeps you by being worth it. A landlord can keep you by making moving painful. Most cloud relationships are some of both, and the exit tax is the part nobody quoted you when you signed.

I want to be fair here, because it would be easy to turn this into a villain story and it isn't one. The cloud earned its place. The elasticity is real, the global reach is real, and for spiky, unpredictable, or early-stage workloads it is still the obviously correct choice. The problem isn't that the cloud is bad. The problem is that the pricing model quietly converted a convenience into a captivity, and almost nobody modeled the difference until the AI bill forced them to.

The January deadline that's quietly resetting the leverage#

Now the part most people running US companies have completely missed, because it's buried in European regulation.

The European Union passed something called the Data Act, which came into force on January 11, 2024. One of its core goals is to make switching cloud providers "free, fast, and fluid" — the EU's words, not mine. The mechanism is blunt: cloud providers operating in the EU must remove the charges associated with switching, including egress charges tied to leaving, by January 12, 2027. During the transition window, they're only allowed to charge what the switch actually costs them, not a penalty designed to keep you.

You can already see the effect, and it happened before the deadline. In anticipation of the law, the major providers pre-complied where it stung most: Google waived exit egress in January 2024, AWS followed on March 5, 2024, and Microsoft did the same for Azure on March 13, 2024. When a vendor voluntarily drops a fee they spent a decade defending, that's not generosity — that's the clearest possible admission that the fee was a barrier to leaving in the first place.

Two honest caveats, because the headlines oversold this. First, these free-exit programs are narrower than they sound. They generally apply when you're fully leaving or switching, not when you're running two clouds side by side — the law specifically preserves charges for ongoing parallel use, and providers attach conditions (Google wants you to close the account; AWS doesn't, but limits repeat claims). Second, if your company only operates in the US, the law doesn't cover you. But — and this is the leverage — you inherit the programs the law forced into existence. The free-exit egress offer exists globally now because of a European deadline. You just have to know to ask for it.

What this means for your company — and it depends on your size#

The same forces land very differently depending on how big you are. Here's the honest version for each.

Large enterprises (1,000+ employees)

You almost certainly already run a hybrid setup, and you likely have a FinOps function — the team whose job is watching cloud spend — so none of this is new vocabulary. Your version of the problem is concentration and exit modeling. The board isn't asking "should we leave the cloud"; it's asking "how much of our operation depends on one provider's proprietary services, and what would it cost us to move the steady-state pieces?"

Your real lock-in isn't egress — for you that's a rounding error — it's the architectural rewiring I described. The work is to build an honest exit-cost model per workload: what's cheap to move (raw storage, predictable compute) versus what's expensive to move (anything built deep on a proprietary managed service). The repatriation candidates that actually pencil out are the boring, steady ones — databases that run the same load every day, inference workloads with predictable demand. Treat this as a supply-chain risk and asset-management exercise, because that's what it is: you're inventorying where your critical data and dependencies live and what your concentration risk really costs.

Mid-size companies (100–999 employees)

You're in the toughest spot, and I say that with sympathy because most of my conversations like the one I opened with are with you. You have the budget for a "cloud cost initiative" — the CFO will happily approve it after seeing this year's invoice — but you don't have the headcount to run two environments well, and that's the actual risk. Repatriation done badly trades a predictable cloud bill for an unpredictable operational one.

Your most useful move isn't a big migration. It's three smaller things: find the one or two workloads whose cost has grown the fastest, price what it would take to move just those, and — critically — call your provider and ask about free egress on exit before you assume you're trapped. Most mid-size firms I talk to don't know that program exists, and it can quietly remove a line item the CFO was bracing for. You're also the size closest to the famous exit stories, which means the precedent is instructive — but those companies usually had unusually strong in-house infrastructure talent, and you'll need to be honest about whether you have it or have to hire it.

Small & growing companies (Under 100 employees)

For you, "repatriation" almost never means buying servers, and anyone telling you to build a data center is selling something. Your version of the exit tax shows up as a single surprise: a backup you pulled, a data export for an analytics project, and suddenly there's an egress charge you didn't know existed. You have essentially zero negotiating leverage with a hyperscaler, and that's fine — you're not trying to leave, you're trying not to get quietly squeezed.

Your practical moves are smaller and cheaper. Know roughly where your data lives and how much it would cost to pull it. Lean on providers with genuinely cheap or zero egress for the data-heavy pieces. And when an AI feature in a tool you use gets more expensive, understand that you're often paying a SaaS vendor's passed-through AI costs — which is a renegotiation conversation, not an infrastructure project. The 37signals-style "we left the cloud and saved millions" story is inspiration for you, not a template.

What to do Monday morning#

You don't need a migration plan to make progress this week. You need to see the toll booth clearly. Here's where I'd start.

1. Pull your egress number — just that one line. Open last month's cloud bill and find the data-transfer-out charge. You're not trying to act on it yet; you're trying to learn whether your exit tax is a rounding error or a real barrier. This is free and takes twenty minutes, and it tells you how trapped you actually are. Most leaders have genuinely never looked at this number in isolation.
2. Call your provider and ask about free egress on exit. Every major cloud now has a program — forced into existence by European regulation — that waives the cost of pulling your data out when you're switching or leaving. Ask whether you qualify and what the conditions are. Even if you have no plans to move, knowing the exit is cheaper than you thought changes every future negotiation. This is a phone call, not a project.
3. Make a one-page list of your "landlord" dependencies. Write down the proprietary services you'd have to rebuild if you ever left — the specific database, the specific serverless platform, the specific pipeline. You don't have to change any of them. You just need to know, on a single page, where your architectural rewiring cost lives. This is the conversation, not the technical change: get your most senior engineer and your finance lead in a room for an hour and build the list together.
4. Find your three fastest-growing line items and ask "why." Sort your bill by what grew most this year. If AI or GPU spend is on that list, ask the harder question underneath it: is that spend producing measurable value, or is it tokenmaxxing — usage that looks like productivity but isn't? You may save more by governing the spend than by moving it.
5. Pick one steady, boring workload and price the move. Not your whole operation — one predictable, unglamorous workload that runs the same load every day. Get a real number for what it would cost to run it somewhere cheaper or on owned hardware over three years, including the people-time to operate it. The number itself is the deliverable; it makes every "should we repatriate" debate concrete instead of theoretical.
6. Fold the 2027 date into your next renewal. If any part of your business operates in the EU, the January 12, 2027 removal of switching charges is now a negotiating chip — bring it to your renewal conversation. If you're US-only, you still ask for the vendor's existing free-exit program. Either way, the leverage you have right now is higher than it has been in a decade. Use it before the renewal auto-renews.
7. Decide who owns this question going forward. Cloud cost stopped being an IT footnote and became a finance-and-strategy topic. Name one person — even part-time — who owns the ongoing job of pricing what staying costs versus what leaving costs. Without an owner, this slides back into the background until the next surprise invoice.

If you want a place to start#

If you get to step three or step five and realize you don't have a clean way to model the exit cost or the vendor-concentration risk, that's a normal place to want a second set of eyes. Mapping where your critical data and dependencies live, and what it would cost to move them, is essentially a supply-chain-risk exercise — the same discipline a framework like the NIST Cybersecurity Framework calls vendor and asset management. A readiness toolkit built around that framework gives you the inventory structure to do it methodically, and a practitioner-led advisory engagement is genuinely useful when the decision is "which workloads move and what does the exit actually cost" — because that's a judgment call, not a checklist. I mention those because they're the relevant reference material, not because this post is a pitch: every action above stands on its own, and you can run all seven without spending a dollar with anyone.

The uncomfortable truth#

So, back to the question I opened with — what do you do when the thing you can't afford to keep is also the thing you can't afford to leave? The honest answer is that you stop treating "cloud-first" as a default and start treating every workload as a decision you have to re-price periodically, the way you'd re-shop insurance instead of letting it auto-renew forever. Repatriation isn't an anti-cloud movement, and it isn't a fad. It's the first time most companies have actually been forced to put a number on what staying costs them — and once you've seen that number, you can't unsee it.

What I expect over the next six to twelve months is more of this, but quieter and more disciplined. Fewer dramatic "we left the cloud" headlines, more boring, workload-by-workload moves that never make the news. The AI cost panic will settle into ordinary governance. The 2027 European deadline will keep pulling exit costs toward zero, and the vendors will keep competing a little harder to keep you because they finally have to. That's a healthier market than the one we've had, and it's better for you whether you ever move a single workload.

For what it's worth, after ten years of watching companies sign cloud contracts they never read closely, the most encouraging thing I've seen this year isn't anyone leaving. It's the number of leaders finally asking what leaving would cost — because that question, asked early and asked honestly, is the one that gets you a fair deal even if you never use the door.

— Charles Redding, Founder, DLegendDigital