Cloud lock-in: why the Data Act makes exit planning practical

Cloud lock-in used to be treated as a technical annoyance: egress fees, proprietary APIs, data that is hard to export, and infrastructure that only works properly with one provider. Under the EU Data Act, the topic is no longer just architecture philosophy. It is becoming part of operational compliance.

For small businesses, agencies, and SaaS teams, the key question is not: “Do we need to migrate everything tomorrow?” The better question is: Could we explain clearly how we would switch if a customer, a risk, or a provider issue forced us to?

What the Data Act changes around cloud switching

The Data Act has generally applied since 12 September 2025. Among other things, it includes rules for data processing services, which covers cloud and hosting-adjacent services. Providers are expected to remove obstacles that prevent customers from switching to another provider, moving to on-premises infrastructure, or using several providers at the same time.

The practical detail is switching cost. Until 12 January 2027, providers may still charge reduced switching charges under certain conditions. From 12 January 2027, providers should no longer impose switching charges on customers for the switching process. This does not remove ordinary service fees, but it makes data export and migration-related fees much less acceptable from a regulatory and policy perspective.

For website operators, this may sound like “Big Cloud”. In practice, even small projects sit in this chain: hosting, databases, object storage, email delivery, analytics, authentication, AI APIs, backups, and monitoring.

Why dev teams should care now

An exit plan is not an 80-page novel wearing compliance perfume. It is a technical safety line. When a provider raises prices, a service fails, privacy requirements increase, or a customer demands a different infrastructure setup, the existing architecture decides whether the move becomes one sprint — or a season finale with a burning server room.

Typical lock-in points include:

• Databases: proprietary features, unclear export paths, missing migration strategy.
• Files and media: object storage without a clean path structure, no lifecycle rules, no tested exports.
• Serverless and edge functions: tightly coupled provider runtimes, secrets, and deployment flows.
• Authentication and user accounts: user IDs, sessions, roles, and MFA are often difficult to move.
• Analytics and logs: personal or security-relevant data is scattered across tools.
• AI integrations: prompts, model names, regions, logging behavior, and provider terms change quickly.

Teams that only start thinking about this when a migration is already necessary pay twice: technically and organisationally.

The pragmatic exit plan

For small teams, a compact project document is enough, for example docs/vendor-exit-plan.md. It should contain verifiable facts, not hopeful vibes:

1. Critical providers: Which services are required for operations, payments, communication, analytics, or AI features?
2. Data categories: Which personal data, customer data, files, logs, and configurations live where?
3. Export path: Are there API, SQL, CSV, JSON, or backup exports? Have they been tested?
4. Restore path: Can the export actually be restored in another environment?
5. Code dependencies: Are provider SDKs wrapped in internal adapters or scattered across the app?
6. Contracts and DPAs: Where are processor terms, regions, subprocessors, and termination periods documented?
7. Costs and deadlines: Which fees, notice periods, and retention windows currently apply?

This is not luxury. It is the technical version of “where are the keys if the house is on fire?”

Architecture: small decisions, large impact

A project does not need to be fully cloud-agnostic. For many small teams, that would be too expensive and too slow. But some decisions make later switching much less painful:

• Put provider SDKs behind small internal adapters.
• Keep data models in your own types instead of passing provider objects everywhere.
• Do not only create backups — test restoring them.
• Document secrets, domains, DNS, and webhooks.
• Treat logs with deletion and access rules.
• Note at least one realistic alternative for critical services.

For websites and smaller SaaS projects, a clean separation between product logic and provider integration is often enough. Nobody has to cosplay multi-cloud. But nobody should tie their business model to one button in someone else’s dashboard.

Privacy: export does not automatically mean allowed

Portability and switchability do not solve every privacy issue. If personal data is exported or transferred to a new provider, GDPR questions remain: legal basis, processor terms, transparency, access controls, deletion, and data minimisation.

Logs, support data, and AI prompts are especially sensitive. They often look technical, but may contain names, email addresses, contract details, health data, payment information, or internal customer notes. An exit plan should therefore ask not only “can we export this?”, but also: what are we allowed to export, who may see it, and when must it be deleted?

Conclusion

The Data Act makes cloud switchability more visible and more relevant. At the same time, the EU is paying closer political attention to cloud and AI markets, competition, and digital sovereignty. For small software teams, this is not a reason to panic. It is a clear task: provider dependencies need to be visible.

A good exit plan is short, technical, and honest. It shows where data lives, how it can be exported, which providers are critical, and which parts of the architecture would hurt during a migration. That protects against lock-in, improves privacy documentation, and makes projects easier to maintain.

Or less dry: when you know the exit, you are not trapped. And software that is not trapped sleeps better at night.

Sources

• Regulation (EU) 2023/2854, Data Act
• Reuters: EU rules reining in Big Tech will now target cloud services and AI, regulators say
• Reuters: EU Commission awards 180 million euro cloud contract to four European providers

Note: This article is a technical overview and does not constitute legal advice.