EU Data Act Switching API: What SaaS Developers Must Build by January 2027

Post #814 in the sota.io EU Compliance Series

On January 12, 2027, the EU Data Act's complete ban on cloud switching charges enters into force. That deadline is 8 months away. Most SaaS developers have heard the headline — but few have translated it into a technical build plan.

Chapter VI of the EU Data Act (Articles 23–31) is not just about pricing. It mandates specific technical capabilities: portable data export APIs, machine-readable formats, 30-day minimum transition assistance, and contractual switching rights that override any "lock-in" terms in your ToS. If your SaaS product stores customer data and charges for migration, you need to act now.

This guide translates the legal obligations into concrete engineering tasks: what endpoints to build, which formats to use, what the 30-day transition obligation actually requires, and why EU-native infrastructure is the architecturally aligned choice.

The Data Act Chapter VI Timeline

Before the technical requirements, the key dates:

The three-year period (entry into force Jan 11, 2024 → Jan 12, 2027) gives providers time to build portability infrastructure. That window is now closing.

Who Is In Scope

Article 23 defines "switching" as the process by which a user moves from one cloud service provider to another, or moves to on-premise infrastructure. The Chapter VI obligations apply to:

Cloud Service Providers (CSPs) — Infrastructure-as-a-Service, Platform-as-a-Service, Software-as-a-Service providers operating in the EU market. If you offer any of:

• Application hosting (PaaS)
• Data storage (object storage, managed databases)
• Software services where user data is stored and processed

...then Chapter VI applies to you.

The SaaS grey zone — Pure SaaS applications are in scope when they provide "cloud services" as defined by Art. 2(29): "a digital service that enables on-demand network access to a scalable and elastic pool of shareable computing resources." Most B2B SaaS products meet this definition if they store customer-specific data and provide API access.

What is excluded — Consumer contracts (B2C) have some carve-outs under Art. 23(3). The full switching charge prohibition of Art. 29 primarily targets professional/business cloud services. However, Art. 4–6 data access rights (discussed in our Data by Design guide) still apply to connected products and related services in consumer contexts.

Article 25: The Technical Switching Obligation

Article 25 is the core implementation requirement. The full obligation under Art. 25(1):

"Cloud service providers shall take all reasonable measures to remove commercial, technical, contractual and organisational obstacles that prevent cloud service customers from switching to a different cloud service provider."

"All reasonable measures" is intentionally broad, but Recital 95 and the implementing acts under Art. 25(5) clarify what this means technically:

1. Documented data formats — You must publish the data formats used to store customer data. Machine-readable schema documentation (JSON Schema, OpenAPI, or equivalent) satisfies this. Undocumented binary formats or proprietary schemas are problematic.

2. Export API availability — The export mechanism must be accessible via a programmatic interface. A manual "contact support to request your data" process does not satisfy the obligation. An authenticated REST endpoint that triggers a bulk export meets it.

3. Standard formats where available — Art. 25(2) specifies that export must use "commonly used open formats" where such formats exist for the data type in question. For structured data: CSV, JSON, NDJSON. For documents: PDF, standard XML. For media: standard container formats (MP4, FLAC, etc.).

4. No format lock-in — Art. 25(3) prohibits requiring customers to use a proprietary intermediary tool to perform the export. The API must be directly accessible.

Article 26: Technical Aspects of Switching — What to Build

Article 26 mandates that cloud service providers maintain technical interoperability capabilities. Article 26(1) requires:

"Cloud service providers shall provide and maintain technical interfaces and documentation to enable the switching process to be performed in a streamlined manner."

In practice, this translates to the following technical requirements:

Required API Endpoints

1. Data Inventory Endpoint

Before a customer can switch, they need to know what data exists. You must provide an endpoint that lists all data categories held for a given account, with format metadata:

GET /api/portability/inventory
Authorization: Bearer {token}

Response:
{
  "account_id": "acct_...",
  "data_categories": [
    {
      "category": "user_records",
      "description": "All user accounts and profile data",
      "record_count": 1240,
      "estimated_export_size_mb": 12,
      "available_formats": ["json", "csv"],
      "schema_url": "https://docs.example.com/schemas/users.json"
    },
    {
      "category": "transaction_history",
      "description": "All transaction records since account creation",
      "record_count": 84200,
      "estimated_export_size_mb": 340,
      "available_formats": ["json", "csv", "ndjson"],
      "schema_url": "https://docs.example.com/schemas/transactions.json"
    }
  ],
  "total_estimated_size_mb": 352,
  "export_sla_hours": 24
}

2. Export Request Endpoint

An authenticated endpoint to trigger a full data export:

POST /api/portability/export
Authorization: Bearer {token}
Content-Type: application/json

{
  "format": "json",
  "categories": ["user_records", "transaction_history"],
  "notification_email": "admin@customer.com"
}

Response 202 Accepted:
{
  "export_id": "exp_...",
  "status": "queued",
  "estimated_completion": "2027-01-15T10:00:00Z",
  "status_url": "/api/portability/export/exp_.../status"
}

3. Export Status Endpoint

GET /api/portability/export/{export_id}/status
Authorization: Bearer {token}

Response:
{
  "export_id": "exp_...",
  "status": "complete",
  "created_at": "2027-01-14T09:00:00Z",
  "completed_at": "2027-01-14T10:23:00Z",
  "download_url": "https://exports.example.com/exp_.../data.zip",
  "download_expires_at": "2027-01-21T10:23:00Z",
  "checksum_sha256": "abc123..."
}

4. Schema Documentation Endpoint (or static URL)

Machine-readable schema documentation for each data category. JSON Schema Draft-07 or OpenAPI 3.x is appropriate:

GET /api/portability/schemas/{category}
Authorization: Bearer {token}

Response:
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://api.example.com/portability/schemas/user_records",
  "title": "User Record Export Schema",
  "description": "Schema for user account records exported under EU Data Act Art. 25",
  "type": "array",
  "items": {
    "type": "object",
    "required": ["id", "email", "created_at"],
    "properties": {
      "id": { "type": "string", "description": "Internal user identifier" },
      "email": { "type": "string", "format": "email" },
      "created_at": { "type": "string", "format": "date-time" },
      "metadata": { "type": "object", "additionalProperties": true }
    }
  }
}

Article 29: The Switching Charges Ban

Article 29 establishes the phased elimination of switching charges:

Art. 29(1) — From September 12, 2026: switching charges must not exceed the actual cost of providing the migration assistance. You cannot profit from helping customers leave.

Art. 29(2) — From January 12, 2027: switching charges are completely prohibited. Zero. No "migration fee," no "export fee," no "data portability fee." Any charge triggered by a customer's decision to switch is unlawful.

What counts as a "switching charge"? The Recitals are clear: any fee that is specifically triggered by the switching process — including:

• Per-GB export fees
• API call charges that exceed standard rates when used for bulk export
• "Account termination" fees tied to data retrieval
• Premium support fees required to perform a switch

What is NOT prohibited:

• Your normal subscription charges during the 30-day transition period (covered below)
• Standard API usage fees for day-to-day operations (not switching-specific)
• Fees for genuinely optional add-on services during migration (clearly labelled and not required for the switch itself)

The practical implication: build your export infrastructure now so that you are not in a position where you have to charge customers for it. A bulk export that hits your database with 500,000 records should be handled asynchronously (async job queue + download link) rather than synchronously billed per-query.

Article 27: The 30-Day Transition Period

Article 27 establishes a minimum transition obligation that is independent of the switching charges question. Under Art. 27(1):

"Cloud service providers shall provide a minimum transition period of 30 days to their customers during which equivalent service functionality is maintained."

This means:

1. You cannot terminate service immediately upon notice of switching. If a customer notifies you that they are switching, you must maintain full service functionality for at least 30 days from that notice.

2. The export must remain accessible during this period. If the export takes 24 hours to generate and the customer initiates it on day 28, the download must still be available after day 30.

3. You cannot degrade service during the transition. Throttling API rate limits, removing features, or restricting data access during the transition period violates Art. 27.

4. Data retention post-transition — Art. 27(3) requires that data remains retrievable by the customer for a period to be specified in the contract, but not less than 30 days after the transition period ends. In practice, this means data must be available for at least 60 days from notification of switch.

Implementation Pattern: Transition State Machine

Customer notifies switch
       ↓
   [TRANSITION_INITIATED]
   - Full service continues
   - Export job queued
   - Timer: 30 days
       ↓
   [EXPORT_AVAILABLE]
   - Download link active
   - Service still fully operational
       ↓
   [TRANSITION_COMPLETE] (day 30+)
   - Service may be terminated
   - Data retained in read-only mode for ≥30 additional days
       ↓
   [DATA_PURGE_ELIGIBLE]
   - GDPR Art. 17 erasure can proceed
   - Notify customer before final deletion

Article 28: Functional Equivalence and Documentation

Article 28 requires that when a customer switches, the receiving provider has enough information to reconstruct a "functionally equivalent service." This is primarily a documentation obligation on the exporting provider:

Data model documentation — Not just schema, but semantic documentation: what does status: "pending" mean in your transaction table? What are the valid state transitions? A JSON Schema file is necessary but insufficient; you need accompanying human-readable documentation.

Configuration exports — For PaaS providers specifically: environment variables, feature flags, and configuration that is not in the data export itself must also be exportable. A customer moving their application from one PaaS to another must be able to reconstruct their runtime configuration.

Integration mapping — If your service integrates with third-party services on behalf of the customer (e.g., you manage OAuth tokens for their connected apps), the export must include enough information to reconstruct those integrations — even if this means documenting integration IDs that the customer will need to reconfigure with the third-party.

Contractual Obligations: What You Must Update in Your ToS

Art. 25(4) explicitly prohibits contractual terms that restrict switching rights. If your Terms of Service contain any of the following, they are unenforceable from September 12, 2025:

• Clauses prohibiting export of data to a competing service
• Restrictions on reverse-engineering your export format for migration purposes
• Non-compete clauses that prevent customers from using a competing service while still subscribed to yours
• Confidentiality clauses that cover data format documentation (customers have a right to this)

Practical ToS changes to make now:

1. Add an explicit section: "Data Portability" that describes your export API and references this regulation
2. Remove any "data migration prohibited" or "export restrictions" clauses
3. Add the 30-day transition commitment as a contractual right (making it enforceable both ways)
4. Specify the data retention period post-switch (minimum 30 days per Art. 27(3))

The GDPR Intersection: Export, Retention, and Erasure

The Data Act switching obligations intersect with GDPR in two places:

GDPR Art. 20 (data portability) — Already establishes a right for individuals to receive their personal data in a structured, machine-readable format. The Data Act extends this to non-personal data and makes it technically actionable at the API level. If your portability API satisfies Data Act Art. 25-26, it likely satisfies GDPR Art. 20 simultaneously — building once satisfies both.

GDPR Art. 17 (erasure) — After the transition period, you are under GDPR Art. 17 obligations to delete personal data when no longer needed. The Data Act transition period creates a temporary hold: you must retain data for at least 60 days post-notification. After that window, GDPR Art. 17 applies and you should delete rather than retain indefinitely.

The tension: a customer asks you to switch and delete all their data immediately. You cannot delete immediately (Art. 27 requires 30 days + 30-day post-switch retention). You can delete after 60 days. Design your data lifecycle to handle this state explicitly.

Implementing NDJSON for Large Exports

For large-scale exports (millions of records), NDJSON (Newline Delimited JSON) is the most practical format. It is:

• Streamable — can be processed line-by-line without loading the entire file into memory
• Schema-compatible — each line is a valid JSON object conforming to your schema
• Compression-efficient — NDJSON + gzip achieves better compression than equivalent nested JSON
• Commonly used — satisfies Art. 25(2)'s "commonly used open format" requirement

Example export structure for a 2GB dataset:

users.ndjson.gz        (all user records, one per line)
transactions.ndjson.gz (all transactions, one per line)
settings.json          (account configuration, small enough for single JSON)
integrations.json      (third-party integration mapping)
schemas/               (directory with JSON Schema files)
  users.json
  transactions.json
manifest.json          (export metadata: generated_at, record counts, checksums)

The manifest.json is critical for the receiving provider: it gives them the export structure without having to scan all files first, and provides checksums for integrity verification.

How EU-Native Infrastructure Aligns With These Obligations

The Data Act switching obligations create a paradox for US-based cloud providers: they are legally required to facilitate their customers leaving, while commercially incentivised to maintain lock-in.

For AWS, Azure, and GCP, "switching" from one of their PaaS products to an EU-native alternative requires:

1. Exporting from their proprietary format
2. Crossing jurisdictions (the data may be leaving the US parent's infrastructure)
3. Paying for egress bandwidth — which while no longer permitted as a "switching charge" after Jan 2027, still has infrastructure cost implications

For EU-native providers like sota.io, the alignment is structural:

• No US parent — switching from sota.io does not involve a transatlantic jurisdiction change
• Standard buildpacks — Nixpacks/Heroku buildpack-compatible deployments are portable by design; a customer leaving sota.io takes their Dockerfile or Procfile with them
• Managed PostgreSQL exports — PostgreSQL's native pg_dump format is the archetypal "commonly used open format" for database exports; no proprietary schema translation required
• No egress fees — removing the hidden cost that makes "free switching" expensive in practice with hyperscalers

The Data Act's switching architecture is, in effect, a regulatory mandate to build what EU-native, open-standard-oriented platforms were already building. CLOUD Act exposure aside, the switching obligations create a structural advantage for providers whose product design aligns with portability rather than fighting it.

The January 2027 Build Plan

Working backward from January 12, 2027:

By July 2026 (6 months out):

• Complete data inventory endpoint (what data categories exist, sizes, formats)
• Implement async export job infrastructure (queue + async processing + download link)
• Publish JSON Schema documentation for all major data categories
• Review ToS for prohibited lock-in clauses; update as needed

By October 2026 (3 months out):

• Complete export endpoints for all data categories
• Implement transition period state machine (30+30 day retention logic)
• Implement GDPR Art. 17 integration (data deletion after transition window)
• Internal testing: export 100% of a test account and verify import into reference competitor environment
• Publish portability documentation page (required under Art. 26)

By December 2026 (1 month out):

• Load test export API with production-scale data volumes
• Confirm no switching-adjacent charges exist in billing system
• Customer communication: notify existing customers of portability rights
• Final legal review of ToS switching rights section

January 12, 2027:

• All switching charges prohibited
• Portability infrastructure in production
• Documentation published

Enforcement Outlook

The Data Act is enforced at the national level under Art. 37, with competent authorities designated in each member state. Germany (Bundesnetzagentur), France (ARCEP), and the Netherlands (ACM) have been most active in digital market regulation enforcement.

Art. 43 specifies penalties: member states set their own, but they must be "effective, proportionate and dissuasive." Germany's digital market enforcement precedents suggest fines of 1–4% of annual turnover for systematic non-compliance with switching obligations.

The first enforcement wave for Chapter VI switching obligations is unlikely before Q2 2027 — authorities need time to process complaints after the January deadline passes. But the complaint period starts January 12, 2027. Any customer who attempts to switch after that date and encounters either switching charges or inadequate export tooling can file a complaint immediately.

Further Reading

• EU Data Act September 2026: Data by Design Obligations for SaaS Developers
• EU Data Act B2B Data Sharing and Smart Contracts
• CRA Art. 11: Vulnerability Handling, SBOM, and Responsible Disclosure
• GDPR Art. 20 Data Portability: Developer Implementation Guide