The EU Data Act (Regulation 2023/2854) became fully applicable September 12, 2025. It mandates cloud switching procedures and eliminates vendor lock-in barriers. At the same time, the Digital Markets Act is investigating AWS and Microsoft Azure as potential gatekeepers, which would impose additional interoperability obligations.
If you’re running tech infrastructure at an SMB—50 to 500 employees, SaaS, FinTech, HealthTech, whatever—you’re dealing with compliance requirements. You need functional equivalence for IaaS migrations and open interfaces for PaaS and SaaS. Egress fee elimination happens by January 12, 2027.
Here’s the fundamental challenge: the US CLOUD Act‘s extraterritorial data access contradicts EU data sovereignty principles and GDPR Article 48 requirements. US cloud providers remain subject to American legal demands regardless of where your data sits.
This guide covers the technical implementation roadmap—switching procedures, proportionate charges, transitional period negotiations, contractual terms, and risk mitigation architectures. You need to avoid compliance penalties, enable customer switching rights, understand revenue recognition impacts, and navigate US-EU regulatory tensions. Let’s get into it. Understanding these requirements is essential for technology leaders navigating the European digital sovereignty movement.
What is the EU Data Act and when does it take effect?
The EU Data Act entered into force on January 11, 2024, and became fully applicable September 12, 2025. It establishes cloud switching and interoperability requirements for data processing services—IaaS, PaaS, SaaS—to reduce vendor lock-in effects.
There’s a timeline you need to track. Entry into force happened in January 2024. Full applicability hit September 2025. Egress fee elimination comes January 2027. These are three different dates with three different compliance checkpoints.
Data processing services are defined to include IaaS, PaaS, SaaS, Storage as a Service, and Database as a Service. Basically, if you’re providing cloud infrastructure or software, you’re covered.
The goal is eliminating lock-in effects. Technical requirements mean functional equivalence. Commercial requirements mean no egress fees. Contractual requirements mean notice periods. The European Commission enforces it through standard contractual clauses.
Companies are advised to consider implications for business models and contract design given the immediate September 2025 applicability. The European Commission was due to publish non-mandatory standard contractual clauses for data processing service contracts by September 12, 2025.
How does the Digital Markets Act define cloud gatekeeper obligations?
The Digital Markets Act designates large platforms as gatekeepers when they serve as important gateways between businesses and consumers with dominant market positions. On November 18, 2025, the European Commission initiated three separate market investigations concerning cloud computing services. AWS and Microsoft Azure are under investigation for potential gatekeeper designation.
If investigations confirm gatekeeper status, these cloud services would be added to existing core platform designations for both companies. Areas of examination include interoperability barriers between cloud services, data access restrictions for business users, service tying and bundling practices, and potentially imbalanced contract terms.
Gatekeeper obligations include interoperability requirements, data access provisions, bundling restrictions, and fair contract terms. This complements the Data Act by targeting market concentration and competitive barriers at the platform level.
Using potential gatekeepers means navigating regulatory requirements from both DMA and Data Act. Both target switching barriers, but DMA focuses on dominant platform behaviour while the Data Act provides universal switching rights.
What does functional equivalence mean under EU Data Act requirements?
Functional equivalence requires IaaS providers to ensure minimum functionality levels are maintained in new environments following cloud switching. Your workloads must operate with equivalent capabilities after migration without significant degradation in performance, features, or reliability. This applies specifically to Infrastructure as a Service under Data Act Article 29. These regulatory standards support the broader European digital sovereignty movement by establishing technical guardrails for platform migration.
The technical definition is minimum functionality preservation, not feature-for-feature parity. For IaaS, compute, storage, and networking must function equivalently post-migration. Both incumbent and receiving providers share responsibility for verification.
It’s different from data portability for PaaS and SaaS, which requires open interfaces and machine-readable formats instead.
Here’s the gap: there are no standardised testing protocols yet defined. You need contractual specification of methodology and acceptance criteria.
Any loss of functionality during migration, such as inability to use certain analytics features after export, must be transparently documented and objectively justified. Silent degradation is not acceptable.
Migration planning must include equivalence verification and parallel running for testing.
Why is the CLOUD Act creating conflicts with EU data sovereignty rules?
The US CLOUD Act from 2018 grants American authorities power to compel US-based service providers to provide access to data stored abroad. Regardless of data storage location globally. Even if that data belongs to non-US persons and resides in EU data centres. This directly contradicts GDPR Article 48, which requires international agreements for foreign authority data access. For a comprehensive analysis of how these CLOUD Act conflicts create broader geopolitical compliance tensions, see our detailed risk assessment.
All US cloud providers—AWS, Azure, Google Cloud—remain subject to the CLOUD Act even with EU data centre locations.
GDPR Article 48 states that court orders from third countries are only valid if based on international agreements such as Mutual Legal Assistance Treaties. The CLOUD Act bypasses MLATs altogether.
This creates an unavoidable compliance conflict. Meet US legal obligations or meet EU data protection requirements. You can’t do both.
As long as a cloud provider is headquartered in the US or controlled by a US parent company, it remains subject to the CLOUD Act regardless of where data is stored. Microsoft’s own chief legal officer in France admitted under oath before the French Senate that the company cannot guarantee EU data is safe from US access requests. That’s a problem.
The European Data Protection Board has made clear that service providers subject to EU law cannot legally base data transfers to the US solely on CLOUD Act requests. GDPR violations carry penalties up to €20 million or 4% of global annual revenue.
Risk mitigation strategies include customer-managed encryption, contractual safeguards, hybrid architectures, and EU provider alternatives. This drives demand for EU-owned cloud alternatives like Exoscale and Gaia-X initiatives.
What types of cloud services are covered by Data Act switching requirements?
Data Act Chapter VI applies to all data processing services including Infrastructure as a Service, Platform as a Service, Software as a Service, Storage as a Service, and Database as a Service.
The technical and pricing requirements vary significantly. For IaaS requirements, you’re looking at functional equivalence testing, workload migration support, and infrastructure parity. PaaS requirements include open interfaces with documentation, development platform portability, and API specifications. SaaS requirements mean structured machine-readable data export formats, complete data retrieval capabilities, and metadata inclusion.
Universal requirements applying to all types: egress fee elimination timeline, notice period maximums of two months, proportionate early termination fees, and transitional period provisions.
Cloud providers must ensure users can retrieve all digital assets including structured and unstructured data, metadata, and configurations in structured, machine-readable format.
What is the timeline for egress fee elimination under the Data Act?
Egress fees—data transfer charges for exporting data from cloud platforms—are permitted as “cost-covering charges” until January 12, 2027. They’re completely prohibited from January 12, 2027 onwards for all data processing services. For a detailed analysis of how egress fee elimination affects switching cost calculations and economic planning, see our ROI modelling guide.
Premium service fees for migration acceleration or data format conversion remain permissible as optional paid services. Providers must adjust pricing models before the 2027 deadline to maintain revenue without egress charges.
Currently, egress fees are a barrier to switching. Multi-thousand dollar charges for large data volumes are common. The regulatory timeline has the Data Act effective September 2025, but the egress fee ban is delayed until January 2027 for provider adjustment.
What’s prohibited: mandatory charges for data extraction and transfer during the switching process. What’s permitted: optional premium services like faster transfer speeds or format conversion assistance if the customer chooses.
SaaS companies must redesign revenue recognition. Cloud providers must find alternative monetisation. Compliance preparation means updating contracts by September 2025 with an egress fee phase-out plan and implementing new pricing by January 2027.
Between September 2025 and January 2027, egress fees must be “cost-covering” not punitive.
According to research, egress fees account for an average of 6% of organisations’ cloud storage costs. Cloud providers charge up to $0.09 USD per GB transferred out of storage. That adds up fast.
How do I implement functional equivalence for IaaS migrations?
Define minimum functionality requirements covering compute performance, storage capabilities, networking features, and availability levels required for workloads. Document testing methodology with measurable criteria before migration—benchmark performance, feature verification, reliability thresholds. Execute parallel running during transitional period (30 days to 7 months) to verify equivalent operation. Both incumbent and receiving providers must cooperate in good faith to facilitate testing and resolve compatibility issues. For detailed migration planning frameworks and vendor lock-in assessment methodologies, consult our strategic migration guide.
The transitional period enables parallel running for equivalence verification. This allows side-by-side comparison, gradual traffic shifting, and rollback capability if equivalence is not achieved.
Documentation requirements fall on both providers. The receiving provider must document capabilities, the incumbent must provide workload specifications, and both share test results. There’s no EU-mandated testing protocol yet, requiring contractual specification.
Challenges include proprietary service dependencies like AWS Lambda or Azure Functions, networking architecture differences, and monitoring tool migrations. Success criteria: workloads operate with comparable performance and reliability, no feature loss, and acceptable operational effort.
Interoperability is a mandatory regulatory obligation under the Data Act. If a customer moves from one cloud provider to another, the new provider must be able to ingest exported data without requiring extensive manual reformatting.
Many cloud applications are built using provider-specific APIs, proprietary services, or orchestration layers requiring rearchitecting components or introducing abstraction layers. That’s the technical debt you need to work through.
What steps are required to achieve Data Act compliance by September 2025?
Conduct compliance assessment determining which services fall under Data Act scope (IaaS, PaaS, SaaS) and current gap analysis. Revise contracts incorporating standard contractual clauses with mandatory terms: notice periods (max 2 months), transitional periods, switching charge disclosures, data portability specifications. Implement technical capabilities: functional equivalence support for IaaS, open interfaces for PaaS, machine-readable exports for SaaS. Update pricing models preparing for egress fee elimination roadmap towards January 2027 full prohibition.
Providers must disclose available switching procedures and technical limitations. Details of data structures and formats for exportable data are required.
Designated national supervisory bodies bear responsibility for enforcement with penalties including warnings, reprimands, orders for compliance, and fines. The European Commission maintains a publicly available register of penalties.
Ongoing obligations include maintaining switching capabilities, honouring notice periods and transitional periods, and conducting annual compliance reviews.
What are proportionate charges and how do they differ from switching fees?
Proportionate charges are reasonable, cost-based early termination fees permitted during contract periods under EU Data Act standards. They must reflect actual costs incurred by the provider—unused capacity, operational expenses—rather than punitive penalties for switching. Different from switching fees which cover migration process costs (data extraction, technical assistance) and are increasingly restricted. The regulatory language creates ambiguity requiring explicit contractual definition and good faith negotiation.
Proportionate charges apply to contract termination, while egress fees cover data transfer costs. The Data Act bans egress fees from January 2027. Proportionate charges cover early contract termination.
No guidance exists on what a proportionate early termination fee would be. Some providers insist full payments due for the remainder of a fixed term are the termination fee, just accelerated on switching. Customers may object that proportionality implies some reduction.
Significant uncertainty exists about how courts will interpret these provisions. For now it’s a matter for negotiation with companies filling in gaps left by vague drafting of legislation.
Contractual specification is necessary. Regulatory ambiguity requires an explicit formula or methodology in service agreements to prevent disputes. Negotiation considerations include customer size and contract value, notice period length reducing impact, and alternative commitment structures.
Compliance risk: excessive charges could be challenged as anti-competitive lock-in contrary to Data Act objectives. Best practices mean transparent disclosure of calculation methodology, good faith negotiation, and consideration of customer migration timeline.
A key concern for cloud providers is whether the switching right undermines ability to recognise revenue. US GAAP is particularly sensitive to customer termination rights. You’ll need to talk to your accountant about this.
How do I negotiate transitional periods for complex cloud migrations?
The Data Act provides 30 days standard transitional period for parallel running during cloud switching, extendable up to seven months for exceptional complexity. Transitional periods must be specified in contracts with clear technical and operational parameters defining parallel running scope. Negotiate based on workload complexity, data volumes, integration dependencies, testing requirements, and risk tolerance. Both incumbent and receiving providers must cooperate in good faith.
30 days is default for straightforward migrations. Up to 7 months for complex multi-service environments requiring extensive testing. Contractual specification requirements mean define parallel running capabilities, specify support obligations, document cutover procedures, and clarify cost allocation.
Factors justifying longer periods: large data volumes requiring gradual migration, complex integration dependencies, mission-critical workloads requiring extensive testing, multi-region deployments, and regulatory requirements in financial services or healthcare.
Parallel running scope includes read-only replication versus full bidirectional sync, production traffic percentage shifting, monitoring and alerting coverage, and rollback procedures.
Provider obligations during transition: the incumbent must maintain service levels and provide migration support, the receiving provider must demonstrate functional equivalence, and both must remove obstacles.
Cost considerations: who pays for parallel infrastructure, data transfer costs during transition, and premium services for acceleration.
Three periods are mandated: maximum notice period of two months, transitional period during which switching happens set at maximum 30 days unless customer or supplier wants it longer, and data retrieval period of minimum 30 days.
There’s an overriding obligation of good faith on both source and destination providers to make the switching process effective. There’s a general positive obligation on providers to remove technical barriers to switching. Not just “don’t obstruct”, but actively help.
FAQ Section
Does the EU Data Act apply to my SaaS company if we’re not based in the EU?
Yes. The Data Act applies to data processing service providers offering services to customers in the EU regardless of provider location. If you serve EU customers with IaaS, PaaS, or SaaS offerings, switching obligations apply. Consider EU market presence, customer contracts, and enforcement jurisdiction when assessing applicability.
What happens if I don’t comply with Data Act requirements by September 2025?
Non-compliance risks include contractual disputes with customers exercising switching rights, potential European Commission enforcement action, competitive disadvantage versus compliant providers, customer churn to alternatives offering easier switching, and reputational damage. France’s SREN Law includes fines up to 3% of annual global turnover, increased to 5% for certain repeat breaches. Germany’s draft implementation act permits fines up to 4% of annual global turnover or €5 million, whichever is higher. Early preparation is recommended given technical implementation complexity.
Can I still charge customers for premium migration assistance services?
Yes. While egress fees are banned from January 2027 and proportionate charges are restricted, optional premium services remain permissible. These include migration acceleration, data format conversion assistance, dedicated technical support, and consultation—as long as customers can choose the free standard switching process instead.
How do I choose between US hyperscalers and European cloud providers under Data Act?
Evaluate on multiple criteria: technical capabilities and feature maturity (hyperscalers typically stronger), CLOUD Act exposure and sovereignty concerns (EU providers have the advantage), switching ease and Data Act compliance posture, pricing including total cost with egress fees, and risk tolerance for US-EU regulatory conflicts. Microsoft 365 EU Data Boundary, Amazon’s European Sovereign Cloud, and Google’s Sovereign Controls provide illusion of control while remaining subject to US legal demands. Search activity shows European alternatives averaging 2,400 monthly searches with 660% year-over-year increase. Hybrid architectures can balance trade-offs.
What’s the difference between GDPR portability rights and Data Act switching requirements?
GDPR Article 20 provides limited portability for personal data in structured, machine-readable formats. Data Act Chapter VI is broader: covers all data types (not just personal data), includes functional equivalence for IaaS, mandates provider cooperation, eliminates egress fees, and specifies transitional periods. The Data Act significantly expands on the GDPR portability foundation.
Do I need to provide functional equivalence guarantees for PaaS and SaaS services?
No. Functional equivalence specifically applies to IaaS services under Data Act Article 29. PaaS services must provide open, cost-free interfaces with documentation. SaaS services must provide structured, machine-readable data exports with metadata. Requirements differ by service model—review relevant Article provisions for your service type.
How do I handle CLOUD Act conflicts in my EU compliance strategy?
Options include selecting EU-owned providers avoiding CLOUD Act jurisdiction entirely, implementing customer-managed encryption where the provider cannot access keys, using hybrid architectures with sensitive data on EU infrastructure, negotiating contractual protections and notification provisions, or accepting residual risk with hyperscaler capabilities. No perfect solution exists—balance technical and legal trade-offs.
What should be included in Data Act standard contractual clauses?
Mandatory terms include notice period specifications (max 2 months for termination), transitional period provisions (30 days to 7 months based on complexity), data portability formats and procedures, switching charge disclosures and calculation methodologies, functional equivalence commitments for IaaS, good faith cooperation obligations, and egress fee elimination roadmap to January 2027.
Can I negotiate longer notice periods if customers agree contractually?
No. Data Act Article 28 caps notice periods at “no more than two months” to prevent excessive contractual lock-in regardless of customer agreement. This is a mandatory maximum that cannot be extended through bilateral negotiation. Providers must adapt business models to this constraint rather than relying on long notice periods.
How will egress fee elimination affect my cloud service pricing model?
Providers must redesign revenue models by January 2027 to maintain profitability without egress charges. Options include increased base subscription prices incorporating data transfer costs, consumption-based pricing on compute and storage usage, premium tier structures, value-added service monetisation, and operational efficiency improvements. Some providers are dropping exit fees well in advance of the January 2027 date. Start transition planning now to smooth customer communication.
What documentation must I provide customers to support functional equivalence testing?
For IaaS services: detailed workload specifications including compute, storage, and networking requirements, current performance baselines and benchmarks, dependency mappings and integration points, monitoring and alerting configurations, and acceptance criteria defining equivalent functionality. Both incumbent and receiving providers share documentation obligations to enable verification.
Are there penalties for providers who create artificial switching barriers?
While the Data Act doesn’t specify penalty amounts directly, Article 28 requires “good faith cooperation” and prohibits obstacles to switching. Providers creating artificial barriers risk contractual breach claims, European Commission enforcement action, reputational damage affecting customer retention, and potential DMA gatekeeper sanctions if designated. Compliance requires genuine facilitation not technical obstruction.
