Why IaaS, PaaS, and SaaS Do Not Exit the Same Way

This chapter compares the EU Data Act's technical duties by service model. The key question is whether the source provider must help recreate minimum functionality, or must instead expose interfaces and export paths that let the customer and destination provider do the reconstruction. That distinction gives a team the right acceptance test: an infrastructure workload needs one kind of evidence, while a managed platform or application needs another.

IaaS: functional equivalence without a destination rebuild

The Regulation gives the clearest functional-equivalence obligation to a particular kind of Infrastructure as a Service, or IaaS. Article 30(1) addresses a provider whose service supplies scalable and elastic computing resources limited to infrastructure elements such as servers, networks, and the virtual resources needed to operate that infrastructure. The service does not also provide access to the operating services, software, and applications stored, processed, or deployed on those elements.

That description marks a boundary between the infrastructure and what the customer runs on it. In an infrastructure-only arrangement, the customer may control much of the operating system, application, and data-processing stack. The source provider supplies the underlying computing environment, but the customer is not buying a complete managed application as part of that service. The precise classification still depends on the offering's actual characteristics; “IaaS” in a product name is not enough.

For this infrastructure-only model, the Regulation defines functional equivalence as re-establishing a minimum level of functionality in the destination service of the same service type. The destination must deliver a materially comparable outcome in response to the same input for the shared features that the source contract supplied. Three phrases carry the practical weight.

“Minimum level” means the obligation is not a promise to reproduce every feature, optimization, or provider-specific advantage. “Materially comparable outcome” means the customer needs a meaningful result, not merely a successful transfer of bits. “Shared features” limits the comparison to capabilities offered by both services and supplied under the contract. A source provider cannot be expected to make a destination perform a feature it does not offer, and a customer cannot use a feature unique to the source as the universal measure of equivalence.

A good test therefore begins with the workload's important inputs and outcomes. Suppose an order-processing application runs on customer-managed virtual resources. The team might select representative order events, recovery scenarios, and expected processing results. It would compare the destination's ability to produce those outcomes for the shared functions, while also checking the minimum functionality needed to keep the business operating. It would not declare equivalence merely because the virtual resources were created or because a storage volume has the same nominal size.

The source provider's duty is to facilitate that result through all reasonable measures within its power. Article 30(1) names capabilities, adequate information, documentation, technical support, and, where appropriate, tools. That can make the source environment legible enough for the customer to reproduce the workload. It does not make the source provider the owner of the customer's target architecture, and it does not require a new service category to be built on a competitor's infrastructure.

This distinction follows from the structure of a switch. The source provider can describe and expose the environment it controls. It cannot see the destination provider's implementation or decide how the destination will allocate its resources.