Zero-Copy Cloud is Not the End of Lock-In. It is the Start of a New One
SAP and Google Cloud have made data migration quietly optional. The data stays put. The operating judgment built above it does not. That is the lock-in the architecture diagram will never show.
Article record
Why it matters
What this means for organisations holding critical data
SAP and Google Cloud have made data migration quietly optional. The data stays put. The operating judgment built above it does not. That is the lock-in the architecture diagram will never show.
Opinion, by Mark Fermor, Director and Co-Founder, Firevault.
Cloud migrations used to announce themselves. Program offices, weekend cutovers, reconciliation meetings and invoices heavy enough to develop their own weather systems. Everyone knew a strategic commitment was being made because hundreds of people had been hired to make it.
On 27 July 2026, SAP and Google Cloud made SAP Business Data Cloud Connect for BigQuery generally available. The service creates a bidirectional, zero-copy connection between SAP and Google. SAP tables, metadata and business semantics can be read inside BigQuery without a second physical copy. Gemini can be grounded on live SAP context. Agents can coordinate across Gemini Enterprise and SAP Joule. No extraction pipeline. No parallel warehouse. No three-year migration ending in a dashboard that looks suspiciously like the old one.
It sounds like an escape from cloud lock-in. It is not. It moves the lock-in somewhere the architecture diagram will never show.
The Data Stays. The Judgment Moves.
Read the vendor story carefully. SAP remains the system of record. BigQuery becomes the analytical layer above it. Agents interpret the combined context and act across both. The data does not move.
What moves is the accumulated answer to a much more consequential question: under these circumstances, what is this company willing to authorise?
That answer starts small. Read inventory. Detect a supplier risk. Recommend an alternative. Then it meets the company. Preferred-supplier agreements. Regional approval limits. Material substitutions. Sanctions controls. Freight constraints. Plant-specific tolerances. The executive who suspends normal policy when a production line is six hours from stopping.
Every encounter changes the system. A new instruction is added. A tool is connected. An exception is given a route. A threshold is tuned because the original setting escalated everything, or worse, almost nothing. Over months, the company's executable judgment is distributed across agent instructions, semantic mappings, approval policies, identity controls, evaluation data, workflow state, production traces and exception history. All of it sits inside a specific vendor's execution environment.
The database can remain exactly where it was. The company's operating judgment cannot.
Where the Firevault View Fits
Firevault has said for two years that data sovereignty is not a storage feature. It is an operating posture. Layer 1 Offline Secure Storage exists so that the material that would end a business is not reachable through any always-on API, management port or agentic workflow. That view now needs a companion argument, because the vendors have absorbed the "leave the data alone" line and turned it into a marketing benefit.
The new question for a UK board is not "who holds our data". The answer to that question is increasingly "we do, and it does not move". The new question is "who holds the executable version of our judgment". Because if the answer is Google, or SAP, or any single hyperscaler-tied agent runtime, then the exit conversation is far harder than any historical data-migration was. Data has schemas. Judgment has scars.
Five Questions Before Signing
- Portability of judgment, not data. Can you export the agent instructions, evaluation cases, exception routes and approval policies in a form another runtime can execute, or only the raw prompts?
- Exit demonstration. Before a workflow becomes production-critical, insist on a documented replay of the same decision on a second runtime. If the vendor cannot do it in a pilot, they will not do it in a divorce.
- Identity and approval control. Who owns the identity graph the agents use to act? If it is the vendor, the vendor owns the approvals, not you.
- Sovereign copy of the decision record. Every agent action should write to a store you control. Not "you have access to". Control. Offline where the stakes justify it.
- The line the agent will not cross. Which decisions must remain human, in your building, with your people? Write that list before the vendor's onboarding team writes it for you.
The Line That Matters
Zero-copy is a genuine engineering advance. It removes a category of pain that the industry has tolerated for a decade. It does not remove the strategic question. It sharpens it.
If the data no longer needs to move, the argument for keeping the most consequential decisions, and the most consequential data, inside your own control gets stronger, not weaker. The right pattern is emerging in outline: sovereign, offline custody of the material that must survive any vendor, coupled with disciplined portability of the operating judgment built above it. That is the posture Firevault was designed for. It is also, in our view, the posture every serious UK board should be asking their CIO to defend by the end of this year.
The database can stay where it is. Make sure the judgment can leave.
Source: The AI Decision Brief, "Google Doesn't Need to Move Your Data Anymore", 28 July 2026.
How Firevault would handle this
Physical disconnection removes the path an attacker needs
Offline Secure Storage® holds a clean copy of your data on hardware that is physically disconnected, so an intrusion cannot reach it, encrypt it or delete it.






