Cloud Exit Readiness Before 2027: EU Data Act & Portability

Cloud Exit Readiness Before 2027: What the EU Data Act Changes and What Your Architecture Still Has to Solve

From 12 January 2027, cloud switching gets cheaper in the EU. Leaving may still be the hard part.

Article 29 of the EU Data Act says providers of data processing services may no longer impose switching charges on customers from that date. That removes one commercial barrier. It does not remove provider-specific databases, IAM rules, managed queues, serverless dependencies, undocumented integrations or an infrastructure setup nobody has rebuilt outside the current account.

The useful question for 2027 is not “Can our provider export the data?” It is “Could we run the product somewhere else without turning the exit into a rebuild?”

What the EU Data Act actually changes for cloud switching

The EU Data Act has applied since 12 September 2025. Chapter VI covers switching between data processing services, including cloud and edge services.

The most visible deadline is 12 January 2027. From then, providers may not charge customers switching fees for the switching process. Until that date, reduced switching charges can still apply, but they cannot exceed costs directly linked to the switch.

The regulation also reaches beyond price.

For infrastructure services, providers must take reasonable measures to support functional equivalence after a move to another service of the same type. For other data processing services, Article 30 requires open interfaces to support switching. European Commission guidance also points to export of data in commonly used, machine-readable formats for PaaS and SaaS services.

There is a less comfortable sentence in the regulation that matters just as much: providers may need to explain when switching is highly complex, costly or impossible without significant interference with data, digital assets or service architecture.

That is where engineering begins.

The legal right to leave and the technical ability to leave are two different things. A contract can remove exit fees. It cannot untangle a product whose business logic, data model and operations are deeply coupled to one provider.

The 2026 European standardisation work programme also names workload portability, APIs, identity and access management, switching procedures and test suites among the areas that need common approaches.

What cloud exit readiness means in practice

Cloud exit readiness is the ability to move an application, its data and its operating model to another environment without disproportionate redevelopment, uncontrolled downtime or loss of critical behaviour.

A company can have excellent cloud infrastructure and still be poorly prepared to leave it.

We usually see the real risk in six areas.

1. Data exports cleanly, but the data layer does not

A database dump can be portable while the production data behaviour is not.

The application may depend on provider-specific replication, extensions, managed search, backup policies, event triggers, access controls or recovery tooling. Exporting rows is only one part of the move.

The better test is whether the destination can reproduce the behaviour the product depends on: consistency, indexing, permissions, recovery, audit history, retention and performance under real load.

If the answer is unclear, the data exit plan is incomplete.

2. Managed services have leaked into core business logic

Provider-native services are useful. Avoiding them everywhere usually creates unnecessary work.

The problem starts when dozens of business modules call proprietary queues, serverless runtimes, workflow engines, storage events or native databases directly. At that point, replacing the cloud service means changing the product.

A healthier architecture makes those dependencies explicit. Some can stay because the business value justifies the lock-in. Others should sit behind interfaces the team controls.

That decision is more useful than trying to make every component “cloud agnostic.”

3. Identity is coupled more deeply than expected

Authentication is usually easy to see. Authorization is where migrations get unpleasant.

Years of service accounts, workload identities, secret stores, KMS policies, role mappings and one-off exceptions can create a hidden dependency graph. Another cloud may offer equivalent concepts without identical behaviour.

A serious exit assessment maps machine identities alongside user identities.

One forgotten service account can turn a technically successful migration into a production outage.

4. Infrastructure-as-code reproduces the current cloud, not necessarily another one

Terraform, Pulumi and similar tools are valuable because they make infrastructure reproducible. Reproducible does not automatically mean portable.

If the code describes hundreds of provider-specific resources, it gives you a precise map of the current dependency graph. That is useful. It is still not an exit plan.

For portability, we separate infrastructure into three groups:

• reusable patterns that can move with limited change;
• provider-specific services with a known replacement path;
• components that need redesign because there is no clean equivalent.

That classification tells you where migration effort will actually go.

5. Observability gets treated as an afterthought

Logs, traces, metrics, alerts, dashboards and incident workflows are part of the production system.

A team can move compute and data successfully and still lose the visibility it needs to operate the product safely. During a cloud move, that is the worst possible time to fly blind.

Monitoring rules, trace context, log retention, dashboards and runbooks should be treated as migration assets, not housekeeping.

6. Nobody has tested an exit

This is the simplest signal.

If the team has never rebuilt the environment from automation, restored production-like data, recreated secrets, reconnected dependencies and run critical workflows in a clean environment, portability is still an assumption.

A slide deck called “cloud exit plan” does not prove the product can exit.

A production-like exit test does.

Run a cloud exit test before you need one

A useful cloud exit exercise is narrower than a full migration project. The goal is to find the expensive surprises while there is still time to choose what to fix.

A practical sequence looks like this:

• Map the real dependency graph: databases, storage, queues, APIs, IAM, secrets, jobs, observability, CI/CD, external integrations and manual operational steps.
• Classify provider-specific dependencies. Keep the ones that earn their complexity. Isolate or replace the ones that create risk without enough value.
• Define the data exit path. Document formats, volumes, transfer windows, retention rules, validation steps and how the destination will prove nothing material was lost.
• Recreate the environment from automation. If the second environment needs archaeology, the first one is not portable yet.
• Reconnect integrations. External systems, callbacks, certificates, IP allowlists, message brokers and scheduled jobs often fail after the “main” application has moved.
• Test identity and permissions. Verify machine accounts, secrets, keys, role mappings and operational access.
• Move observability with the workload. Rebuild dashboards, alerts, logs and traces before the cutover test.
• Run a realistic workload and rollback. A migration path should prove both directions: that the product can move and that the team can recover when validation or performance fails.

This gives leaders something more useful than a generic “multi-cloud strategy.” It shows what can move now, what needs selective engineering work, and what should stay provider-native because the trade-off is sensible.

Where Allmatics fits

At Allmatics, we work with established products where the hard part is rarely writing a new service from scratch. The harder work is changing one layer without breaking the business logic around it.

Our Cloud Solutions work covers cloud migration, infrastructure management and hybrid cloud architecture. Across Product Enhancements and Tech Consulting, we also handle legacy code optimisation, third-party integrations, API work and architecture changes around existing systems.

That combination matters for cloud exit readiness because the problem usually crosses several boundaries at once. Infrastructure can be portable while application code is not. Data can export while integrations fail. Containers can move while identity and observability remain tied to one provider.

A useful assessment has to look across all of them.

One Allmatics platform case shows the architecture principle clearly. In a long-running retail SaaS product, the client’s POS systems were staying in place. We built a connector architecture that exposed transaction data to a central platform instead of forcing the source systems to be replaced. The platform used .NET, AngularJS, Google Cloud and Kubernetes and was designed for multi-tenant operation.

That project was not a cloud-exit exercise, and we do not use it as proof that the platform could move providers unchanged. The relevant lesson is more specific: when the boundary between systems is explicit, one layer can evolve without forcing a rewrite of everything around it.

We have used the same approach in other products by introducing separate services around an existing platform and connecting them through APIs. Good exit architecture often starts with the same discipline: fewer hidden dependencies, cleaner boundaries and a smaller blast radius when infrastructure changes.

A 10-question cloud exit readiness check

Before commissioning a migration, ask these ten questions:

1. Can we recreate the production environment from documented automation?
2. Can we export all business-critical data and metadata in a usable format?
3. Which provider-native services are called directly from business logic?
4. Can we reproduce identities, permissions, secrets and key-management behaviour elsewhere?
5. What breaks if the current provider’s database, queue, storage or serverless service disappears?
6. Are APIs and integrations documented well enough to reconnect them?
7. Can our observability stack follow the workload?
8. Have we restored and tested the product in a clean environment?
9. What is the rollback path if data validation, latency or performance fails?
10. Which components need redesign, and which only need a cleaner boundary?

If several answers are “we think so,” you do not have an exit capability yet. You have an assumption.

What an Allmatics cloud exit readiness assessment can deliver

For teams reviewing cloud risk before 2027, we can turn that uncertainty into a concrete engineering map.

A focused assessment can produce:

• an application and infrastructure dependency map;
• an inventory of provider-specific services and lock-in points;
• a data export, transfer and validation plan;
• an IAM, secrets and key-management dependency map;
• a list of integration changes required at the destination;
• target architecture options;
• selective refactoring recommendations;
• business continuity and rollback requirements;
• a realistic view of what can move as-is, what needs isolation and what genuinely needs redesign.

That is a useful starting point whether the business plans to switch providers, build a hybrid setup, reduce concentration risk or simply negotiate from a stronger position.

From January 2027, EU rules remove one category of switching cost. Engineering teams still control the part that usually determines whether an exit is routine or painful.

If you want to know how portable your current application really is, start by testing the exit while you still have the choice.