Every IT decision-maker running analytics on Redshift, BigQuery, or Azure Synapse has a version of the same conversation: what would it actually cost us to leave? The honest answer is rarely comfortable. Cloud vendor lock-in in BI is not primarily a contractual problem. It is an architectural one, built into query engines, storage formats, and data gravity, and the bill only becomes visible when leaving is no longer optional.
With worldwide public cloud spending at $679 billion in 2024, the hyperscalers have had every incentive to deepen that gravity. The question for your infrastructure team is not whether lock-in exists, but whether your current architecture gives you a realistic exit path, and at what cost.
The format problem nobody puts in the sales deck
BigQuery stores its native tables in Capacitor, Google’s proprietary columnar format. You do not get direct access to those files. Exporting to Parquet, the format you would need to move anywhere else, requires an explicit export job with egress fees on top. Redshift couples compute and storage tightly within AWS, and while its SQL dialect is PostgreSQL-derived, it diverges enough on window functions and data types that a direct port to another warehouse is rarely clean. Azure Synapse decouples compute and storage and integrates deeply into the Azure ecosystem, which is a genuine architectural advantage inside Azure and a meaningful dependency outside it.
Data migration is actually the easier part of a business intelligence migration strategy. The harder work is rewriting SQL dialect differences, particularly around date functions, array handling, and STRUCT types; migrating stored procedures and UDFs; updating ETL pipelines; and reconfiguring access controls. None of that appears on a cost calculator.
What egress actually costs
The so-called “exit tax” on cloud data is real, though the picture shifted in 2024. AWS charges approximately $0.09/GB for the first 10 TB of egress, Azure approximately $0.087/GB, and GCP’s Premium Tier sits at $0.12/GB. Across a large analytics estate, egress fees routinely account for 6 to 12 percent of total cloud bills. Synchronising data across providers compounds this: you pay egress on both sides of every transfer, which makes multi-cloud architectures economically unworkable without deliberate design that keeps inter-provider data flows minimal.
In January 2024, GCP announced it would waive egress fees for customers migrating off its platform entirely. AWS and Azure followed within two months. The caveats matter: Azure requires cancellation of all subscriptions, and AWS excludes services like CloudFront and Direct Connect. Routine operational egress, serving data to users from the cloud day to day, is not abolished. The waiver addresses switching, not ongoing traffic costs. It is a welcome signal, but it does not eliminate the format rewrite, the pipeline rework, or the downtime risk.
What the EU Data Act actually changes
Regulation (EU) 2023/2854, the EU Data Act, entered into force on 11 January 2024 and applies from 12 September 2025. Chapter VI is specifically designed to counteract lock-in in data processing services, covering IaaS, SaaS, PaaS, and edge computing. It requires providers to remove obstacles to effective switching, including commercial, contractual, technical, and organisational hurdles, with egress fees explicitly in scope.
The Act introduces a graduated abolition of switching fees. From the date of entry into force until 12 January 2027, switching fees may still be charged but must be limited to actual direct costs and disclosed before any agreement is signed. From 12 January 2027, charging switching fees is completely forbidden. Providers must also supply customers with detailed information on switching and porting procedures and maintain an up-to-date register of data structures, formats, and interoperability specifications.
Portability on paper is not portability in practice. The Data Act can mandate the removal of fee barriers; it cannot mandate that your SQL dialects align, your UDFs translate cleanly, or your ETL pipelines survive the crossing.
Enforcement rests with competent supervisory authorities under Article 40, not with individual business customers. Member States are required to set penalty frameworks by 12 September 2025, but confirmed figures for specific jurisdictions are not yet available. The regulation is a meaningful shift in the legal landscape, but it does not replace the technical work of building a portable BI stack cloud portability requires.
Open table formats as the practical hedge
The most durable answer to cloud vendor lock-in in BI is architectural, not contractual. Open table formats, specifically Apache Iceberg, Delta Lake, and Apache Hudi, add ACID transactions, schema evolution, and time travel on top of Parquet, enabling portable lakehouse architectures that are not owned by any single vendor. Gartner rated open table formats such as Apache Iceberg as having “Transformational” benefit in its 2025 Hype Cycle for Data Management, the highest impact rating the firm assigns.
Iceberg is now read and written by Spark, Flink, Trino, Presto, and Hive. AWS Athena and Glue integrate with it; Snowflake integrates with it. In 2024, Databricks acquired Tabular, founded by Iceberg’s original creators, and introduced interoperability features across Iceberg, Delta Lake, and Hudi. The industry has converged on open formats as a de facto interchange layer. If your data warehouse strategy does not include a plan for how your data lands in an open format at rest, you are building in the next generation of lock-in.
What a portable data warehouse architecture actually looks like
A genuinely portable architecture separates storage from compute, stores data in open formats on object storage you control, and treats the query engine as a replaceable layer. That means using Iceberg or Delta Lake on object storage rather than native warehouse tables where possible, keeping transformation logic in engine-agnostic SQL or in a framework like dbt that targets multiple backends, and validating your egress path before you need it rather than after.
The region where your data physically lives also carries legal weight. For analytics tables that may hold personal data, the warehouse region determines your GDPR exposure. That is not a compliance footnote; it is an architectural constraint that should inform where you land your data at rest.
We operate DIVERSITY’s analytics infrastructure under Tier III standards, ISO 27001 certification, and a contractual 99.9% uptime SLA across carrier-neutral facilities. Sovereignty here is not a marketing line; it is a contract-level guarantee, auditable and enforceable under European law, not subject to foreign jurisdiction. When customers use our infrastructure as a landing zone for a BI stack migration, they are not trading one set of proprietary dependencies for another. They are landing on open-format object storage, with direct peering to the hyperscalers they are moving away from, which means the data transfer path is predictable and the architecture they build on top of it belongs to them.
Stress-testing portability before it becomes a crisis
The practical test is not theoretical. Take one major reporting pipeline and map every dependency: the SQL dialect features it uses, the UDFs it calls, the ETL jobs that feed it, the access controls that gate it. Then estimate what it would cost in engineering time and egress fees to move that pipeline to a different query engine on neutral object storage. If you cannot answer that question for your most critical pipeline, you do not yet have a portable data warehouse architecture; you have a migration risk that has not been priced.
The hyperscalers have built excellent products. The question is whether the exit from those products, if it ever becomes necessary, is a planned operation or an emergency. Building on open formats, separating storage from compute, and validating your egress path on neutral infrastructure is how you keep that choice yours.
