A Migration Framework, Not a Marketing Pitch
Databricks published a BigQuery migration framework on August 6, 2026. It covers the full arc: estate assessment, entry-point selection, phased wave execution, dual-operation bridging, SQL logic conversion, and governance mapping. Data platform owners and analytics leaders running mature BigQuery estates now have a sequenced, opinionated playbook to evaluate.
The framework covers Process, Technology, and People. The Process and Technology pillars drive the architecture and operating decisions most teams need to make first.
Why BigQuery Becomes a Problem at Scale
BigQuery is a fast start for analytics. The problems tend to surface later. On-demand pricing and slot reservations create a tension between performance and budget that grows harder to manage as workloads expand. Governance across ETL, storage, business intelligence (BI), and AI models fragments across separate tools. Varying on-demand costs and slot reservations force a trade-off between performance and budget that is difficult to resolve without rearchitecting.
Databricks argues that consolidating ETL, storage, BI, and multi-model AI into a single open Lakehouse eliminates that fragmentation and delivers predictable performance at scale.
Start With an Assessment, Not a Migration
The framework is explicit: assessment comes before everything else. Profile the BigQuery estate first — datasets, query history, and slot consumption — to find which workloads drive cost, which dashboards are actually used, and which tables are never queried. Lakebridge, the open-source Databricks Labs migration toolkit, includes a BigQuery profiler that automates this discovery. Migration waves get planned around what is actually used, not what merely exists.
The estate profile determines the entry point.
BI-First or ETL-First: The Entry Point Decision
Two entry points cover most situations.
BI-first suits an analytics leader whose dashboards are slow or capped by concurrency limits. Rebuild the most-used dashboards on Databricks while reading BigQuery data in place initially. Switch teams over one use case at a time, proving parity side by side. The payoff is visible quickly: faster dashboards and natural-language Q&A with Genie. The trade-off is that backend costs keep running until pipelines follow.
ETL-first suits a data platform owner watching pipeline costs climb and batch windows slip. Offload heavy processing to the Photon/Spark engine to stabilize the backend and create a clean foundation for AI. Business users see little change until pipelines land, so the framework recommends publishing cost and runtime wins with each wave to maintain stakeholder trust.
When the assessment is ambiguous, the signal is clear: dashboard complaints point BI-first; pipeline cost points ETL-first.
Waves, Not a Big Bang
The framework is direct about cutover risk. A big-bang cutover concentrates all the risk in a single moment. If anything breaks, trust in the whole program breaks with it.
Wave-based migration keeps the blast radius small. Rank workloads on two axes: value to the organization (visibility to leadership, revenue proximity, compliance urgency, daily user count) and migration complexity. Start where value is high and complexity is low. Each wave delivers a visible business win, reconciles before the next wave starts, and leaves the team faster for the one that follows.
Dual operation — running both platforms during a transition wave — works in both directions depending on entry point. BI-first teams use Lakehouse Federation so Databricks can read BigQuery while dashboards move first. ETL-first teams flip it: move ingestion and transformation to Databricks, land curated tables in open formats, and let BigQuery continue serving existing dashboards from that same single copy. No dual-write pipelines, no export jobs, no second copy to reconcile.
One important constraint applies to the ETL-first path. External tables served from BigQuery are read-only on BigQuery's side and carry limitations, including manual schema refresh after schema changes. Plan the cutover of the serving layer onto Databricks SQL as the closing step, not a long-term state.
SQL Logic: Three Tiers of Conversion
SQL logic migration runs across three tiers. Rule-based transpilation handles the bulk of standard SQL. The Lakebridge toolkit covers this tier. An agentic code converter handles more complex conversions using parallel AI agents. Manual refactoring handles the remainder that automated tools cannot resolve cleanly.
For teams executing a lift-and-shift first, the immediate goal is migrating existing SQL logic to Databricks SQL as-is. Once stable, high-value pipelines can be refactored into Lakeflow Spark Declarative Pipeline for automated orchestration, built-in data quality, and unified batch and streaming.
Governance: Map Permissions Before Data
Unity Catalog, Databricks' unified governance layer, maps directly to BigQuery's object hierarchy. Project maps to Catalog, Dataset maps to Schema, Table maps to Table. Fine-grained controls — row filters, column masks, and tags — replicate BigQuery's column-level security natively.
The sequencing rule from the field is firm: migrate permissions before data. Each wave's cutover changes where a table lives, not who can see it. Governance that travels with the data avoids the cost of rebuilding access controls from scratch after each wave.
Unity Catalog also treats AI models as first-class governed objects alongside tables and pipelines — a meaningful difference for teams building AI products on top of the same data platform.
What Data Platform Owners Should Do Before Moving Forward
The framework is detailed enough to use as a planning document. The practical starting point is the estate assessment.
Run the Lakebridge BigQuery profiler before any architecture decision. Identify your top cost-driving workloads, your most-used dashboards, and the tables that carry no active queries. That profile determines whether your entry point is BI-first or ETL-first, and it sizes the first migration wave before any engineering capacity is committed.
Also audit your governance model now. If BigQuery permissions are managed informally or inconsistently, migrating permissions after data moves creates a gap window. Map the permission structure first, then align it to Unity Catalog's three-tier hierarchy before the first wave executes.
Finally, confirm that any teams relying on BigQuery external tables or federated queries understand those are a transitional bridge, not a permanent architecture. Plan the cutover of the serving layer onto Databricks SQL as a defined milestone, with success criteria such as 99.9% parity to trigger decommissioning of legacy pipelines.