Google Doesn’t Need to Move Your Data Anymore
Zero-copy solves the old migration problem. It does not solve the new question of who owns the operating judgment built above the data.
Cloud migrations used to announce themselves.
They arrived with program offices, extraction plans, reconciliation meetings, weekend cutovers, and invoices large 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.
Google has found a quieter route.
Leave the data alone.
On July 27, SAP and Google Cloud made SAP Business Data Cloud Connect for BigQuery generally available. The service creates a bidirectional, zero-copy connection between SAP Business Data Cloud and Google’s data and AI environment.
Companies can expose SAP tables, metadata, and business semantics inside BigQuery without building another physical copy of the underlying data. They can combine that information with outside datasets, use it to ground Gemini, and coordinate agent workflows across Gemini Enterprise and SAP Joule.
SAP remains the operational system of record. BigQuery becomes the analytical environment above it. Agents interpret the combined context and act across both platforms.
No heroic extraction pipeline. No parallel warehouse containing a slightly different version of the truth. No three-year migration program culminating in a dashboard that looks suspiciously like the old dashboard.
It sounds like an escape from cloud lock-in.
It may simply move the lock-in somewhere harder to see.
The Data Stays. The Judgment Moves.
Google and SAP describe one of the intended uses of the architecture as proactive supplier-risk management.
A company could combine live SAP procurement and inventory records with external information about shipping delays, geopolitical disruption, weather, commodity markets, or supplier distress. An agent could identify a developing shortage, rank alternative suppliers, and initiate the contingency workflow before a factory runs out of material.
That is where the architecture stops being an interesting data connection and starts becoming an operating system for decisions.
At first, the workflow looks simple. Read the inventory position. Detect the risk. Recommend another supplier.
Then it meets the company.
It discovers preferred-supplier agreements, regional approval limits, material substitutions, sanctions controls, freight constraints, plant-specific tolerances, quality holds, disputed lead times, and the executive who will suspend 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 receives a route. An evaluation case is created after a failure. A threshold is adjusted because the original setting escalated everything or, worse, almost nothing.
The purchase orders remain inside SAP.
What moves into the execution environment is the accumulated answer to a more consequential question:
Under these circumstances, what is this company willing to authorize?
That answer will eventually be distributed across agent instructions, semantic mappings, approval policies, identity controls, evaluation data, workflow state, production traces, and exception history.
The database can remain exactly where it was.
The company’s executable judgment cannot.
Below the paywall, I examine five questions enterprise buyers should ask before treating zero-copy as an exit from lock-in:
What happens to the data migration services business when the data no longer needs to move?
How does execution lock-in accumulate without appearing on an architecture diagram or migration budget?
Why can an exportable agent still be nearly impossible to replace in production?
Where does the strongest case for the SAP-Google architecture hold, and where does it stop?
What exit demonstration should buyers require before an agentic workflow becomes too important to move?
The data may remain portable. The operating judgment built above it may not.
