A media company moves its analytics platform to Google Cloud. The migration goes well, and the team adopts many managed services along the way: BigQuery for analytics, Dataflow for pipelines, Pub/Sub for messaging, and Cloud Functions for automation. Two years later, a merger brings a new parent company with a strategic commitment to another cloud provider. Leadership asks how long it would take to move. The answer is uncomfortable. Data can be exported, but hundreds of pipelines, functions, and queries are written against Google-specific services. Nobody planned for leaving.
This scenario is becoming more relevant as switching costs change. Google Cloud offers to waive data transfer fees for customers who leave entirely, and European regulation is pushing providers to remove switching charges altogether. Those changes lower the financial barrier to exit. They do nothing about the technical barrier. Google cloud consulting partners who take reversibility seriously design for it from the first sprint, so that leaving, or moving some workloads elsewhere, remains a real option.
What Google's Exit Waiver Covers
In January 2024, Google announced it would eliminate data transfer fees for customers migrating off Google Cloud. The offer has conditions. Customers submit a formal request, complete the migration within a set window, which Google describes as 60 days, and terminate their agreement. Fees are credited once the exit is complete.
This is a meaningful step, but its scope is narrow:
- Full Exit Only: The waiver is designed for customers leaving Google
Cloud, not for those moving some workloads while keeping others.
- Fixed Window: The migration must be completed within the approved
period.
- Account Closure: The waiver applies when the customer ends its
relationship with Google Cloud.
Organizations pursuing multicloud strategies, or moving a subset of workloads, should not assume the waiver applies to them.
What the EU Data Act Changes
The European Union's Data Act sets rules to make switching between cloud providers easier. Its provisions require providers to remove commercial, contractual, technical, and organizational obstacles to switching. During a transition period, providers may charge reduced switching fees limited to their costs. From January 12, 2027, switching charges, including data egress charges, must be removed entirely.
For customers operating in the EU, this significantly lowers the financial cost of moving data between providers. It also signals a broader regulatory direction: portability and reversibility are becoming expectations, not exceptions.
Why Fees Are the Smaller Barrier
Egress fees are visible and easy to calculate. The larger barrier to switching is usually technical lock-in.
- Proprietary Services: Managed services such as BigQuery, Spanner,
Firestore, Dataflow, and Cloud Functions have unique APIs, query
dialects, and behaviors. Code written for them must often be
rewritten to run elsewhere.
- Data Formats: Data stored in proprietary internal formats may need
conversion before another platform can use it.
- Identity and Security: IAM roles, service accounts, and organization
policies are specific to each provider and must be rebuilt.
- Networking: Virtual private cloud designs, interconnects, and
firewall rules need to be recreated.
- Operational Tooling: Monitoring, logging, and deployment pipelines
tied to one provider's tools must be replaced.
- Skills: Teams trained deeply on one platform need time to learn
another.
Removing egress fees addresses none of these. A move can still take many months and cost far more in engineering effort than in data transfer. In many cases, the engineering cost of rewriting pipelines, queries, and integrations is several times larger than the data transfer bill ever was.
Reversibility as a Design Requirement
Reversibility means designing systems so that moving them, in whole or in part, is practical. It does not mean avoiding managed services or building everything to the lowest common denominator. It means making conscious choices and keeping the cost of change visible.
Portable Data Formats
Store data in open formats where practical. For analytics, open table formats such as Apache Iceberg allow data to be read by multiple engines. BigQuery supports open formats through BigLake, which lets organizations keep data in Cloud Storage while querying it with BigQuery. Regular exports of critical data in open formats provide an additional safety net.
Infrastructure as Code
Define infrastructure with tools such as Terraform or OpenTofu, which support several providers. Code-defined environments are easier to reproduce, audit, and adapt than those built by hand in a console.
Containers and Open Runtimes
Package applications in containers and run them on Kubernetes or other portable runtimes where it fits. Google Kubernetes Engine uses open Kubernetes APIs, which reduces the effort needed to run workloads on another provider's Kubernetes service.
Deliberate Use of Proprietary Services
Use proprietary services where they deliver clear value, and document each choice. For every service, record why it was chosen, what an alternative would be, and roughly what a move would involve. This turns lock-in from an accident into a known, accepted trade-off.
Abstraction Where It Pays
For critical integrations, consider thin abstraction layers that separate business logic from provider-specific APIs. Abstraction adds some complexity, so it should be used selectively for the components most likely to move.
Exit Documentation
Maintain an exit plan for major systems: what would move, in what order, with what tools, and with what estimated effort. Update it as the architecture changes.
Multicloud and Partial Moves
Full exits are rare. Partial moves are much more common: shifting one application to another provider after an acquisition, running AI workloads where specific models or accelerators are available, or placing data in a particular region for regulatory reasons. These moves usually fall outside exit waivers, so data transfer costs and technical effort both apply.
Designing for partial moves looks slightly different from designing for full exit. It focuses on clean boundaries between systems, well-documented APIs, and data sharing patterns that work across providers. Event streams, open table formats, and standard authentication methods make it easier to split workloads without breaking dependencies.
Organizations should also consider where data gravity sits. Large data sets tend to pull processing toward them, because moving data is slow and costly. Placing the primary copy of critical data in an open format, with clear rules about which systems read it, gives more freedom to move compute later.
Contract Terms That Support Exit
Technical design is only half of reversibility. Contracts should support it too. Useful terms include commitments on data return formats and timelines, assistance during transition, notice periods for service changes or retirements, and clarity on how committed spend agreements are handled if workloads move.
Review these terms with legal and procurement teams before signing multiyear commitments. Large spend commitments can create their own form of lock-in, since moving workloads may leave unused commitments that still must be paid. Aligning commitment levels with realistic usage, and negotiating flexibility where possible, keeps financial terms from undermining technical portability.
What GCP Consultants Should Deliver
GCP consultants who design for reversibility should include specific deliverables in migration and modernization projects:
- A lock-in register listing each proprietary service in use, its
purpose, alternatives, and estimated switching effort.
- Data portability standards defining which data sets use open formats
and how often critical data is exported.
- Infrastructure as code for all environments, stored in version
control.
- Container and runtime guidelines for application workloads.
- An exit plan for major systems, reviewed annually.
- Contract guidance covering exit terms, data return, and assistance
obligations.
These deliverables add modest effort to a project and can save a great deal of time and money if circumstances change, whether through a merger, a regulatory shift, or a pricing change.
Questions for a Google Cloud Migration Consultant
When selecting a google cloud migration consultant, ask:
- How do you balance the benefits of managed services against future
portability?
- Which proprietary services do you recommend, and what would it take
to move off each one?
- Do you use infrastructure as code for all environments?
- How do you handle data formats for analytics and storage?
- Will you provide a lock-in register and an exit plan?
- How do you factor the EU Data Act and provider exit policies into
your recommendations?
A consultant who can answer these clearly is thinking about the client's long-term flexibility. One who treats reversibility as unnecessary may be optimizing for the migration rather than for the client.
When Deep Integration Is the Right Choice
Reversibility has costs, and it is not always worth maximizing. Some workloads benefit so much from a provider's unique services that deep integration is the right call. BigQuery's serverless analytics, for example, can deliver capabilities that are hard to match elsewhere at the same effort.
The goal is informed choice. A google cloud solutions consultant should help the client decide, service by service, where deep integration pays off and where portability matters more. That decision should be revisited as business strategy, regulation, and technology change.
Governance Google Cloud Consulting Partners Should Set Up for Reversibility
Reversibility needs ongoing attention:
- Architecture Reviews: New services and major changes are reviewed for
lock-in impact.
- Register Updates: The lock-in register is updated whenever services
are added or removed.
- Exit Drills: Periodically test exporting critical data and rebuilding
a sample environment from code.
- Contract Reviews: Exit and data return terms are checked at each
renewal.
These practices keep the exit option real rather than theoretical. They also give leadership a factual basis for negotiating with providers, since a credible alternative strengthens any renewal discussion.
A Representative Redesign
Return to the media company. After the merger question, it engages a GCP cloud consultant to review its architecture. The review produces a lock-in register covering 40 services. For analytics, the team moves core tables to an open table format stored in Cloud Storage, still queried through BigQuery. Pipelines are gradually refactored to use a portable processing framework where practical. All infrastructure is brought under Terraform. Application services are containerized on GKE.
The company keeps using Google-specific services where they add clear value, but each is now documented with an alternative and an estimated switching effort. When leadership asks the same question a year later, the answer is a plan with a timeline rather than an unknown.
Measuring Reversibility
Useful measures include:
- Lock-In Register Completeness: The share of services documented with
alternatives
- Exit Drill Results: Time needed to export data and rebuild a test
environment
Google cloud consulting partners add lasting value when they plan for the possibility of exit before the migration begins. Google's exit waiver applies only to full account closure within a fixed window, and the EU Data Act is lowering switching fees, yet technical lock-in remains the main cost of leaving. Portable data formats, infrastructure as code, and deliberate choices about proprietary services keep options open. Professional GCP consulting services include lock-in registers and exit planning as part of migration design. During any GCP consultation, it is worth asking a simple question: if the business needed to move this workload in two years, what would it take?
