DMA and cloud providers: how Big Tech regulation may affect cloud platform selection in Europe

Choosing a cloud platform in Europe is increasingly about more than just price, SLAs, regions, and the range of managed services. Another criterion is now being added: how well the company manages its dependence on the provider and whether it will be able to switch platforms in a few years without disproportionate costs.

The DMA and the Data Act do not force businesses to urgently move away from major cloud platforms. But they do change the context: they increase scrutiny of Big Tech’s market power, exit terms, data portability, migration costs, and contract transparency. For customers, this can become an additional argument in negotiations with a provider and a reason to assess architectural dependencies in advance.

The main limitation remains technical. Even if regulation reduces some external barriers, it does not eliminate hyperscaler lock-in: dependence on APIs, managed databases, serverless functions, IAM, network services, monitoring, licenses, discounts, and the team’s skills. Data can be exported, but that does not mean the application will quickly run on another platform.

In practical terms, this means three things:

• Consider not only the cost of moving into the cloud, but also the cost of moving out;
• Separately assess the portability of data, applications, and operational processes;
• Treat European, local, and alternative providers not as automatic replacements for hyperscalers, but as part of a broader strategy.

First, it is important to distinguish between two regulatory layers: the DMA is more closely related to the market power of the largest digital platforms, while the Data Act focuses on data portability and the terms for switching cloud providers. If these topics are conflated, it is easy either to overestimate the impact of regulation or to miss real opportunities to reduce dependence on a single platform.

DMA and the Data Act: Two Distinct Regulatory Layers Around Cloud Services

The DMA and the Data Act are often seen as a single European push against Big Tech, but for cloud strategy they are different instruments. The DMA addresses the market power of the largest digital platforms, while the Data Act deals with the practical conditions for data portability and switching cloud or edge providers.

The DMA is usually associated with marketplaces, search, app stores, and messaging services, but cloud infrastructure has also come under scrutiny. On November 18, 2025, the European Commission opened three investigations into cloud services under the DMA: two into the possible gatekeeper status of AWS and Microsoft Azure, and another into whether the current DMA obligations are adequate for the cloud market. At this stage, these are not sanctions or findings of infringement, but an assessment of whether the rules apply.

The Data Act works differently. For cloud services, it is more about contracts and migration: data portability, open interfaces, interoperability, and functional equivalence of services. Its practical value for customers is in understanding how they can leave their current platform, retrieve their data, and reduce switching barriers.

In short:

The key difference is this: the DMA helps assess a provider’s market power, while the Data Act focuses on the terms for exiting a platform. In contract negotiations, this translates into specific questions: how data is exported, within what timeframes, in which formats, how much data egress costs, which interfaces are documented, and what counts as a successful migration.

However, neither regime replaces architectural preparation on its own. If an application depends heavily on managed services, access permissions, monitoring, and specific APIs, legal guarantees can make an exit easier, but they will not make it automatic. That is why the next step is to examine what hyperscaler lock-in consists of in practice.

Hyperscaler lock-in: what the dependency is made of

Even when regulation makes data migration easier and reduces some exit costs, moving off a major cloud platform remains an engineering project. Dependency is created not only by the contract, but also by how the system is built: which APIs the application uses, where the data resides, and how access, monitoring, backups, and team processes are configured.

Broadly speaking, lock-in consists of several layers:

• Data and traffic. Volume, format, transfer speed, outbound traffic costs, and the risk of downtime during export are important.
  
• Platform services. Managed databases, queues, serverless functions, events, storage, and analytics often have APIs, settings, limits, and log formats that differ from vendor to vendor.
  
• Control plane. IAM roles, access policies, keys, auditing, network rules, DNS, load balancers, monitoring, and alerts are rarely transferred as a ready-made model.
  
• Commercial and operational dependency. Licenses, discounts, spending commitments, team skills, runbooks, and processes are typically tailored to the current platform.

A practical example is a managed database. Tables can be exported, but application behavior may depend on specific storage types, replication settings, built-in backups, access rights, monitoring, and performance. On paper, the data is portable; in practice, the SLA, latency, fault tolerance, and operational procedures all need to be validated again.

In an enterprise environment, the dependency can be even broader. For example, a company may use a combination of a cloud platform, enterprise identity, office services, licenses, analytics, and volume discounts. That does not make such an architecture wrong: it can provide speed, maturity, and predictable support. But when choosing a platform, it is important to understand the cost of reversing course.

Regulation can reduce external barriers: make exit terms more transparent, lower some fees, and strengthen the customer’s negotiating position. But the main question remains technical: whether it is possible to move not just the data, but a functioning system with all its integrations, permissions, observability, and operating model.

Service compatibility: data portability is not the same as application portability

If the dependency extends beyond the data itself, compatibility must be assessed at multiple levels. Exporting a database, files, or logs in a readable format is only the first step. The application must then run in another environment with the expected permissions, latency, events, limits, and failure scenarios.

In cloud environments, there are three levels of portability:

• Data — whether they can be exported in a human-readable and machine-readable format;
• Interfaces — whether the service can be accessed through open or compatible APIs;
• Application behavior — whether the system will operate with the same expectations for access, latency, failures, events, and monitoring.

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure



Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans



Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus



Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster

The Data Act can improve the first two levels by making formats and interfaces more transparent and reducing lock-in during migration. However, comparable functionality does not mean identical behavior. A provider may offer a service in a similar category, but its limits, permission model, backup settings, event handling, metrics, and failure responses will differ.

One example is S3-compatible object storage. A compatible API lowers the barrier: the application is easier to reconfigure, and some data upload and read tools may continue to work. However, this does not guarantee identical access policies, operation speeds, request limits, event integrations, behavior during a regional outage, or monitoring quality.

The same logic applies to Kubernetes. Containers improve compute portability, but they do not automatically carry over networking, databases, IAM, secrets, observability, or operational procedures.

Therefore, when choosing a cloud platform in Europe, it is not enough to ask whether the data can be retrieved and whether a “compatible” service exists. You need to verify how the application will behave on another platform in real-world scenarios: under load, during a failure, during recovery, when access permissions change, and when integrations are switched over.

Compatibility reduces some technical barriers, but an actual migration between providers is still a project with a budget, timeline, tests, and risks.

Migration and Multicloud: What May Become Easier and What Will Remain a Project

Compatibility reduces some of the technical barriers, but it does not turn a platform change into a simple switch. After checking formats, APIs, and application behavior, a more practical question arises: how much it costs not to “migrate in theory,” but to actually leave.

Lower egress fees can significantly change the exit economics for companies with large data sets. If a SaaS or fintech company stores terabytes of data, cheaper data export lowers the financial barrier. But the engineering project does not disappear.

Migration still has three layers:

• Data — export, integrity verification, migration of archives, logs, backups, and recovery after a failure;
  
• Applications — reconfiguration of databases, queues, access permissions, network routes, dependencies, and load testing;
  
• Operating model — new on-call procedures, monitoring, security, support, SLA, and team skills.

Changing providers and using a multicloud strategy are different approaches. Changing providers answers the question, “How do we leave the current platform?” Multicloud answers a different question: “How do we operate several platforms at the same time?”

A multicloud architecture can reduce dependence on a single provider, but it also increases the complexity of networking, access management, monitoring, security, and support. In practice, the team is maintaining not one environment, but several different operational domains.

The contractual layer also remains important. Spend commitments, volume discounts, bundled offerings, export timelines, data formats, and exit assistance can either accelerate or slow down a migration. Regulation helps make some terms more transparent and reduce certain barriers, but it does not replace calculating the cost of exit in advance.

This leads to a practical step: not simply deciding whether to leave or stay, but determining which workloads should reside where — with a major provider, a European provider, a niche service, or in a multicloud model.

Provider Selection Strategy in Europe

Regulation does not automatically make a European or alternative provider the better choice. It changes the evaluation framework itself: a company must compare not only functionality and the cost of entry, but also how manageable the dependency is, migration conditions, data jurisdiction, and the actual compatibility of services.

Major cloud platform: when scale and service maturity matter

Large cloud platforms remain a rational choice when a company needs a broad range of managed services, a global network of regions, and mature tools for security, analytics, machine learning, databases, and support.

For a fast-growing SaaS company, a fintech business, or an international corporate group, this may be the right strategic bet. However, in this scenario it is important to limit critical dependencies in advance: separate data from platform-specific logic, use standard formats, document an exit plan, and avoid making long-term spending commitments without assessing migration risk.

European and alternative providers: where they offer an advantage

A European provider may be the stronger choice when the priorities are hosting data in the EU, a clear jurisdiction, local support, customer requirements for digital sovereignty, or working with regulated sectors.

This choice may be appropriate for storage, backups, dedicated personal data processing environments, national projects, and services where legal predictability matters more than the broadest possible range of managed features. However, a European provider still needs to be evaluated against engineering criteria: fault tolerance, security, observability, support, API compatibility, and the ability to assist with migration.

An alternative or niche provider is a good fit when the workload is well defined: object storage, compute without a complex platform layer, a backup site, a separate analytics environment, edge infrastructure, or a service with a predictable load profile. This approach can reduce dependence on a single major provider and offer better pricing for a specific class of resources, but it typically provides fewer managed services and integrations.

Multi-cloud: When Reducing Dependency Justifies the Complexity

Multi-cloud is not always justified. It makes sense when a company has a mature engineering team, consistent security practices, automated deployment, independent monitoring, and a clear understanding of which workloads are placed in different clouds and why.

If multiple providers are chosen only as “insurance,” without a budget for operations, a multi-cloud architecture can increase risk. Instead of reducing dependency, the company ends up with several different IAM models, network perimeters, monitoring systems, support procedures, and skill sets.

In practice, the strategy usually is not to choose a single provider forever, but to classify workloads. Critical applications that rely heavily on managed services can remain with a major provider, but with an exit plan. Data, archives, and backups should be designed so they can be exported in standard formats. Workloads subject to European jurisdiction requirements can be hosted with a provider that has data centers and contractual guarantees in the EU. Isolated services can be moved to alternative providers if doing so does not compromise security or support.

For new procurements, it is useful to evaluate not only pricing and the SLA, but also compatibility, exit terms, outbound traffic costs, and the transfer of logs, backups, configurations, and metadata.

Conclusion

The DMA and the Data Act add a new criterion to choosing a cloud provider in Europe: how effectively a company manages its dependence on the platform. This is not about automatically moving away from major providers or treating a European provider as a universal replacement, but about taking a more mature approach to selection.

A company should understand in advance which dependencies it is taking on, where portability is required, which exit terms should be included in the contract, and which parts of the architecture must remain portable. Commercial barriers may be lowered, but migrating a live system is still an engineering project. For this reason, a cloud strategy should account not only for entering a platform, but also for a controlled exit from it.

FAQ

Do European companies need to move away from AWS, Azure, or Google Cloud immediately?

No. The DMA and the Data Act do not require customers to leave major cloud platforms. They do, however, provide a reason to review their architecture, contracts, and exit plan.

Does the Data Act make cloud-to-cloud migration easy?

No. The Data Act may reduce costs and improve the conditions for data portability, but it does not automatically migrate applications, access rights, networks, monitoring, or operational processes.

Why is the DMA important for the cloud market?

The DMA is important as a tool for curbing the market power of major digital platforms. For cloud customers, this may affect the transparency of terms, service interoperability, and their negotiating position.

Is a European provider the best alternative to a major cloud provider?

Not always. A European provider may be stronger in terms of data residency, local compliance, and jurisdiction, but it still needs to be evaluated for resilience, support, and integrations.

What should be included in an RFP or contract with a cloud provider?

Data export formats, migration timelines, data egress costs, exit assistance, documented interfaces, termination terms, spend commitments, and the procedure for transferring logs, backups, and settings.

Does multicloud reduce dependency on a single provider?

Yes, but at the cost of greater complexity. Multiple clouds require separate management of networking, security, observability, access permissions, support, and team expertise.

Sources

1. European Commission — “Commission launches market investigations on cloud computing services under the Digital Markets Act”

2. European Commission — “Data Act explained”

3. UK Competition and Markets Authority — “Cloud services market investigation: Final decision report”