EU Data Act Cloud Switching 2026: Complete Developer Compliance Toolkit

Post #1420 in the sota.io EU Cloud Compliance Series

The EU Data Act cloud switching obligations (Art.23–28 of Regulation (EU) 2023/2854) became applicable on 12 September 2025. If your SaaS or cloud platform processes data for customers in the EU and enables those customers to move away — or prevents them from doing so — you are in scope.

This is the final post in our five-part EU-DATA-ACT-CLOUD-SWITCHING-2026 series. The first post covered the switching request API and state machine. The second post covered data format standards. The third post covered the Art.27 anti-obstacle requirements. The fourth post covered transition assistance and parallel operations. This finale assembles everything into a compliance toolkit: a complete checklist, an enforcement map, a risk matrix, and a reference architecture.

Who Is in Scope

The EU Data Act distinguishes between operators of data processing services (cloud providers, SaaS platforms, managed service providers) and their customers (businesses or individuals using those services). The switching obligations in Art.23–28 apply to operators whenever:

1. The service qualifies as a "data processing service" — a broad category covering cloud infrastructure (IaaS/PaaS/SaaS), edge computing, and hybrid deployments where the provider processes data on behalf of the customer.
2. The customer is established or resident in the EU or the data relates to activities in the EU.
3. The customer wishes to switch to a different operator or to in-house infrastructure.

Consumer-only B2C services without any B2B component are mostly out of scope for the switching obligations. But if your platform serves business customers — including SMBs — you are almost certainly in scope.

The Complete Art.23–28 Developer Checklist

Art.23 — Switching Rights and Request Handling

Art.23 establishes the customer's right to switch and the operator's obligation to support it. The core requirements:

• No maximum notice period above 30 calendar days — you cannot require more than 30 days notice before initiating a switch.
• No minimum subscription term that functions as a switching barrier — if a 12-month lock-in effectively prevents switching during that period, that is a prohibited obstacle under Art.27.
• No financial penalty for early switching — exit fees not covered by Art.26 are prohibited.
• Documented switching process — you must publish how customers initiate a switch and what timelines they can expect.

Developer checklist for Art.23:

[ ] API endpoint or UI flow for switching request exists and is documented
[ ] Notice period required from customer: ≤30 calendar days
[ ] No penalty fee charged for switching request initiation
[ ] Switching process documented in product docs / ToS / support pages
[ ] Switching request acknowledged in writing (email or in-app) within 5 business days
[ ] Timeline for data export completion communicated to customer

Art.24 — Switching Assistance Obligations

Art.24 places active support duties on the outgoing operator. Switching is not just about handing over a zip file — you must support continuity during the transition period.

Key obligations:

1. Configuration and metadata export — not just raw data, but the operational metadata needed to replicate the customer's setup: environment variables, network configurations, IAM policies, integration settings.
2. Technical documentation — sufficient to allow the incoming provider or the customer's technical team to reproduce the workload.
3. Reasonable query handling — you must respond to technical questions from the switching customer within a reasonable timeframe during the transition period.
4. No service degradation — the switching process must not result in reduced performance, availability, or functionality for the customer's live workload until the transition is complete.

Developer checklist for Art.24:

[ ] Configuration export includes: env vars, IAM policies, network config, integration endpoints
[ ] Metadata export includes: resource inventory, dependency map, API keys (non-secret format)
[ ] Technical documentation template generated per-customer on switching request
[ ] Support SLA during switching: ≤48h for technical queries (or your contractual SLA)
[ ] Transition window: no maintenance, no performance changes, no feature removals until switch complete
[ ] Parallel operations documented if customer requires dual-write during transition (see our fourth post)

Art.25 — Technical Constraints and Data Formats

Art.25 requires that data exports use open, interoperable formats where such formats exist for the data type in question. Proprietary-format-only exports are permissible only where no open standard exists, and even then you must provide sufficient documentation for the receiving provider to parse the format.

Practical requirements:

• Structured data (databases, configuration, logs): JSON, CSV, Parquet, NDJSON, or equivalent open formats.
• Object/blob storage: Standard S3-compatible API or direct file transfer with no proprietary compression.
• Application state: Standard serialization formats (JSON/YAML for configuration, standard SQL dumps for relational data).
• Programmatic access: A machine-readable API for bulk export, not just a UI download.

Developer checklist for Art.25:

[ ] Customer data exportable in at least one open format (JSON/CSV/NDJSON/Parquet)
[ ] Export API is documented and accessible programmatically
[ ] Proprietary formats: documented schema + parser reference provided
[ ] Export completeness: all customer data scopes are exportable (not just "main" data — also audit logs, metadata, configuration)
[ ] Export format tested against receiving provider's import API (at minimum: documented compatibility)

Art.26 — Switching Charges Phase-Down

Art.26 mandates a phase-down of switching charges to zero. The timeline:

"Direct costs" means only the actual operational expenses incurred in providing the switching service — storage bandwidth, export processing time, engineering support. You cannot include lost revenue, amortized infrastructure costs, or contractual penalties in the calculation.

Developer checklist for Art.26:

[ ] Switching charges documented and limited to direct costs (if charged pre-2027)
[ ] Cost calculation methodology documented internally (in case of NCA audit)
[ ] Free switching by September 2027: engineering and product roadmap item created
[ ] No hidden charges: switching-adjacent fees (e.g. "data egress for export") reviewed for compliance

Art.27 — Prohibition of Obstacles to Switching

Art.27 is the broadest prohibition — it catches any practice that deters, prevents, or delays a customer from switching, whether commercial, technical, or contractual. The Article explicitly covers:

• Commercial disincentives: termination fees, advance payment requirements for the remaining contract period.
• Technical obstacles: proprietary format lock-in, artificially throttled export APIs, deletion of data before the export is complete.
• Contractual restrictions: minimum notice periods exceeding 30 days, NDA clauses that prevent the customer from disclosing the destination provider, clauses requiring the customer to keep using the incumbent service during the transition.
• Service degradation: intentional or negligent reduction of service quality during or after a switching request.

Developer checklist for Art.27:

[ ] ToS reviewed: no clause requires >30-day notice for switching
[ ] ToS reviewed: no clause prohibits customer from disclosing destination provider
[ ] ToS reviewed: no financial penalty for switching beyond Art.26-compliant charges
[ ] Export API rate limits: not set below a level that would prevent timely export (e.g. not capped at 1 MB/h for a 1 TB customer)
[ ] Data retention during switching: customer data is NOT deleted until customer confirms export complete
[ ] No contractual requirement to continue using the service during or after the switching process
[ ] Legal review completed for standard ToS and DPA — obstacle-prohibition clause added to DPA

Art.28 — Equivalence of Functionality

Art.28 is the most forward-looking provision. It requires that, where technically feasible, operators facilitate functional equivalence for incoming customers — that is, you must not use proprietary API designs that make it impossible to replicate functionality from a competitor's platform.

This does not mean you must accept every competitor's data format. It means:

• Your APIs must be designed with interoperability in mind, not deliberately incompatible with open standards.
• If an open standard exists for the functionality (e.g. S3-compatible object storage, OpenID Connect for auth), you should implement it rather than a proprietary equivalent.
• Where a customer arrives from another platform and requests equivalence mapping, you must provide reasonable technical guidance.

Developer checklist for Art.28:

[ ] Core APIs align with open standards where standards exist (S3, OpenID, OAuth2, SCIM)
[ ] Proprietary APIs documented with migration guides from major competing platforms
[ ] Equivalence mapping table: competitor features ↔ your features (internal or customer-facing)
[ ] Feature-parity documentation maintained for common migration paths

NCA Enforcement Landscape by Member State

Each EU member state is required to designate a national competent authority (NCA) responsible for enforcing the EU Data Act. As of September 2025, the NCA landscape is taking shape — most states are assigning these responsibilities to existing digital market or telecom regulators.

Practical implication for cross-border SaaS: A complaint from a French customer triggers ARCEP, from a German customer triggers BNetzA. If your platform operates across multiple EU countries and receives a simultaneous complaint, you may face parallel investigations. Your compliance documentation must be available in English (minimum) and ideally the language of the main EU country you operate in.

NCA notification timelines: The EU Data Act does not define a mandatory breach-notification-style timeline for switching violations (unlike GDPR Art.33 or NIS2 Art.23). However, if an NCA opens an investigation, you will typically have 10–30 business days to provide documentation. Ensure your switching compliance records are audit-ready.

Risk Exposure Matrix

The EU Data Act (Art.40) requires member states to establish penalties that are "effective, proportionate and dissuasive." Fine amounts are set by member state law — the EU text does not harmonize maximum amounts the way GDPR does. Germany's draft implementation legislation (Datengesetz-Ausführungsgesetz) sets a framework; other member states are at varying stages of implementation.

Estimated enforcement risk profile by violation type:

Key insight: The highest enforcement risk in 2025–2026 is from customer complaints triggering NCA action on Art.23 and Art.27 violations. NCAs are not yet running proactive audits of cloud provider ToS at scale, but when a business customer makes a formal complaint about being prevented from switching, NCAs are obligated to investigate.

Reference Architecture: Compliant Cloud Switching System

A minimal EU Data Act-compliant switching implementation for a SaaS platform has six components:

1. Switching Request Handler

// POST /api/v1/switching-request
interface SwitchingRequest {
  customer_id: string;
  destination_provider?: string; // optional — customer may not disclose
  requested_format: 'json' | 'csv' | 'parquet' | 'sql';
  transition_window_days: number; // customer preference, max 30 for notice
  include_scopes: SwitchingScope[];
}

type SwitchingScope = 
  | 'application_data'      // primary business data
  | 'configuration'          // environment, settings, IAM
  | 'audit_logs'             // compliance records
  | 'metadata'               // resource inventory, tags
  | 'integration_configs';   // webhooks, API keys (sanitized)

2. Data Export Service

The export service must handle large datasets asynchronously without rate-limiting the customer to a pace below what is technically feasible.

interface ExportJob {
  id: string;
  customer_id: string;
  status: 'queued' | 'processing' | 'ready' | 'expired';
  format: string;
  scopes: SwitchingScope[];
  created_at: string;
  ready_at?: string;
  download_url?: string;
  // Expires 30 days after completion — customer data must remain accessible
  expires_at?: string;
}

3. Transition State Machine

The transition period begins when the customer initiates a switch and ends when the customer confirms export complete or 30 days elapse (whichever is shorter). During this window:

States: REQUESTED → EXPORT_READY → TRANSITION_ACTIVE → CUSTOMER_CONFIRMED → DEPROVISIONED
                                          ↕ (parallel operations if requested)
                                   QUERY_SUPPORT (at any point during TRANSITION_ACTIVE)

4. Configuration Documentation Generator

Auto-generate per-customer technical documentation at switching request:

async function generateSwitchingDoc(customerId: string): Promise<SwitchingDocument> {
  return {
    resource_inventory: await getResourceInventory(customerId),
    environment_manifest: await getEnvManifest(customerId),
    integration_map: await getIntegrationMap(customerId),
    iam_policies: await getIAMPolicies(customerId),
    network_topology: await getNetworkConfig(customerId),
    // Technical FAQ: common questions from switching customers for this tier/plan
    switching_faq: await getSwitchingFAQ(customerId),
  };
}

5. Compliance Audit Trail

Every switching event must be logged for NCA audit readiness:

CREATE TABLE switching_events (
  id UUID PRIMARY KEY,
  customer_id UUID NOT NULL,
  event_type TEXT NOT NULL, -- 'request', 'export_started', 'export_ready', 'doc_generated', 'transition_support', 'confirmed', 'deprovisioned'
  actor TEXT, -- 'customer' | 'system' | 'support_agent'
  metadata JSONB,
  created_at TIMESTAMPTZ DEFAULT now()
);

6. NCA Documentation Package

Pre-generate the documentation package you would submit to an NCA in an investigation:

• Compliance policy: your written EU Data Act switching compliance policy
• ToS review certificate: legal sign-off that ToS contains no prohibited obstacles
• Switching process SLA: documented notice periods, response times, transition windows
• Charge methodology: how you calculate direct costs for any switching charges
• Sample export artefacts: example output from each export scope in each supported format

Go-Live Readiness Checklist

Use this before declaring EU Data Act switching compliance:

LEGAL
[ ] ToS reviewed for Art.27 obstacles — prohibited clauses removed
[ ] DPA (Data Processing Agreement) updated with switching rights language
[ ] Privacy notice updated if switching-related processing is new
[ ] Art.26 charge schedule documented and disclosed

PRODUCT
[ ] Switching request flow implemented and accessible to all business customers
[ ] All export scopes available: application_data, configuration, audit_logs, metadata
[ ] Open format export available for primary data type
[ ] Export API rate limits reviewed — not artificially constrained
[ ] Service degradation prevention: no maintenance windows auto-scheduled during switching

ENGINEERING
[ ] Transition state machine implemented
[ ] Data retention during switching: customer data not deleted before confirmation
[ ] Switching event audit trail in place
[ ] Configuration documentation generator tested end-to-end

OPERATIONS
[ ] Support SLA for switching queries defined and communicated
[ ] NCA documentation package template ready
[ ] Internal runbook for NCA investigation response created
[ ] Free switching by Sept 2027: product roadmap item created and estimated

SEPTEMBER 2027 PREPARATION
[ ] Zero-charge switching path designed (no revenue impact modelled)
[ ] Switching cost absorption plan: where do operational costs go when charges drop to zero?
[ ] Automated switching pipeline: can you handle a spike of simultaneous switching requests with zero charge and zero marginal cost?

Series Summary

Over this five-post series, we built a complete picture of EU Data Act cloud switching compliance:

What SaaS Developers Should Do This Week

If you have not yet assessed your EU Data Act switching exposure:

1. Run the Art.27 checklist on your ToS — this is the highest enforcement risk in 2025/26.
2. Check your export API rate limits and data scopes — does curl /api/export actually return everything?
3. Book a legal review of your DPA for switching rights language.

If you are already partially compliant:

1. Close the Art.24 gap — do you generate per-customer technical documentation on switching request?
2. Start the September 2027 planning — free switching must be operational by then.
3. Build your NCA documentation package while your engineers still remember the switching implementation.

The EU Data Act switching obligations are not as complex as GDPR or as technically demanding as NIS2. But they are real obligations, they are in force, and they will generate enforcement actions as business customers exercise their new rights.

This post is the fifth and final entry in the sota.io EU-DATA-ACT-CLOUD-SWITCHING-2026 series. For EU cloud compliance infrastructure that is sovereign by design, see sota.io — EU-native managed PaaS, no CLOUD Act exposure.