Technology

Technology

Cloud Portability and Data Ownership: Lessons from the EU Data Act

The EU Data Act turns cloud switching and connected-product data access into operational questions about export, dependencies, contracts, identity, and testing.

An export folio and manifest move between servers while a hand verifies the destination beside a separate identity control.
AI-generated editorial illustration for LedgerByte.

The EU Data Act, applicable since September 2025, gives SMEs a useful operational lesson even when a specific contract or business falls outside its scope: data access and cloud switching must be designed before an exit. Inventory business data and dependencies, classify what can be exported, document formats and interfaces, separate identity and encryption control, negotiate assistance and deletion, test restore or migration, and retain a fallback. Legal rights, technical portability, and business continuity are related but distinct; qualified counsel should determine how the Act applies to a particular provider, connected product, user, or contract.

What the EU Data Act changes

The European Commission describes the Data Act as creating rules for fair access to and use of data, including data generated by connected products and related services and provisions intended to make switching between data-processing services easier. It applies from 12 September 2025, with particular provisions and contractual contexts requiring careful reading. The Act is not a declaration that every person owns every piece of data or that every cloud workload can move without engineering.

For an SME, the durable lesson is to ask who can access which data, for what purpose, in what format, at what cost, with which trade-secret and privacy protections, and how a service is switched or terminated. These questions matter across the world because weak exit design creates operational concentration even where no specific legal switching right applies. Use official guidance and qualified legal advice for scope and rights.

Define data rights and responsibilities precisely

Create a data map covering customer, employee, finance, product, device, telemetry, derived, model, log, configuration, and support information. Record controller or equivalent role where applicable, contractual rights, intellectual property, trade secrets, retention, location, processors, recipients, access interface, and deletion. Terms such as ownership can obscure different rights to access, use, share, protect, retain, or delete.

Connected-product data may involve the user, manufacturer, service provider, third party, and individuals whose information appears in the dataset. Access must not override privacy, security, or trade-secret controls. Authenticate requesters, authorize fields and periods, minimize data, log disclosure, and provide understandable metadata. A bulk export without meaning or safeguards is not responsible portability.

Inventory the complete cloud dependency

Map compute, containers, functions, databases, object stores, queues, identity, keys, certificates, DNS, network, observability, backups, deployment, source code, registries, third-party APIs, licenses, support, and operational knowledge. Record owners, versions, configuration, regions, data volumes, service levels, recovery, and replacement options. Managed services may reduce operating burden while increasing migration work; that tradeoff should be explicit.

Distinguish data export from functional equivalence. A database dump may preserve records but not authorization, jobs, indexes, event order, encryption, or application behavior. An infrastructure template may not include manually configured identity or vendor settings. Document what must be rebuilt and what can be transformed. Prioritize essential business services and maximum tolerable downtime.

Cloud exit map covering data, applications, identity, networking, operations, contracts, and verification
A usable exit spans the whole service dependency chain, not only stored files.Original LedgerByte illustration

Negotiate contracts for a real exit

Before commitment, review notice, term, renewal, early termination, switching assistance, export format, APIs, data volume, egress or transfer charges, professional services, service continuity, deletion, verification, backups, logs, subcontractors, insolvency, and dispute terms. Confirm which provider tools remain available during transition and for how long after termination. Record who owns migration work and third-party costs.

Service credits do not restore a failed business. Require incident and change notification, support routes, and evidence appropriate to risk. Avoid automatic renewals that expire before migration can complete. Place key dates in the vendor calendar. Preserve copies of contracts, architecture, configuration, invoices, and export procedures outside the provider portal. Qualified counsel should assess unfair terms or statutory rights in the relevant context.

Engineer portability without avoiding useful cloud services

Portability does not require using only the lowest common denominator. A managed database or event service can create genuine value. Make the choice with an exit estimate and mitigation: open data formats, abstraction at selected boundaries, container or standard protocol where useful, infrastructure as code, automated deployment, documented transformations, and portable observability. Keep business logic from depending unnecessarily on provider-specific metadata.

Control identity and encryption. Know how users, workloads, keys, certificates, and secrets are recreated or rotated in a destination. Avoid making the only backup decryptable solely by a service being exited without a tested recovery path. Export access policy and audit evidence where needed, but do not copy stale privileges blindly. A migration is an opportunity to revalidate access.

Test switching and data access

Run periodic exports and validate completeness, integrity, metadata, schema, permissions, timestamps, and usability. Restore a representative service in an isolated environment or alternate region or provider. Measure time, bandwidth, cost, transformation, manual work, skill gaps, and business validation. Test at realistic data volume; a small sample may hide a multi-day transfer or throttling limit.

For connected-product access, test request authentication, scope, consent or authority, format, rate limit, privacy filtering, trade-secret protection, delivery, revocation, and audit. Include an incorrect or excessive request and a vulnerable requester. Provide documentation so recipients can interpret the data. Monitor abuse and operational load without making legitimate access impractical.

Maintain an exit plan as architecture changes

Assign executive, technical, data, security, legal, finance, procurement, and business owners. Define exit triggers such as service failure, security risk, legal change, price, product retirement, acquisition, or strategic move. Maintain options: alternate provider, self-managed restoration, regional failover, reduced manual operation, or orderly shutdown. Not every workload needs live multi-cloud; each needs a proportionate continuity and exit decision.

Review dependency, data map, contract, export, restore test, cost, skill, and provider roadmap annually and after material change. Close exercise findings. Cloud portability is not the claim that switching is effortless. It is evidence that the SME understands what it depends on, can retrieve and protect its data, can continue critical work, and retains credible choices when commercial or legal conditions change.

Include finance in exit modeling. Estimate parallel-service periods, data transfer, support, engineering, licenses, tax, contract termination, write-offs, and temporary productivity loss. Compare these costs with the risk and value of remaining. A low monthly price can coexist with a high exit cost. Record assumptions and update them as data and architecture grow so leadership can make an informed timing decision.

Plan deletion as carefully as export. Define which production, replica, backup, log, support, test, and subcontractor copies should be removed, which must be retained, the legal basis, and how deletion is verified. Revoke credentials and network paths and monitor for residual billing or activity. Do not demand immediate deletion of records the SME is legally required to preserve; coordinate privacy, legal, security, and records owners.

Avoid a portability project that weakens security. Migration copies can multiply sensitive data, bypass normal controls, or travel through personal storage. Use approved encrypted transfer, access limits, integrity checks, secure temporary environments, and deletion. Rotate keys and secrets appropriately. Monitor both source and destination during transition and document custody of export media and credentials.

For connected products, incorporate access rights into product design: data catalog, user identity, consent or authority, export, API, rate limits, security, privacy, trade secrets, support, and audit. Retrofitting an undocumented device fleet is expensive. Procurement should ask manufacturers and platform partners how data is exposed, updated, retained, shared, and transferred before the SME commits to a product ecosystem.

Define acceptance in business terms. A destination should process orders, authenticate users, issue reports, preserve balances, meet performance, support operations, and reconcile data—not merely start an application. Business owners should approve representative workflows and totals. Keep source systems in a controlled read-only or rollback state until evidence supports cutover and retention obligations permit closure.

Maintain skills and documentation. Portability fails when only a departed consultant understands transformations or when runbooks depend on a provider portal during termination. Store diagrams, code, schemas, decisions, credentials procedures, and test results in controlled company repositories. Rotate owners through exercises and keep vendor support contacts current. Knowledge is a migration dependency.

Use portability as leverage for better architecture, not as a threat in every vendor relationship. Share realistic requirements, request roadmap evidence, and negotiate proportionate support. Some services may remain intentionally provider-specific because their value exceeds exit cost. Record that decision and revisit it. Informed lock-in is different from dependency discovered during a crisis.

Finally, treat every exit exercise as an architecture review. Remove undocumented workarounds, improve exports, close stale access, and update costs and recovery objectives. The goal is not frequent switching. It is sustained evidence that the SME can make a deliberate choice while protecting customers, records, and essential operations.

Cloud portability evidence pack
AreaEvidenceFailure it prevents
DataCatalog, rights, formats, volumes, retention, export testIncomplete or unusable transfer
ApplicationDependency map, code, configuration, transformationData moves but the service does not work
Identity and securityUsers, workloads, keys, logs, policy recreationLockout, overexposure, or lost evidence
Contract and costNotice, assistance, charges, deletion, datesCommercial surprise and missed window
OperationsOwners, runbook, restore result, fallback, acceptanceUncoordinated migration and prolonged outage

Frequently asked questions

Does the EU Data Act mean cloud switching is free?

The Act includes switching-related provisions and a phased approach to certain charges, but exact rights, dates, services, and permitted costs require current legal analysis. Engineering, assistance, transformation, and business costs may still exist.

Does data ownership mean an SME can export everything?

No. Different parties may hold access, use, intellectual-property, privacy, confidentiality, retention, or deletion rights. Map the dataset and obtain advice. Export must respect other people’s rights and security.

Is multi-cloud required for portability?

No. Multi-cloud can add complexity and cost. A proportionate strategy may use tested exports, infrastructure as code, documented dependencies, an alternate restore path, contract rights, and a manual continuity plan rather than active duplication.

Sources

  1. EU Data Act gives users control over data from connected devicesEuropean Commission
  2. Data Act explainedEuropean Commission
  3. Digital Identity GuidelinesNational Institute of Standards and Technology