concept

Functional Equivalence

also called Switching Equivalence, Same-Service-Type Equivalence

The standard that a destination service must deliver the same output at the same performance and security after a switch, which is defined only between services of the same type and therefore does not rescue a proprietary managed service.

eu-data-actcloud-exitportabilityvendor-lock-inconcentration-risk

An exit plan says the workload can move to another provider. The question a supervisor asks is what "move" means: the same features, the same latency, the same security posture, or merely the data in a tarball. The EU Data Act (Regulation (EU) 2023/2854) gives that question a defined answer for cloud switching.

Functional equivalence, as the regulation defines it, is the maintenance of a minimum level of functionality in the new service's environment such that, in response to the same input on core elements of the service, the destination delivers the same output at the same performance and with the same level of security, operational resilience and quality of service as the originating service at termination.

Two qualifiers do most of the work. The comparison is between services of the same service type, and the obligation to enable functional equivalence sits on providers of infrastructure services rather than on every managed product. A proprietary workflow engine or a vendor-specific database has no same-type destination, so nothing in the regulation conjures one.

Why it matters

It reframes what an exit plan is measuring. Before, teams priced exit as an egress bill and a document. The Data Act has applied since 12 September 2025 and switching charges must be withdrawn entirely from 12 January 2027, so the money barrier disappears. What replaces it is a clock: a notice period of at most two months, then a mandatory maximum transitional period of 30 calendar days, with an extension to at most seven months only where the provider justifies technical unfeasibility within 14 working days.

30 days is not a migration project; it is the window in which a rehearsed migration executes. Functional equivalence is the acceptance criterion for that rehearsal, which makes it an engineering specification rather than a legal phrase.

Implementation patterns

  • A three-way dependency classification: commodity infrastructure; open-protocol managed service with a self-hostable or multi-vendor equivalent such as Postgres, Kafka, an S3-compatible store or Kubernetes; and proprietary with no equivalent. Only the third class costs anything to leave, and the estate's exit cost is the sum of that class.
  • Equivalence tests written as assertions, not prose: the same request returns the same response, p99 within an agreed multiple of the original, the same authentication and encryption posture, the same recovery time objective.
  • A rehearsal cadence on the single most critical service. The first restore into the alternative takes a week; the third takes days. Record the date and the measured recovery time, because that is the claim a supervisor can test.
  • Escrow of the things that are not data: infrastructure definitions, pipeline configuration, identity mappings and the runbook. Data portability without these produces a working database nobody can serve from.

Industry example

Financial institutions in the EU already maintained exit plans under sector outsourcing rules, and supervisors had been unimpressed by document-only plans for years. The Data Act's switching timetable makes the gap measurable rather than rhetorical: a firm can now be asked when it last executed the plan and whether the result met functional equivalence, and the answer is either a date and a number or an admission.

Failure scenarios

  • State in a proprietary service. The plan assumes portability the regulation does not provide, and the discovery happens during the 30-day window.
  • Equivalence tested on the happy path only, so the destination serves reads correctly and fails on the batch reconciliation nobody exercised.
  • Performance equivalence ignored. The workload runs on the new provider at three times the latency, which is a breach of the standard and of the firm's own service levels.
  • The plan is current and the infrastructure is not. The document describes an architecture two years old because nothing forces it to be re-derived.

Trade-offs

Designing for equivalence costs you the best features of your provider. An abstraction over two clouds pays a tax on every release, in reduced capability and in the code that hides the difference. The counter-argument is narrow and real: the tax is worth paying only for the components whose loss would stop a critical service, and for everything else a rehearsed rebuild is cheaper than a permanent abstraction.

The second trade is where you spend the rehearsal budget. One genuine restore a year on the most critical service beats a complete paper plan for the whole estate, and costs about a week of a small team's time.

When not to use it

Do not build for functional equivalence outside its jurisdiction and outside its risk class. A firm with no supervisory exit requirement, or a non-critical workload, should not carry dual-provider abstractions for their own sake. The proportionate posture for a non-critical service is a rehearsed data export and a documented rebuild, not a warm second provider. And where the obligation does apply, scope it: equivalence is required for the critical service, not for the internal wiki.

Interview question

Q: Your regulator asks for evidence that you can switch cloud providers within the statutory window. Your core ledger runs on a provider-specific managed database. Walk me through what you tell them and what you change.

What a strong answer covers: the honest statement that no same-type destination exists, so equivalence is not achievable for that component as built; a plan to move the ledger's state to an open-protocol engine with a measured cutover; interim compensating evidence in the form of a tested restore into a self-hosted instance with the recovery time recorded; and a refusal to claim a 30-day switch that has never been run.

Quick check

Quiz: Why does removing switching charges make cloud exit harder for some firms rather than easier? Because the barrier was never the egress bill; removing it exposes the timetable, and a 30-day transitional period is unreachable for a plan that has never been executed.

Flashcard: Which class of dependency does functional equivalence not help with? Proprietary managed services with no same-type destination, since the standard compares services of the same type and the obligation falls on infrastructure providers.