EU Data Act Functional Equivalence FAQ

Under the Data Act, functional equivalence means re-establishing a minimum level of functionality after a customer switches to a new data processing service of the same service type. The comparison is based on the customer's exportable data and digital assets, and it looks at whether the destination service delivers a materially comparable outcome for the same input and for shared contractual features.

The definition does not promise identical performance, identical configuration, or a full replica of the old environment. Teams should frame functional equivalence as a switching outcome to support, not as a warranty that every workload, integration, latency profile, or provider-specific feature will carry across unchanged.

Article 30(1) applies the functional-equivalence duty to providers whose service is limited to scalable and elastic infrastructural resources such as servers, networks, and the virtual resources needed to operate them, without access to the operating services, software, and applications deployed on that infrastructure. The Commission FAQ describes this as IaaS.

PaaS and SaaS providers remain covered by Chapter VI when they meet the definition of a data processing service, but Article 30 gives them different duties. They must make open interfaces available to customers and destination providers. Compatibility with a referenced harmonised standard or common specification becomes mandatory at least 12 months after the reference is published in the central Union repository. Until a relevant reference is published, Article 30(5) requires a structured, commonly used, machine-readable export for a same-service-type switch at the customer's request.

For an in-scope IaaS switch, the customer should be supported toward using a destination service of the same service type with materially comparable outcomes for the same input and for shared contractual features. The Data Act does not say the source provider must make the destination service identical, rebuild the workload for the customer, or control the destination provider's environment.

A useful switching plan therefore states the target outcome in operational terms: which workloads, configurations, data categories, access rights, security settings, machine images, containers, or other digital assets will be exported or documented; which destination features are shared; and which differences remain outside the source provider's control.

For IaaS functional equivalence, the source provider must take reasonable measures within its power. Article 30 describes the support as capabilities, adequate information, documentation, technical support, and, where appropriate, necessary tools.

The provider's switching contract and public information should also tell customers how switching and porting work, which methods and formats are available, what restrictions or technical limitations are known, and where to find the provider's register of data structures, formats, standards, and open interoperability specifications for exportable data.

The contract may set a notice period of no more than two months, followed by a maximum transition period of 30 calendar days and at least 30 calendar days for retrieval. If 30 days is technically infeasible, the provider must notify and justify that conclusion within 14 working days of the request and may specify an alternative transition period of no more than seven months. The customer may extend the transition once for a period it considers more appropriate.

The switching file should distinguish exportable data from digital assets and from material that the Data Act does not require the provider to disclose or transfer. Exportable data covers input and output data, including metadata generated or co-generated by the customer's use of the service, but excludes provider or third-party intellectual property and trade secrets.

Digital assets are broader practical enablers for using the customer's data in a new environment. The Commission FAQ gives examples such as configuration settings, security and access-control metadata, applications, virtual machines, and containers where the customer has an independent right to use them.

For PaaS and SaaS, the Data Act requires providers to make open interfaces available free of charge, to an equal extent, to all customers and the concerned destination providers. It also requires sufficient information for software-to-software communication. Compatibility duties depend on publication of the relevant harmonised standard or common specification in the central Union repository and the 12-month period in Article 30(3). Where no relevant reference has been published, Article 30(5) supplies the machine-readable export rule for same-service-type switching.

For IaaS, interoperability standards and open specifications can also help customers reach functional equivalence, but they do not turn the source provider into the operator of the destination environment. The standardisation route should be tracked as a dependency because the Data Act ties some compatibility duties to publication in the central Union standards repository.

Functional-equivalence wording should not imply unlimited responsibility. The Data Act limits the source provider's technical obligations to the services, contracts, and commercial practices it provides. It also says providers are not required to develop new technologies or services, disclose or transfer protected intellectual property or trade secrets, or compromise security and service integrity.

The customer-facing explanation should also separate included switching assistance from optional additional services. A customer may request additional support beyond the provider's Data Act switching obligations, but that should be described and priced as an additional service agreed in advance rather than hidden inside the mandatory switching process.

For functional equivalence, the Data Act record should identify the source clause, Commission guidance, actor role, dataset, request or contract trigger, and the owner who approved the interpretation.

Keep the cited external URL, decision date, reviewer, unresolved assumptions, and implementation artifact together so the answer remains auditable.

For functional equivalence, the Data Act workflow should name the legal, product, procurement, cloud, support, or security owner who can change the affected process.

For functional equivalence, use one accountable owner per action, then record consulted teams and evidence dependencies separately.

The functional-equivalence duty centres on IaaS, where the source provider must take reasonable measures so the customer can re-establish a minimum level of functionality on a same-type destination service. PaaS and SaaS providers do not owe that outcome. They must provide the open interfaces required by Article 30(2), meet the compatibility duty after the Article 30(3) trigger, and provide the Article 30(5) export when no relevant repository reference has been published.

Teams should classify the service before promising an outcome, because expecting functional equivalence from a SaaS provider, or accepting only a raw export from an IaaS provider, both misread the Regulation.

Under the Data Act, the source provider must offer reasonable assistance, exercise due care to maintain business continuity, provide capabilities and information to support the switch, and keep a high level of security during transfer and retrieval. The duty is about enabling the customer to reach a comparable outcome, not rebuilding the destination environment.

The measures should be scoped to the provider's own service and contractual features, with any work beyond that treated as a separately agreed additional service rather than part of the mandatory switching support.

Under the Data Act, a source provider is not required to develop new technologies or services, disclose or transfer protected intellectual property or third-party trade secrets, or compromise the security and integrity of its service to deliver functional equivalence. These are genuine limits rather than excuses to avoid the switching duty.

A defensible decline points to one of those specific limits for the requested step, while still delivering the export, assistance, and continuity measures the Regulation requires for everything else.