Cloud Exit Planning: Staying Portable Without Giving Up Managed Services

Write down how you would leave, then carry on using managed services. Those two things are not in conflict, and treating them as if they are is how businesses end up running everything on bare virtual machines to preserve a freedom they will never exercise. The useful exit plan is a one-page document that names where your data lives, how you would get it out, and which three components would need rebuilding. It takes an afternoon and it makes every procurement conversation easier.

What an exit plan is actually for

Most exit plans are written for someone else: an auditor, an insurer, a large customer’s procurement team, or a regulator in financial services. That is a perfectly good reason to have one. But the version that helps you is shorter and more honest, and it answers three questions: if this provider doubled its prices, raised a policy we could not accept, or suffered a multi-day regional outage, what would we actually do?

The answer is rarely to move everything. It is usually to move one thing, accept degraded service on another, and negotiate harder on the rest. Writing that down converts a vague anxiety into a short list of things worth preparing. It also tells you which parts of your architecture are genuinely load-bearing.

What changed: free exits and the January 2027 deadline

Two things changed and both are in your favour. First, the vendors moved. Google Cloud announced in January 2024 that customers migrating their data off Google Cloud entirely could do so with free network data transfer, applying to customers globally. AWS followed in March 2024, waiving data transfer out to the internet for customers moving off AWS, and updated the programme in September 2025 to give eligible customers 90 days to complete the move. Microsoft announced free egress for customers leaving Azure in the same month.

Second, the law moved. The EU Data Act entered into force on 11 January 2024 and became applicable on 12 September 2025. During the transition, providers may charge only costs directly incurred in facilitating a switch; the UK CMA’s own analysis of these programmes records that a full removal of switching charges is required from 12 January 2027. After that date, leaving should cost nothing at the transfer layer.

Note the consistent exclusion. None of these programmes makes everyday traffic between two clouds free, which is the pattern most teams actually want. If your plan depends on cheap ongoing transfer rather than a one-off exit, read what egress actually costs before you design around it.

Where the real lock-in lives

Here is the uncomfortable part. Transfer fees were never the thing keeping anyone in place. The real cost of leaving is distributed across things nobody lists on a price page: the identity provider your whole estate authenticates against, the deployment pipeline, the proprietary database features somebody used because they were there, the monitoring dashboards, the compliance evidence tied to one provider’s audit reports, and the fact that your team knows one console and not another.

That concentration is the reason regulators keep returning to this. The UK CMA’s 2025 market investigation found that Amazon and Microsoft hold positions of significant market power, and identified egress fees and interoperability barriers as limits on switching and multi-cloud use. In March 2026 the CMA announced that, following its engagement, both firms had set out material steps on egress fees and interoperability for UK customers, while the CMA opened a strategic market status investigation into Microsoft’s business software ecosystem. Progress on switching is being reviewed rather than concluded.

Lock-in worth accepting, and lock-in that is not

Lock-in is not a binary and it is not always bad. The question is whether the service is doing work you would otherwise have to do. Managed PostgreSQL is a good trade: the wire protocol is standard, your queries are portable, and the provider handles backups and failover. A proprietary serverless database with its own query language is a different proposition, and may still be the right call if it removes an entire class of problem.

The five portability choices that cost nothing

These five choices cost nothing extra at the point you make them, and each one shortens a future exit by weeks. That combination is rare enough to be worth acting on.

1. Keep your infrastructure definition in code, in a tool that targets more than one provider. You will still rewrite the resource definitions, but the structure, review process and naming survive.
2. Choose open database engines where the workload allows it. PostgreSQL and MySQL are available as managed services on every major provider, so the schema and the application code move even when the service does not.
3. Containerise the application tier. A container image that runs on one provider’s container service runs on another’s with configuration changes rather than code changes.
4. Keep an independent copy of your data. Not a second live region: a restorable export in an open format, somewhere the provider does not control. This also happens to be the backup you want during an outage.
5. Write the runbook as you build. Every time you add a stateful service, add a line to the exit plan describing how its data would come out. Two minutes each time beats a week of archaeology later.

Nothing on that list says avoid managed services. The expensive mistake is the opposite one: running your own database, your own queue and your own identity system on virtual machines to stay portable, then spending more on operations than the managed services would have cost. Our guide to service models sets out where that line usually falls.

Writing an exit plan in one page

An exit plan that fits on one page gets read, updated and used. One that runs to forty pages gets filed. Ours has six sections, and we write it in the same session as the architecture review.

Review it once a year, and after any significant architectural change. If you are planning a move right now rather than preparing for a hypothetical one, our piece on choosing a migration path covers the strategies and what each costs to execute, and the provider comparison is the right place to weigh up where you would go.

Eudora Technology writes and reviews these plans remotely for clients worldwide, usually alongside a broader architecture review, and we are happy to say when the honest answer is that your current lock-in is fine. The cloud solutions page covers how we work, and the introduction to cloud technology is the primer behind all of this.

If you need an exit plan for an auditor, an insurer or your own peace of mind, we can write one with you in a single session and tell you honestly which risks are worth money. Get in touch with Eudora Technology to talk about your project.