EU Data Act: Planning Your Exit from a Document Platform

Regulatory information checked: November 6, 2026. The evidence model below is implementation guidance; legal duties depend on the service, role and use case.

Document platform portability is often reduced to a single question: can we download our files? That question is necessary and insufficient. A usable document system also contains metadata, stable identifiers, versions, permissions, relationships, retention state, workflow history, and integration contracts.

The EU Data Act has applied since September 12, 2025. Chapter VI addresses switching between data-processing services. Its scope is the service offered, not every software licence; assess a customer-operated installation separately from a managed service. SaaS/PaaS interface and export duties differ from IaaS functional-equivalence duties. The European Commission's Data Act guidance also notes that switching charges, including switching-related data egress, are removed from January 12, 2027. This does not make every migration, destination service or optional implementation task free.

For buyers, this is a reason to make exit design part of architecture and procurement now. The cheapest time to define a reliable export is before the first migration, not during a contract dispute or accelerated replacement project.

Files are the visible part of the system

Suppose an organization exports five million files with their original names. It may still be unable to reconstruct:

• which version was approved or published;
• which contract, claim, employee, or case each document belonged to;
• which users were allowed to see it;
• whether a legal hold or retention rule applied;
• who uploaded, changed, reviewed, or deleted it;
• which downstream systems referenced its identifier;
• whether OCR text or extracted attributes were authoritative, derived, or manually corrected.

The files are present, but the information system is gone.

Define a portable document package

A practical export specification should identify the authoritative and derived elements separately. The table is our recommended migration package, not a claim that the Act requires every item in every service. Identify exportable customer data and metadata, provider IP/trade-secret exclusions, and which destination behaviours need rebuilding. Check the actual service contract and applicable exceptions.

• Layer

  Binary objects

  Portable content

  Original files, renditions, signatures, and generated documents.

  Validation

  Counts, sizes, checksums, and missing-object report.

• Layer

  Identity

  Portable content

  Stable document IDs, source IDs, paths, and external references.

  Validation

  Uniqueness and referential-integrity checks.

• Layer

  Metadata

  Portable content

  Attributes, schemas, classifications, dates, and provenance.

  Validation

  Schema validation and value reconciliation.

• Layer

  Lifecycle

  Portable content

  Versions, status, retention, holds, deletion state, and disposition events.

  Validation

  Business-rule and chronology checks.

• Layer

  Relationships

  Portable content

  Links to entities, dossiers, cases, contracts, and related documents.

  Validation

  Orphan and broken-link report.

• Layer

  Authorization

  Portable content

  Roles, groups, policy inputs, and access classifications.

  Validation

  Sampled access-equivalence testing.

• Layer

  History

  Portable content

  Audit events, reviews, approvals, and workflow outcomes.

  Validation

  Sequence, actor, timestamp, and completeness checks.

• Layer

  Derived data

  Portable content

  OCR text, embeddings, thumbnails, and search fields.

  Validation

  Decision to migrate or reproducibly rebuild.

Open APIs help, but they do not define an exit

An API can make every object retrievable and still leave the customer with an impractical migration. Rate limits, pagination behavior, export ordering, dependency discovery, and audit access all affect whether a complete export can finish within the available window.

A tested exit plan should document:

• the bulk-export method and expected throughput;
• how a consistent cutoff point is established while the source remains active;
• how changes after the initial export are captured;
• which data is available through standard APIs and which requires a service request;
• how identity and permission mappings will be translated;
• how completeness is reconciled and exceptions are reported;
• when source data, backups, and derived indexes will be deleted after acceptance.

Integration contracts are part of portability

Line-of-business applications often store a document ID, URL, or repository-specific path. During a switch, those references can become the hardest dependency. A portable design uses stable business identifiers and an integration layer that can resolve them to the current document platform.

Events also need translation. A customer may rely on “document approved,” “contract signed,” or “vendor certificate expired” events. Exporting the documents without documenting those event schemas leaves connected systems unable to reproduce the workflow.

FormKiQ Integration Frameworks treat metadata mappings, lifecycle synchronization, event contracts, and external identifiers as explicit integration assets. That makes the connection maintainable during normal operations and easier to replace during an exit.

Test portability with a partial migration

Contract language is important, but a test provides stronger evidence. Select a representative collection and export it into an independent environment. Include large files, multiple versions, restricted records, legal holds, complex metadata, and connected business objects.

Measure:

• time to export and import;
• percentage of records transferred without manual correction;
• metadata and relationship exceptions;
• permission differences;
• search and retrieval equivalence;
• business workflows that require redesign;
• supplier assistance and charges required.

Repeat the test after material schema, workflow, or integration changes. Portability can decay as the platform becomes more customized.

Ownership changes the default

FormKiQ can be deployed into the customer's AWS account, with documents in customer-controlled S3 buckets and metadata in customer-controlled DynamoDB tables. That model gives the customer direct access to the underlying data and infrastructure.

Direct ownership does not eliminate migration work. A new platform still needs mappings for metadata, permissions, versions, workflows, and relationships. It does, however, remove a major dependency: the customer does not need the vendor to release the primary storage before an exit can begin.

The Data Act raises the baseline for switching. Buyers can go further by designing document portability as a continuing technical capability, with explicit schemas, stable identifiers, open interfaces, and a tested migration package.

Exit rehearsal: export one contract dossier

Illustrative design exercise, not a reported incident or measured FormKiQ result.

1. Step 1

   Signed file, prior versions and manifest of hashes

   Independent destination check

   Counts and hashes match; signed bytes remain unchanged

   Who resolves a failure

   Source operator and migration owner.

2. Step 2

   Contract ID, metadata, vendor relationship and approval history

   Independent destination check

   Destination can find the dossier from its business ID and explain which version was approved

   Who resolves a failure

   Application and data owners.

3. Step 3

   Access policy inputs, retention and legal hold

   Independent destination check

   Translated rules pass allowed/denied access tests; holds remain enforceable

   Who resolves a failure

   Security and records owners.

4. Step 4

   ERP references and post-cutoff changes

   Independent destination check

   Links resolve after cutover; reconciliation finds no missing updates

   Who resolves a failure

   Integration owner before migration acceptance.