EU Cloud Switching & Exit Readiness Report 2026

Executive Summary

The EU Data Act turns cloud switching from a largely contractual question into a regulated operational process. The Regulation has applied since 12 September 2025. For providers of data processing services it sets out requirements for removing switching obstacles, for contractual transparency and for supporting the switch. From 12 January 2027, switching charges including the data egress fees incurred for a covered switch are to be removed entirely.

That does not automatically eliminate cloud lock-in. Data transfer is only one layer. A real exit covers data and metadata, schemas, identities, keys, networks, service dependencies, deployment artifacts, observability, operational knowledge, contracts and a controlled shutdown path. Even a provider with free egress can create high switching costs if proprietary managed services, missing export paths or untested restore processes dominate.

This report consolidates three investigations:

1. a Documentation Readiness Score for five major cloud providers;
2. a reproducible routine egress model for 1, 10 and 100 TB plus a matrix of public exit programs;
3. ten documented product shutdowns and service endings as recovery case studies.

The results are deliberately not a certificate of compliance. They show which information is publicly findable, which cost classes can be calculated and which operational controls a customer has to own.

Citable key findings

1. [OBSERVED] The EU Data Act has applied since 12 September 2025; its cloud switching rules address technical, contractual, commercial and organizational obstacles.
2. [OBSERVED] From 12 January 2027, switching charges including the corresponding data egress fees are to be removed entirely. This rule must not be equated with generally free ongoing internet egress.
3. [CALCULATED] In the disclosed documentation score, Google Cloud reaches 95/100, Oracle Cloud Infrastructure 88/100, Azure 84/100, AWS 82/100 and IBM Cloud 65/100. What is measured is public documentation maturity, not actual legal compliance.
4. [CALCULATED] In the routine egress scenarios, the modeled transfer costs range from zero or bundled amounts up to several thousand euros per month, depending on provider, tariff logic and volume. Requests, retrieval, storage, support and engineering have to be accounted for separately.
5. [OBSERVED] Several hyperscalers document programs or credits for a complete planned exit. Conditions, deadlines, scope and account closure differ.
6. [INTERPRETATION] A statutory switching right is only operationally usable if export, rehydration, reconciliation, security and cutover have been tested beforehand.
7. [INTERPRETATION] A long shutdown notice period does not prove recovery capability. Without a complete export and import path it merely extends the time during which the risk is visible.
8. [RECOMMENDATION] Every critical cloud service needs a versioned exit record, a tested export artifact, a target architecture, a cost budget, a RACI and a last successful drill.

---

1. Research question and scope

How far do law, public provider documentation and pricing programs reduce the switching barrier – and which exit costs and recovery tasks remain with the customer?

Four levels are examined:

Level	Object of investigation	not claimed
Law	Data-Act-related requirements and dates	individual legal advice or a compliance audit
Documentation	publicly findable switching, export and support paths	actual quality of a specific enterprise project
Costs	public routine egress prices and documented exit programs	complete TCO of a specific account
Recovery	public shutdown/sunset cases and the controls derivable from them	representative failure probability across all providers

1.1 Objects of analysis

• five major cloud providers in the Documentation Readiness Score;
• eight object storage or cloud egress models;
• publicly documented full-exit or egress rules;
• ten shutdown/sunset events between 2015 and 2026;
• seven technical and organizational exit layers.

1.2 Statement classes

• [OBSERVED]: documented directly from a public source;
• [CALCULATED]: calculated from disclosed rules and data;
• [SCENARIO]: modeled assumption, not an observed customer case;
• [INTERPRETATION]: analytical conclusion;
• [RECOMMENDATION]: operational recommendation for action.

---

2. The shared exit model

A cloud exit is not a single data export. FW Delta Research uses seven separable layers.

Layer	state to be transferred	typical hidden dependency	evidence of a robust exit
1. Contract	termination, deadlines, fees, support	automatic renewal, minimum purchase	audited exit calendar and cost approval
2. Data	payload data, files, metadata, history	incomplete exports, retrieval fees	complete export plus checksums
3. Schema and logic	data models, rules, jobs, policies	proprietary workflows and functions	machine-readable definitions and mapping
4. Identity and secrets	roles, groups, keys, certificates	provider IAM, non-exportable secrets	new IAM model and rotation
5. Network	DNS, IPs, peering, firewalls, egress	private endpoints, fixed allow lists	reproducible network configuration
6. Operations	logs, alerts, SLOs, runbooks, backups	provider-bound observability	target monitoring and tested restore
7. Shutdown	reconciliation, read-only, deletion	unknown residual data and open jobs	signed cutover and deletion record

2.1 The portability gap

Portability Gap =
required operational state
- actually exportable and restorable state

The larger this gap, the less relevant the pure egress rate becomes. A free data stream helps little if permissions, schedulers, functions, event routes or managed service semantics have to be reconstructed by hand.

2.2 Four cost classes

Total exit cost =
transfer costs
+ transformation costs
+ parallel operation
+ risk costs

Transfer costs cover egress, requests, retrieval, media and network. Transformation covers export scripts, schema mapping, replatforming and tests. Parallel operation arises from duplicated infrastructure, data replication and extended support contracts. Risk costs cover downtime, data loss, misconfiguration, security gaps and lost revenue.

---

3. Part I - Legal framework and public provider readiness

2. Legal framework

2.1 Date of application

[OBSERVED] Regulation (EU) 2023/2854 (Data Act) was published at the end of 2023 and has applied since 12 September 2025.

2.2 Switching between data processing services

Chapter VI targets obstacles to:

• switching to another provider,
• transfer to on-premises infrastructure,
• parallel use of several providers,
• porting exportable data and digital assets.

2.3 Deadlines

As a rule, the Data Act provides for a maximum transitional period of 30 calendar days after the relevant notice/initiation phase. Where this is not technically feasible, a reasoned alternative transitional period of at most seven months can become relevant under the statutory conditions. The contract must also address a minimum period for data retrieval after the transition.

The exact application depends on the contract, the service and the facts of the case.

2.4 Switching charges

The European Commission explains:

• a transitional regime applies until 12 January 2027,
• from 12 January 2027, switching charges including data egress are to be removed entirely insofar as they serve the switch.

Three distinctions are decisive:

1. Routine egress: ongoing data traffic in normal operation
2. Switching egress: data transfer as part of a qualifying switch
3. Early termination/commitment: remaining contractual or minimum purchase obligations

A provider can waive switching egress and still charge for routine egress. A fee waiver also does not automatically end minimum terms or other contractual obligations.

---

---

3. Methodology

3.1 Sample

• Amazon Web Services
• Microsoft Azure
• Google Cloud
• Oracle Cloud Infrastructure
• IBM Cloud

OVHcloud and Hetzner were considered in the research but not ranked. Up to the data cutoff date, no sufficiently dedicated, publicly findable Data Act mapping page with comparable depth of detail was identified. NR here means not ranked, not “not compliant”.

3.2 Criteria

Code	Criterion	Weight
L	dedicated legal mapping or addendum	15
P	public switching process	15
E	service-specific export documentation	15
F	formats, APIs and interfaces	15
T	deadlines, transition and continuity	10
C	treatment of switching/egress costs	15
D	retrieval, deletion and closure	10
S	support and escalation path	5

Readiness Score = L + P + E + F + T + C + D + S

3.3 Object of assessment

The score measures the quality of public traceability. It does not measure internal operational capability. A provider can have a high score and still require a complex migration.

---

---

4. Overall result

Rank	Provider	documentation maturity / 100
1	Google Cloud	95
2	Oracle Cloud Infrastructure	88
3	Microsoft Azure	84
4	AWS	82
5	IBM Cloud	65

Complete matrix

Provider	L /15	P /15	E /15	F /15	T /10	C /15	D /10	S /5	Total
Google Cloud	15	15	15	15	10	15	5	5	95
Oracle Cloud Infrastructure	15	15	15	13	10	10	5	5	88
Microsoft Azure	15	12	15	12	10	10	5	5	84
AWS	15	10	15	12	10	10	5	5	82
IBM Cloud	10	8	10	10	5	10	7	5	65

Machine-readable version:

data/FDR-2026-05_cloud_switching_readiness.csv

---

---

5. Provider analyses

5.1 Google Cloud – 95 points

Google publishes a detailed mapping of Data Act articles to contract clauses and process components. The mapping page covers, among other things:

• 30-day Migration Period,
• Initiation Period,
• alternative deadline in case of technical impossibility,
• exportable data and digital assets,
• excluded internal data,
• Data Recovery Period,
• deletion,
• Business Continuity,
• security requirements.

In addition there is general data portability documentation and a program for eliminating certain data transfer fees on a complete switch.

[INTERPRETATION] Google reaches the highest value not because of a claimed “easy migration”, but because the public documentation links contract, deadline and process granularly.

5.2 Oracle Cloud Infrastructure – 88 points

Oracle provides a dedicated EU Data Act page and service-specific notes on switching methods. An addendum covers contractual aspects.

Strengths:

• dedicated legal and contractual documentation,
• concrete service-specific export and migration paths,
• support reference.

Limits:

• the overall process is spread across several documents,
• “no switching charges” has to be separated from remaining early termination or commitment effects,
• retrieval and deletion logic is publicly less compact than in the Google mapping.

5.3 Microsoft Azure – 84 points

Microsoft documents data export and cloud choice via APIs, PowerShell, portals and machine-readable formats. The public bandwidth page also describes a procedure for free egress in the case of a complete exit from Azure.

Strengths:

• broad export documentation,
• free exit egress with an application process,
• clear administrative tools,
• extensive service-specific documentation.

Limits:

• some configurations and proprietary data are not exportable identically,
• Data-Act-specific end-to-end documentation is less centralized,
• a credit or support process is not the same as automatically fee-free routine egress.

5.4 AWS – 82 points

In 2024 AWS announced a worldwide program under which customers can have additional data transfer out credited via support for a complete switch. Later updates point EU customers to a Data Act addendum and defined process criteria.

Strengths:

• documented support path,
• established service export tools,
• free exit DTO credits under conditions,
• extensive technical migration documentation.

Limits:

• the customer has to register the exit as such,
• approval and time window are process-bound,
• the breadth of AWS services makes “functional equivalence” a workload-specific question,
• routine egress and a qualifying exit have to be kept separate.

5.5 IBM Cloud – 65 points

In the Cloud Terms, IBM notes that EU customers migrating out of IBM Cloud may be entitled to reduced data egress charges under the Data Act conditions and should contact support or their designated contact.

Strengths:

• Data Act mentioned publicly,
• support and case path,
• contractual reference.

Limits:

• fewer public end-to-end process details,
• a less granular service and deadline mapping approach,
• fee treatment and export categories tend to require individual support.

[INTERPRETATION] The lower score is a statement about public documentation density, not about the customer’s actual legal position.

---

---

6. What a cloud exit actually covers

6.1 Data

• object and file storage
• databases
• snapshots
• logs
• backups
• secrets
• metadata
• IAM configuration
• images and artifacts

6.2 Compute

• VM images
• containers
• serverless functions
• autoscaling
• scheduling
• accelerator/GPU dependencies

6.3 Network

• IP addresses
• DNS
• load balancers
• firewalls
• private links
• peering
• routing
• certificates

6.4 Managed services

This is where the largest semantic rebuild arises:

• proprietary databases
• queues
• event bus
• AI/ML services
• observability
• identity
• data warehouses
• serverless platforms

[INTERPRETATION] The Data Act can reduce contractual and technical obstacles. It does not, however, automatically turn a proprietary managed service into an identical portable runtime.

---

---

7. Switching readiness on the customer side

7.1 Exportable asset register

For each service:

Field	Example
Service	Managed PostgreSQL
Data	tables, WAL, users, extensions
Export format	SQL dump, logical replication
Volume	4.2 TB
Dependencies	IAM, KMS, DNS, monitoring
RTO/RPO	2 h / 5 min
Target	PostgreSQL at another provider
Validation	row counts, checksums, query suite
Owner	Data Platform
last test	2026-06-15

7.2 Exit runbook

1. Freeze the scope.
2. Provision the target environment.
3. Check data classification and legal basis.
4. Plan full and delta transfer.
5. Rotate secrets and keys.
6. Test performance.
7. Check business continuity.
8. Cutover.
9. Validation.
10. Use the retrieval period.
11. Confirm deletion.
12. Close contract and billing.

7.3 Exit budget

Even with zero switching charges, what remains is:

• engineering
• target infrastructure
• parallel operation
• tests
• downtime risk
• data cleanup
• application conversion
• training
• external consulting

A fee waiver removes one invoice line, not the migration project.

---

---

8. Procurement requirements from 2026

[RECOMMENDATION] New cloud contracts should address at least:

• exportable categories,
• excluded internal data,
• formats and APIs,
• notice and initiation process,
• maximum transition,
• technical impossibility and extension,
• continuity and security,
• retrieval period,
• deletion confirmation,
• switching charges,
• routine egress,
• commitments and early termination,
• support SLA,
• test export,
• subprocessor and marketplace dependencies.

Contract and architecture test

The best moment for the first exit test is before go-live, not before termination.

---

---

9. Why egress alone is not a measure of lock-in

A storage provider can charge zero egress fees and still create high switching costs if:

• APIs are proprietary,
• data models are not portable,
• export is slow,
• dependencies and identities are missing,
• managed services have to be reimplemented.

Conversely, a provider can charge for egress but offer standardized formats and very good export tooling.

[INTERPRETATION] Lock-in is multidimensional:

data volume
× egress price
+ semantic rebuild
+ operational interruption
+ contractual commitment
+ organizational effort

---

4. Part II - Routine egress, exit programs and cost model

2. Terms that must not be conflated

2.1 Routine egress

Recurring transfer out of the cloud service to internet destinations, for example:

• downloads by end customers,
• data hand-off to partners,
• CDN origin traffic,
• regular replication into another environment,
• analytics or backup exports,
• API responses with high data volume.

This traffic is part of normal operation. A provider can bill it by volume, bundle it into a tariff, tie it to storage usage or state it as zero.

2.2 Planned exit

A planned complete or largely complete change of provider. Separate conditions can apply to it:

• support request,
• exit notice,
• defined migration period,
• credit instead of an immediate zero price,
• list of covered services,
• closure or termination process,
• exclusion of repeated or normal transfers.

An exit program is therefore not a flat rate for ordinary traffic.

2.3 Switching charges under the EU Data Act

The EU Data Act addresses obstacles to switching between data processing services. The European Commission describes that switching charges including fees for data egress are to be removed entirely from 12 January 2027. Until then a transitional phase applied in which cost-based fees were possible.

[CRITICAL] The concrete scope has to be examined legally and contractually. The report does not deal with any individual case and does not claim that from 12 January 2027 all internet egress will be free regardless of occasion, contract, customer location and service.

2.4 Data retrieval

Retrieval is the technical or tariff-based re-provisioning of data out of a storage class. A provider can state egress as zero and charge for retrieval at the same time. For archive or infrequent access classes this is decisive for exit costs.

---

---

3. Methodology

3.1 Sample

The sample covers eight providers:

• AWS
• Microsoft Azure
• Google Cloud
• Cloudflare R2
• Backblaze B2
• Wasabi
• OVHcloud
• Hetzner Object Storage

A numerical routine egress model was built for AWS, Azure and Google Cloud. The five other providers were analyzed in a policy matrix because of their differing bundle, zero-price or fair-use models, rather than forcing them into the same price series through a false equivalence.

3.2 Unit

The usage volume is defined as a decimal TB:

1 TB = 1,000 GB = 10^12 bytes

Provider-specific billing units are preserved:

• For the table under consideration, Azure explicitly publishes 1 TB = 1,000 GB.
• AWS examples use 1 TB = 1,024 GB for TB thresholds; the model thresholds were set accordingly.
• Google Cloud bills the cloud storage transfer under consideration per GiB and tiers it in TiB. Decimal TB were therefore converted into GiB.

This separation prevents identically labeled “TB” from being tacitly treated as an identical billing unit.

3.3 Scenario

What is modeled:

• source in Europe or a European reference region,
• transfer to the public internet,
• normal destination area without higher special tariffs,
• one billing month,
• 1, 10 or 100 decimal TB,
• public pay-as-you-go list prices,
• no individual discounts or commitments.

3.4 Exclusions

Not included are:

• storage capacity,
• PUT/GET/List or other API operations,
• retrieval and early deletion fees,
• compute and database exports,
• inter-region or inter-zone traffic,
• CDN and private interconnects,
• premium routing or acceleration,
• support,
• value added tax,
• contractual penalties and remaining terms,
• engineering and dual running,
• downtime and opportunity costs.

3.5 Currency

EUR cost = USD cost / 1.1367

The ECB reference rate of 28 July 2026 was used. The conversion is a normalization for comparison, not an invoice amount.

---

---

4. Routine egress: public list prices

Monthly volume	AWS	Microsoft Azure	Google Cloud
1 TB	€71.26	€68.88	€98.32
10 TB	€783.85	€757.72	€983.19
100 TB	€6,872.70	€6,759.04	€9,102.62

Machine-readable inputs, units, USD values, EUR values and sources:

data/FDR-2026-05_egress_costs.csv

4.1 AWS

[OBSERVED] For data transfer out from regions to the internet, AWS states the first 100 GB per month as free. An official S3 example quotes USD 0.09 per GB for Europe (Ireland). Public AWS DTO examples then document tier values of USD 0.09 for the first 10 TB, USD 0.085 for the next 40 TB and USD 0.07 for the next tier.

[CALCULATED] The normalized model yields:

• 1 TB: EUR 71.26
• 10 TB: EUR 783.85
• 100 TB: EUR 6,872.70

The calculation is a representative list price model for the data path under consideration, not a complete AWS invoice calculator. Service, region and transfer path can differ.

4.2 Microsoft Azure

[OBSERVED] For internet egress via the Microsoft Premium Global Network out of Europe and North America, Azure publishes:

• first 100 GB per month free,
• next 10 TB: USD 0.087 per GB,
• next 40 TB: USD 0.083 per GB,
• next 100 TB: USD 0.07 per GB,
• next 350 TB: USD 0.05 per GB.

[CALCULATED] From this follow:

• 1 TB: EUR 68.88
• 10 TB: EUR 757.72
• 100 TB: EUR 6,759.04

4.3 Google Cloud

[OBSERVED] Google Cloud Storage bills general network usage to worldwide destinations outside Asia and Australia at:

• 0 to 10 TiB: USD 0.12 per GiB,
• 10 to 150 TiB: USD 0.11 per GiB,
• above that: USD 0.08 per GiB.

[CALCULATED] After converting the decimal usage volumes into GiB:

• 1 TB: EUR 98.32
• 10 TB: EUR 983.19
• 100 TB: EUR 9,102.62

[CRITICAL] Destination regions such as Australia or China have different prices. The comparison must not be transferred to those paths.

---

---

5. What the numbers mean – and what they do not

5.1 Recurrence makes the position strategic

[CALCULATED] At a constant 10 TB every month, twelve months produce:

Provider	annual value, routine egress only
AWS	€9,406.18
Microsoft Azure	€9,092.64
Google Cloud	€11,798.23

In this narrowly defined model the difference between Azure and Google Cloud is roughly EUR 2,705.59 per year. It does not follow that Azure is cheaper overall. A lower network price can be more than offset by higher costs elsewhere.

5.2 Volume discounts do not dissolve the absolute cost position

At 100 TB the effective euro amount per TB falls through the tiers. The total bill nevertheless stays in the four-digit monthly range. Especially with media, telemetry, backups, AI datasets and cross-cloud architectures, egress can therefore become an architecture variable instead of an incidental cost item.

5.3 A public price is not the real contract

Enterprise contracts can contain:

• discounted data transfer,
• private commitments,
• credits,
• spend-based rebates,
• CDN bundles,
• individual regional prices,
• minimum purchase amounts or termination consequences.

The list price is therefore a reproducible baseline, not necessarily the invoiced amount.

---

---

6. Providers with zero, conditionally zero or bundled egress

Provider	public routine rule	important counter-position
Cloudflare R2	egress stated as 0 for Standard and Infrequent Access	storage and operations; IA retrieval 0.01 USD/GB; 30 days minimum duration
OVHcloud Object Storage	no ingress, egress or API fees on the page under consideration	retrieval or restored data possible per storage class
Backblaze B2	free up to three times the average monthly storage	above that 0.01 USD/GB; the free allowance depends on byte-hour storage
Wasabi Pay as You Go	no egress price as long as monthly egress is at most equal to active storage	1 TB minimum commitment and 90 days minimum retention period
Hetzner Object Storage	1 TB egress and 1 TB storage included in the base tariff	overage pay as you go; check the current dynamic overage value before going live

Complete policy matrix:

data/FDR-2026-05_exit_policy_matrix.csv

6.1 Why zero is not the same as free

Example Cloudflare R2:

Egress = 0
total cost = storage + Class A operations + Class B operations + retrieval where applicable

Example Wasabi:

free egress applies only within the published storage-to-egress ratio
+ minimum commitment
+ minimum retention period

Example Backblaze:

free egress = up to 3 × average monthly storage
overage = 0.01 USD/GB

[INTERPRETATION] A fair comparison needs at least two axes:

1. cost per stored TB-month
2. cost per transferred TB at a real read/exit ratio

A pure zero egress figure favors providers with a higher storage or retrieval price; a pure storage comparison favors providers with expensive access.

---

---

7. Hyperscaler exit programs

7.1 AWS

[OBSERVED] AWS documents that customers switching to another provider or to on-premises can contact support in order to receive credits for data transfer out. The review takes place at account level. According to the update, eligible customers have 90 days for the switch as a rule and should inform support if more time is needed.

7.2 Microsoft Azure

[OBSERVED] Azure describes free egress for customers who take their data out of Azure entirely in order to move to another cloud provider or into their own data center. For volumes above the normal 100 GB free allowance, a credit process is provided.

7.3 Google Cloud

[OBSERVED] The Google Cloud Exit Program covers customers who migrate all workloads and data and then end their Google Cloud contractual relationship. The process comprises an exit notice, a defined start process and a completion notice; not every service and not every normal transfer falls under it automatically.

7.4 Consequence for cost models

A robust model contains two lines:

routine egress at the normal operating price
planned-exit egress at the requested/contractually confirmed treatment

Only after written confirmation may exit egress be entered as zero in the project budget. A public program does not replace an account-level review.

---

---

8. EU Data Act: what changes on 12 January 2027

[OBSERVED] The Data Act has applied since 12 September 2025. For cloud switching, the Commission describes:

• contractual and transparency requirements,
• technical support and removal of obstacles,
• open interfaces or exportable formats for certain services,
• functional equivalence as a goal for certain IaaS switches,
• complete removal of switching charges including data egress from 12 January 2027.

No blanket zero-egress regulation

The central sentence is not:

Every data transfer out of the cloud is free.

But rather, in substance:

Fees for the operations necessary for a covered switch, and for data egress, are to be removed.

From this follow review questions:

• Are the customer and the contract within the territorial and personal scope?
• Is this a switch or normal continuous operation?
• Which services and data are covered?
• Which exit and notice processes apply?
• Which services are strictly necessary?
• Which third-party and marketplace costs remain?
• Which remaining terms or commitments are not a switching charge?

[RECOMMENDATION] From 2027, procurement should not simply delete the egress line but require a separate switching cost schedule in the contract, with items that can go to zero, items that remain and items that are unresolved.

---

---

9. The actual equation of a cloud exit

Total Exit Cost
= network and switching fees
+ retrieval and API operations
+ transfer tooling and temporary infrastructure
+ dual running
+ data model and format transformation
+ re-platforming of managed services
+ IAM, secret and key migration
+ network, DNS and certificate changeover
+ tests, reconciliation and audit evidence
+ downtime and performance risk
+ remaining terms and commitments
+ internal and external engineering time

9.1 Semantic exit

Being able to export data as bytes does not mean a system has been ported. Examples:

• proprietary warehouse functions,
• cloud-specific IAM roles,
• event bus semantics,
• managed Kubernetes extensions,
• serverless triggers,
• monitoring and alerting history,
• key material and HSM integration,
• database extensions,
• ML feature stores and vector indexes.

9.2 Time is a cost factor

With large data volumes, bandwidth, API limits and export windows can extend the migration. Longer dual running creates compute, storage, license and staffing costs – even if the pure egress fee is zero.

9.3 The cheapest transfer can be the most expensive rebuild

A standardized S3-compatible archive can be easy to migrate despite an egress fee. An egress-free proprietary managed service can create high re-platforming costs. Exit risk therefore has to be assessed separately by bytes, semantics and operations.

---

---

10. Exit budget for decision-makers

10.1 Mandatory fields per service

Field	Question
Data volume	How many TB have to be transferred completely, incrementally and repeatedly?
Routine or exit	Is the transfer normal operation or a qualifying change of provider?
Storage class	Do retrieval charges or minimum retention periods apply?
Format	Is the export format open, complete and documented?
Bandwidth	What realistic net transfer rate is available?
Consistency	How are changes synchronized during the migration?
Dependencies	Which IAM, network, event, key and managed service dependencies exist?
Dual running	How long do source and target have to run in parallel?
Contract	Which notice, credit, commitment and deletion conditions apply?
Evidence	How are completeness, integrity and deletion demonstrated?

10.2 Three budget pots

A. Routine Data Movement
B. Planned Switching Project
C. Emergency Exit / Provider Failure

The emergency exit needs its own assumption. A credit process that requires support contact and lead time is no substitute for a scenario in which the provider or the account is unavailable at short notice.

10.3 Control metrics

Routine Egress Rate
= monthly external transfer / average stored data

Exit Throughput
= successfully validated data volume / migration day

Semantic Portability Coverage
= portable critical functions / total critical functions

Exit Cost at Risk
= unresolved fees + remaining terms + estimated re-platforming effort

---

---

11. Architecture measures that lower cost and risk at the same time

Data

• open formats and documented schemas,
• regular external snapshots,
• checksums and reconciliation,
• separate hot, warm and archive strategy,
• independent key and secret management where sensible.

Application

• cloud-specific adapters at clear boundaries,
• infrastructure as code,
• reproducible builds,
• no business logic exclusively in proprietary low-code flows,
• export and import paths as a product feature.

Operations

• restore and exit drills,
• measured net bandwidth,
• documented API limits,
• runbooks and responsibilities,
• monitoring outside the primary provider,
• a tested, working DNS and certificate changeover.

Contract

• exit notice and credit process,
• service list and fee matrix,
• retrieval and API costs,
• deletion and transition period,
• support and data formats,
• treatment of subprocessors and marketplace products,
• obligations under the Data Act from 2027.

---

5. Part III - Shutdown notice and recovery evidence

2. Event types

Planned sunset

The provider announces an end date with lead time and describes export or replacement.

Product consolidation

Functionality is moved into another product, a partner or a platform.

Support end-of-life

Development or support ends while local artifacts can partly continue to be used.

Read-only tail

Productive use ends; data remains readable or exportable for a defined period.

Incident-driven shutdown

A service is first taken offline for security, abuse or operational reasons; the formal discontinuation follows later.

[INTERPRETATION] These types must not be mixed into a single notice metric. A negative value for Firefox Send shows a different risk pattern than 731 days of lead time for Adobe Muse.

---

---

3. Methodology

3.1 Sample

The cases were selected because official announcements or support materials were publicly available and because they represent different shutdown types.

The sample is:

• not random,
• not representative,
• spread across different categories,
• limited to publicly reconstructable events.

3.2 Metrics

Notice Days
= primary service end date
- public announcement date

Post-End Export Days
= read-only/export end date
- primary service end date

Where no robust announcement date emerged from the primary source reviewed, no notice value is estimated.

3.3 Qualitative fields

For each event the following were recorded:

• export path,
• migration path,
• named replacement,
• refund/credit,
• data deletion or retention note.

Values:

1.0 = clearly documented
0.5 = partial, restricted or contract-specific
0.0 = not sufficiently documented in the primary source reviewed

---

---

4. Event matrix

Event	Provider	Announcement	Service end	Notice days	Post-end window
Universal Analytics Standard	Google	16 March 2022	1 July 2023	472	366
Stadia	Google	29 September 2022	18 January 2023	111	0
Google Optimize / Optimize 360	Google	20 January 2023	30 September 2023	253	0
Jamboard app and devices	Google	28 September 2023	1 October 2024	369	91
Hipchat Cloud and Stride	Atlassian	26 July 2018	15 February 2019	204	28
Adobe Muse development/support	Adobe	26 March 2018	26 March 2020	731	365
Workplace from Meta	Meta	14 May 2024	31 August 2025	474	273
Firefox Send	Mozilla	17 September 2020	7 July 2020	-72	0
Firefox Notes sync service	Mozilla	17 September 2020	1 November 2020	45	0
Firebase Dynamic Links	Google	not robustly documented	25 August 2025	n/a	0

Statistical classification

• [CALCULATED] Positive, precisely dated planned notices: n = 8
• [CALCULATED] Median: 311 days
• [CALCULATED] Minimum: 45 days
• [CALCULATED] Maximum: 731 days
• [CALCULATED] Precisely dated events including Firefox Send: n = 9
• [CALCULATED] Median including the negative incident-driven timeline: 253 days
• [CALCULATED] Cases with a positive post-end window: 5 of 10
• [CALCULATED] Median post-end across all cases including zero: 14 days

[CRITICAL] These metrics must not be extrapolated to the entire SaaS market.

---

---

5. Case studies

Universal Analytics Standard

[OBSERVED] On 16 March 2022, Google announced that standard Universal Analytics properties would stop processing new data from 1 July 2023. The reconstructed lead time is 472 days. Access to and export of historical data remained provided for until 1 July 2024.

[INTERPRETATION] This is an example of a long transition with a named successor. Even so, the migration was not a pure export: event model, attribution, reporting and implementation all changed.

Stadia

[OBSERVED] The discontinuation was announced on 29 September 2022 for 18 January 2023, corresponding to 111 days. Google announced refunds for relevant purchases.

[INTERPRETATION] A refund reduces financial loss but does not port a user library or the service state to an alternative platform.

Google Optimize / Optimize 360

[OBSERVED] The service ended on 30 September 2023. The matrix dates the historical announcement to 20 January 2023; this value has to be confirmed again against an archived primary record before publication.

[CRITICAL] If the original announcement date is not preserved in the current support page, the live version must either cite a web archive record or remove the notice value as not verifiable.

Jamboard

[OBSERVED] Google announced the next phase on 28 September 2023. App operation entered a final phase on 1 October 2024; an additional read-only and export window ran until 31 December 2024.

[RECOMMENDATION] Whiteboard content should be migrated not only as static images but with ownership, context and target assignment.

Hipchat Cloud and Stride

[OBSERVED] Atlassian announced the partnership with Slack on 26 July 2018; the services ended on 15 February 2019. In the matrix, export remained possible until 15 March 2019.

[INTERPRETATION] A named partner path can make migration easier but creates a new provider dependency.

Adobe Muse

[OBSERVED] Adobe discontinued development on 26 March 2018 and supported the product until 26 March 2020. For certain hosted Business Catalyst sites, the transition under consideration ran until 26 March 2021.

[INTERPRETATION] Local design artifacts and a hosted runtime have different end-of-life clocks.

Workplace from Meta

[OBSERVED] Meta added to its Workplace communication on 14 May 2024. In the matrix, regular use ran until 31 August 2025; a read and download phase until 328 July 2026.

[RECOMMENDATION] With collaboration systems, messages, files, groups, integrations, identity, compliance archives and communication culture have to be migrated separately.

Firefox Send

[OBSERVED] Mozilla took Firefox Send offline as early as July 2020 and confirmed the permanent discontinuation on 17 September 2020.

[INTERPRETATION] This is the most important counterexample to the assumption of a guaranteed lead time. Security or abuse events can skip the normal sunset process.

Firefox Notes

[OBSERVED] On 17 September 2020, Mozilla announced the end of the sync service for early November. The modeled lead time is 45 days.

[LIMITATION] A simple note service has a different migration complexity than CRM, analytics or messaging. The notice figure alone says nothing about adequacy.

Firebase Dynamic Links

[OBSERVED] Google documents the end of the service on 25 August 2025 as well as export and migration guidance.

[LIMITATION] The first robust announcement date was not sufficiently preserved in the current primary page reviewed. The report therefore calculates no notice value rather than estimating a date from secondary sources.

---

---

6. What a long notice does not solve

Discovery

Announcements can show up in:

• blog posts,
• admin banners,
• support articles,
• account emails,
• changelogs,
• contractual notices.

Without an owner and monitoring, the internal start can happen months later.

Inventory

Teams often do not know:

• which processes are affected,
• which data volumes exist,
• which integrations are running,
• which users or customers are dependent,
• which exports depend on planning or approval.

Replacement Fit

A named successor can bring:

• a different data model,
• different prices,
• different APIs,
• different compliance,
• less functionality

with it.

Parallel operation

Migration often requires:

• dual write,
• delta sync,
• read-only freeze,
• identity mapping,
• customer communication,
• rollback.

---

---

7. Shutdown Readiness Record

service: "..."
business_criticality: "high"
owner: "..."
vendor_status_sources:
  - "official-blog"
  - "admin-notices"
  - "legal-updates"
last_full_export: "YYYY-MM-DD"
export_frequency_days: 30
restore_last_tested: "YYYY-MM-DD"
portable_state:
  data: true
  files: true
  logic: partial
  permissions: partial
  audit: false
replacement_candidates:
  - "..."
maximum_tolerable_notice_days: 30
degraded_mode: "..."
customer_communication_template: "..."

[RECOMMENDATION] The record should be part of the service catalog and not only of the procurement folder.

---

---

8. Recovery strategies by state

Data

• regular exports,
• open formats,
• hashes and manifest,
• independent backups,
• documented retention.

Logic

• workflows as code or in a machine-readable format,
• document business rules outside the proprietary UI,
• tests and sample data.

Identity

• own domain,
• independent identity provider,
• group and role export,
• break-glass access.

Integrations

• API inventory,
• webhooks,
• credentials in your own secret store,
• adapter boundaries,
• fallback.

Communication

• stakeholders,
• customers,
• regulatory bodies,
• support scripts,
• status page.

---

---

9. Triggers for an early exit drill

• acquisition or strategic partnership,
• license or price change,
• falling release frequency,
• declining support,
• new export restrictions,
• product consolidation,
• discontinuation of adjacent features,
• high staff attrition at the provider,
• regulatory change,
• repeated incidents.

[CRITICAL] These signals do not prove an imminent shutdown. They justify updating the exit plan.

---

---

10. Connection to the EU Data Act

The EU Data Act strengthens portability and switching for covered data processing services. It does not, however, eliminate all shutdown risks:

• not every product falls within scope in the same way,
• application logic may remain proprietary,
• incident-driven shutdowns can happen quickly,
• the target system and the internal migration remain customer tasks,
• export rights do not replace a tested restore.

[INTERPRETATION] Regulation can improve the switching channel. Business continuity still has to be prepared architecturally.

---

6. Synthesis: what the law solves – and what architecture has to solve

6.1 From entitlement to operational capability

A statutory entitlement reduces asymmetric contractual power. It does not, however, replace execution capability. The customer still has to know:

• which state exists;
• which of it is business-critical;
• in which format it can be exported;
• which consistency limits apply;
• which target platform accepts the state;
• how long parallel operation is necessary;
• which cutover and rollback point is permissible;
• how deletion and contract termination are evidenced.

The decisive metric is therefore not “Can I terminate?” but:

Time to verified independent operation

It measures the time from the activated exit plan to a demonstrably functioning target system that runs without productive dependency on the previous provider.

6.2 Routine egress, full exit and Data Act switching

These three cases must not be conflated, neither editorially nor in the calculator.

Case	typical situation	pricing logic	required check
Routine egress	ongoing delivery to users or systems	normal public rate/free allowance	region, destination, tier, unit
Full exit program	customer moves all data/workloads and closes the account or contract	credit, waiver or application	eligibility, deadline, scope, account closure
Data Act switching	statutorily covered switch of a data processing service	transitional and later fee rules	scope of application, contract, necessary services

A headline such as “From 2027 cloud egress is free” would be wrong. The precise statement is: for covered switching charges including the corresponding data egress fees, the Data Act provides for complete abolition from 12 January 2027. Ongoing data transfer outside a switching process can continue to be priced.

6.3 Exit readiness as a controlled system

A robust program requires at least the following artifacts:

1. service and data inventory;
2. dependency graph;
3. data classification and retention map;
4. export and import procedures;
5. checksums and reconciliation rules;
6. target architecture and capacity assumptions;
7. IAM and secret rotation plan;
8. network and DNS cutover;
9. observability and incident plan;
10. contract, fee and support calendar;
11. RACI and escalation contacts;
12. last drill with findings and remediation.

6.4 Why multi-cloud is not automatically exit readiness

Multi-cloud can reduce or duplicate dependencies. Two providers do not automatically mean portability if:

• each application uses different proprietary services;
• data models diverge;
• identities are maintained separately;
• only one side is tested in production;
• costs and operational knowledge fragment;
• failover exists only on slides.

Real portability shows in reproducible artifacts and tested transitions, not in the number of cloud contracts.

---

7. 180-day exit program

Days 0–30: scope and evidence

• name a sponsor and an exit owner;
• prioritize critical services by revenue, regulatory and operational impact;
• inventory data, schemas, identities, secrets and network paths;
• record contracts, renewal dates and exit programs;
• pull first export artifacts and document them hash-based;
• define target RTO, RPO and maximum parallel operation.

Gate 1: For every tier-1 service there is an owner, a data class, an export path and a target hypothesis.

Days 31–60: export and rehydration

• produce complete exports in an isolated environment;
• check metadata, attachments, audit data and relations;
• build the target system;
• version mapping and transformation rules;
• run restore or import;
• compare volumes, checksums and business-level samples.

Gate 2: At least one representative state was restored outside the source system.

Days 61–90: functional and security parity

• implement IAM, roles and least privilege;
• rotate secrets;
• test integrations and event paths;
• activate monitoring, alerting, backup and incident runbooks;
• run performance, load and failure tests;
• prioritize open parity gaps.

Gate 3: The target system meets defined minimum SLOs and security controls.

Days 91–120: parallel operation

• activate change data capture or controlled synchronization;
• automate business-level reconciliation;
• move user groups or traffic across in stages;
• observe the costs of both environments daily;
• test rollback conditions and decision rights.

Gate 4: Deviations are measurable, explainable and within the error budget.

Days 121–150: cutover

• set a change freeze or defined write ownership;
• perform the final delta transfer;
• switch over DNS, routing, queues and integrations;
• obtain business acceptance;
• set the old service to read-only where possible;
• activate hypercare and executive reporting.

Gate 5: Productive operation is independent; rollback remains available for a limited time.

Days 151–180: closure

• final data and financial reconciliation;
• secure export artifacts and the evidence vault;
• decommission accounts, keys, peering and support contracts;
• obtain deletion and termination evidence;
• document lessons learned, actual costs and residual dependencies;
• schedule the next exit drill.

Gate 6: No unintended productive dependency and no unresolved residual data class remain.

---

8. Exit readiness scorecard for customers

Dimension	Weight	0 points	full score
Inventory and ownership	10	unknown services/owners	complete, current inventory
Data export	15	no tested full export	automated, complete, verified
Rehydration	15	export never imported	repeatable restore in the target
Logic and configuration	10	GUI only or implicit	versioned and portably documented
IAM and secrets	10	provider-bound, unresolved	target roles and rotation tested
Network and integrations	10	no dependency map	reproducible paths and cutover
Observability and operations	10	monitoring ends at the provider	SLOs, alerts, backups and runbooks in the target
Contract and fees	10	renewal/exit unknown	deadlines, waiver, support and budget confirmed
Drill and evidence	10	no test	current drill with findings closure

The scorecard is an internal management aid, not a legal or certification standard. A high score only has value if evidence is on file.

---

9. Procurement requirements for new contracts

Clarify at least the following in writing:

1. complete list of exportable data and metadata classes;
2. formats, APIs, rate limits and maximum export duration;
3. treatment of logs, audit data, attachments and backups;
4. portability of policies, functions, workflows and configuration;
5. support obligations during transition and parallel operation;
6. routine egress, exit waiver and other switching charges;
7. data retrieval and minimum retention costs;
8. access after termination and read-only period;
9. deletion date, backup retention and evidence;
10. technical contacts and escalation;
11. the option of an annual exit drill;
12. cooperation in security and reconciliation tests.

A general sentence such as “data can be exported at any time” is not sufficient. The contract and the technical annex should name object classes, formats, deadlines and responsibilities.

---

10. Visualization specification

Chart 1 - Provider Documentation Readiness

• File: data/FDR-2026-05_cloud_switching_readiness.csv
• Presentation: horizontal bars, 0–100;
• Subtitle: “Public documentation maturity, not a compliance assessment”;
• Tooltip: eight subscores.

Chart 2 - Routine egress at 1, 10 and 100 TB

• File: data/FDR-2026-05_egress_costs.csv;
• separate panels per volume or a logarithmic scale;
• zero and bundled offers with a footnote on retrieval, operations and minimum conditions;
• no mixing of USD and EUR.

Chart 3 - Exit Policy Taxonomy

• File: data/FDR-2026-05_exit_policy_matrix.csv;
• categories: metered, waiver, conditional zero, bundled;
• provider logos optional, but the textual conditions must remain accessible.

Chart 4 - Shutdown Notice and Recovery Window

• File: data/FDR-2026-05_shutdown_events.csv;
• timeline from announcement to service end and optional read-only or export phase;
• distinguish event type by color or symbol;
• do not aggregate planned sunsets with security shutdowns.

Chart 5 - Seven exit layers

• architecture diagram;
• per layer an artifact, an owner and test evidence;
• no decorative cloud graphic without informational value.

---

11. Reproducibility

Files

• data/FDR-2026-05_cloud_switching_readiness.csv
• data/FDR-2026-05_egress_costs.csv
• data/FDR-2026-05_exit_policy_matrix.csv
• data/FDR-2026-05_shutdown_events.csv

Calculation rules

1. Do not tacitly mix decimal TB and provider-side GB/GiB/TiB thresholds.
2. State currency and reference rate with a date.
3. Apply free allowances before tiers.
4. Keep requests, retrieval, storage, support, taxes and engineering separate.
5. Do not replace routine egress with a full exit program.
6. Only recalculate documentation scores if sources and rubric are archived.
7. Calculate shutdown notice as calendar days between the documented announcement and the end date.
8. Treat unknown values as not documented, not as zero.

---

12. Limitations

1. Public documentation can lag behind internal provider processes.
2. Enterprise contracts can contain better or worse conditions.
3. The documentation score measures findability and completeness, not legal compliance.
4. Egress prices depend on region, service, destination and volume.
5. Switching programs can contain eligibility and closure conditions.
6. The shutdown cases considered are a curated sample, not a population.
7. A successful export does not prove functional restoration.
8. The report does not assess cloud security, performance or overall product quality.
9. Legal classification can become more concrete through guidance, case law and contract drafting.
10. All volatile prices and programs have to be checked again before live publication.

---

13. Permissible and impermissible statements

Permissible:

“FW Delta assesses the publicly documented switching readiness of five providers; the score is not a compliance audit.”

Impermissible:

“Google Cloud is 95 percent Data Act compliant.”

Permissible:

“From 12 January 2027 the Data Act provides for the abolition of covered switching charges including the corresponding data egress fees.”

Impermissible:

“From 2027 every cloud data transfer is free.”

Permissible:

“Routine egress and a complete exit follow different pricing and process rules.”

Impermissible:

“A zero-egress provider causes no exit costs.”

---

14. Version history

• 1.0 · July 2026 · Data Act documentation score, egress costs, exit programs, shutdown cases and 180-day operating model consolidated.
• Live version open · Check law, prices, programs and provider documents again before publication.

15. Sources

1. Regulation (EU) 2023/2854 (Data Act), https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng.
2. European Commission, “Data Act explained”, https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained, accessed in July 2026.
3. European Commission, “Frequently Asked Questions – Data Act”, https://digital-strategy.ec.europa.eu/en/faqs/data-act-questions-and-answers, accessed in July 2026.
4. Google Cloud, “EU Data Act – Google Cloud Mapping”, https://cloud.google.com/security/compliance/eudataact, accessed in July 2026.
5. Google Cloud, “Data Portability”, https://cloud.google.com/terms/data-portability, accessed in July 2026.
6. Google Cloud Blog, “Eliminating data transfer fees when migrating off Google Cloud”, https://cloud.google.com/blog/products/networking/eliminating-data-transfer-fees-when-migrating-off-google-cloud, accessed in July 2026.
7. Microsoft Learn, “Exporting Customer Data and Enabling Cloud Choice”, https://learn.microsoft.com/en-us/compliance/assurance/assurance-exporting-customer-data, accessed in July 2026.
8. Microsoft Azure, “Bandwidth pricing”, https://azure.microsoft.com/en-us/pricing/details/bandwidth/, accessed in July 2026.
9. Microsoft Learn, “Data transfer fees – EU Data Act”, https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/data-transfer-fees, accessed in July 2026.
10. AWS News Blog, “Free data transfer out to internet when moving out of AWS”, https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-internet-when-moving-out-of-aws/, updated 30 September 2025, accessed in July 2026.
11. AWS, “Data transfer”, https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer, accessed in July 2026.
12. AWS, “Service Terms”, https://aws.amazon.com/service-terms/, accessed in July 2026.
13. Oracle Cloud Infrastructure, “EU Data Act”, https://docs.oracle.com/en-us/iaas/Content/General/Reference/eu-data-act.htm, accessed in July 2026.
14. Oracle, “EU Data Act Addendum”, https://www.oracle.com/contracts/docs/eu-data-act-addendum.pdf, accessed in July 2026.
15. IBM Cloud Docs, “IBM Cloud Terms of Use – EU Data Act”, https://cloud.ibm.com/docs/overview?topic=overview-terms, accessed in July 2026.
16. IBM, “Data Processing Addendum”, https://www.ibm.com/support/customer/csol/terms/?id=i126-6614, accessed in July 2026.
17. AWS, “Amazon S3 Pricing”, https://aws.amazon.com/s3/pricing/, accessed in July 2026.
18. AWS, “AWS VPN Pricing”, https://aws.amazon.com/vpn/pricing/, accessed in July 2026.
19. Google Cloud, “Cloud Storage pricing”, https://cloud.google.com/storage/pricing, accessed in July 2026.
20. Cloudflare, “R2 pricing”, last updated 28 May 2026, https://developers.cloudflare.com/r2/pricing/, accessed in July 2026.
21. Backblaze, “S3-Compatible Cloud Storage with 3x Free Egress”, https://www.backblaze.com/cloud-storage/solutions/developers, accessed in July 2026.
22. Wasabi, “Hot Cloud Storage Pricing”, https://wasabi.com/pricing, accessed in July 2026.
23. Wasabi, “Product Terms”, https://wasabi.com/product-terms, accessed in July 2026.
24. OVHcloud, “S3-compatible object storage with no egress fees”, https://www.ovhcloud.com/en/public-cloud/object-storage/, accessed in July 2026.
25. Hetzner, “Object Storage”, https://www.hetzner.com/storage/object-storage/, accessed in July 2026.
26. European Central Bank, “Euro foreign exchange reference rates”, reference rates of 28 July 2026, https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html, accessed in July 2026.
27. Google, Prepare for the future with Google Analytics 4, https://blog.google/products/marketingplatform/analytics/prepare-for-future-with-google-analytics-4/, published on 16 March 2022; accessed in July 2026.
28. Google, A message about Stadia and our long-term streaming strategy, https://blog.google/products-and-platforms/products/stadia/message-on-stadia-streaming-strategy/, published on 29 September 2022; accessed in July 2026.
29. Google Analytics Help, Google Optimize sunset, https://support.google.com/analytics/answer/12979939?hl=en, accessed in July 2026.
30. Google Workspace Updates, The next phase of digital whiteboarding, https://workspaceupdates.googleblog.com/2023/09/the-next-phase-of-digital-whiteboarding-for-google-workspace.html, published on 28 September 2023; accessed in July 2026.
31. Atlassian, New partnership with Slack, https://www.atlassian.com/blog/development/new-atlassian-slack-partnership, published on 26 July 2018; accessed in July 2026.
32. Atlassian, Slack partnership FAQ, https://www.atlassian.com/partnerships/slack/faq, accessed in July 2026.
33. Adobe, End of service for Adobe Muse, https://helpx.adobe.com/uk/muse/kb/adobe-muse-end-of-service.html, accessed in July 2026.
34. Meta, Shaping the Future of Work with Workplace, https://about.fb.com/news/2021/10/workplace-fifth-birthday/, with update of 14 May 2024; accessed in July 2026.
35. Mozilla, Update on Firefox Send and Firefox Notes, https://blog.mozilla.org/en/uncategorized/update-on-firefox-send-and-firefox-notes/, published on 17 September 2020; accessed in July 2026.
36. Firebase, Dynamic Links Deprecation FAQ, https://firebase.google.com/support/dynamic-links-faq, accessed in July 2026.
37. Google Takeout, https://takeout.google.com/, accessed in July 2026.
38. Google Analytics Help, Universal Analytics data processing and deletion, https://support.google.com/analytics/answer/11583528, accessed in July 2026.
39. Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonised rules on fair access to and use of data, EUR-Lex, https://eur-lex.europa.eu/eli/reg/2023/2854/oj, accessed in July 2026.

---

Disclosure and disclaimer

FW Delta develops and operates its own infrastructure, automation and migration architectures and can benefit commercially from corresponding projects. Public observations, calculations, scenarios and recommendations are therefore labeled separately.

This report is not legal, tax or contractual advice. For a specific switch, the scope of application of the Data Act, the contract, data classes, security requirements and actual provider conditions have to be examined individually.