Snowflake to BigQuery

Why organisations move, what makes the migration non-trivial, how Apache Iceberg fits into the decision, and a structured methodology for executing it without surprises.

Executive summary

Cloud data warehouse decisions carry long-term cost, capability, and risk implications. For organisations already invested in, or evaluating, Google Cloud Platform (GCP), a migration from Snowflake to BigQuery is frequently justified on total cost grounds - but cost alone does not make the decision straightforward.

If an organisation is committed to GCP, BigQuery is the natural home for analytical workloads - but the migration requires deliberate engineering effort, not a lift-and-shift assumption.

This paper presents the technical and operational realities of that migration in depth: the drivers behind it, the platform-level trade-offs that must be planned for, the data type and SQL dialect mechanics involved, governance and audit-retention requirements for regulated organisations, and a structured methodology for executing the migration with minimal risk.

We will not pretend BigQuery is strictly superior to Snowflake in every dimension, because it is not. What follows is the same plan we would execute ourselves: where BigQuery wins outright, where it requires deliberate engineering to match Snowflake's defaults, and what that engineering actually costs in time and risk.

The methodology in this paper is drawn directly from Google Cloud's own migration framework and validated against real-world migrations - including SmarterX's move of over 80 databases from Snowflake to BigQuery, which halved their data warehouse costs within a month of completion.

This paper is intended for technical decision-makers - architects, engineering leads, CDOs, and compliance functions - evaluating a Snowflake-to-BigQuery migration in a regulated or audit-sensitive environment. It assumes working familiarity with cloud data warehouse concepts but not detailed prior knowledge of either platform's internals.

What this paper covers

• The commercial and architectural case for moving from Snowflake to BigQuery
• A detailed, dimension-by-dimension platform comparison, current as of mid-2026
• Six specific migration challenges, with technical mechanics and concrete mitigations for each
• BigQuery's pricing models (on-demand vs. capacity-based) and how they interact with migration planning
• Governance, PII, and audit-retention requirements specific to regulated services
• A structured, source-agnostic three-phase migration methodology
• An evidence-based comparison of Apache Iceberg against BigQuery, with a clear verdict on which fits which organisation
• A full set of references to primary source documentation

Why organisations migrate from Snowflake to BigQuery

Three factors consistently appear in migrations Beyond has supported and observed across the industry. Cost dominates the initial conversation, but the more durable driver is often strategic platform alignment: an organisation that has standardised its compute, AI, and data integration stack on GCP finds maintaining a separate, parallel commercial and operational relationship with Snowflake increasingly difficult to justify over time.

2.1 Architectural philosophy

Both platforms separate storage from compute - the shared architectural foundation that made cloud data warehouses viable at scale. The difference lies in how each platform exposes that separation to users.

Snowflake exposes the separation through virtual warehouses - explicitly sized compute clusters (X-Small through 6X-Large) that the user starts, suspends, and scales. Fine-grained cost control at the cost of operational overhead: teams must right-size warehouses and manage auto-suspend thresholds.

BigQuery eliminates the operational layer entirely. Google's Dremel query engine draws from a shared multi-tenant pool of compute, automatically allocating slots to each query. Storage lives in Colossus, Google's distributed file system, in a columnar format optimised for analytical scans. The database is simply there - always on, always scaled.

Key insightBigQuery's serverless model means you pay for what you query, not for what you provision. Organisations coming from Snowflake frequently discover that workloads with irregular or unpredictable patterns become substantially cheaper on BigQuery's on-demand pricing.

2.2 Compute cost and pricing model differences

Snowflake's credit-based compute model charges for elapsed warehouse time rather than work performed. A virtual warehouse bills continuously while running, and idle compute accumulates if not actively governed. BigQuery offers two fundamentally different pricing models instead.

• Snowflake (credit-based): bills per second of warehouse uptime, billed in 60-second minimums. Idle warehouses bill continuously unless auto-suspend is configured.
• BigQuery (on-demand): bills per TiB of data scanned, independent of query duration, with a 10 MB minimum per query. A LIMIT clause does not reduce cost - only column pruning, partitioning, and clustering reduce bytes scanned.
• BigQuery (capacity / Editions): bills per slot-hour regardless of bytes scanned. Three tiers - Standard, Enterprise, Enterprise Plus - with 1- and 3-year commitments discounting ~20% and ~37-40% respectively.

The distinction sharpens for unpredictable, sporadic workloads. A status check or lightweight lookup that scans only kilobytes of data will repeatedly reset Snowflake's auto-suspend timer - keeping the warehouse running and billing at a fixed per-second rate even though the queries themselves do negligible work. BigQuery charges by volume scanned: at roughly $6.25 per TiB, a status check costs a fraction of a cent however frequently it runs.

RecommendationRun the BigQuery Migration Assessment tool to extract Snowflake's QUERY_HISTORY for a 30-day representative window during discovery, and use it to model both BigQuery pricing options before committing to either. Beginning on on-demand and migrating to capacity pricing once usage patterns stabilise is the lower-risk default path.

2.3 GCP platform alignment

BigQuery is native to GCP, sharing an IAM layer, billing project, and networking model with every other GCP service. Snowflake on GCP is capable but remains a separate vendor relationship sitting alongside GCP rather than within it.

Data in BigQuery flows directly to Vertex AI, Dataflow, and Looker - no egress billing line, no separate vendor security boundary to cross. Machine learning models can be trained and served directly from BigQuery ML without data movement, and streaming ingestion through Pub/Sub requires no additional infrastructure.

For organisations with strict access-review requirements, the single-pane-of-glass IAM model reduces compliance overhead: fewer distinct systems require independent audit and access review.

2.4 Operational simplicity

BigQuery is fully serverless - no warehouses to size, no auto-suspend windows, no concurrency limits to monitor directly. Snowflake's virtual warehouse model offers finer control at the cost of continuous active management.

• BigQuery: engineers write SQL; BigQuery allocates compute automatically per query. Lower ongoing platform management overhead.
• Snowflake: separate warehouses per workload, predictable isolation, tunable concurrency - genuine value with mature platform engineering capacity.

Platform comparison

The dimensions below summarise how Snowflake and BigQuery differ, current as of mid-2026. Both platforms evolve continuously; specific feature parity should always be re-verified against current documentation at the point of decision.

• Compute pricing - Snowflake: credit-based; virtual warehouses bill continuously while running. BigQuery: on-demand (per TiB scanned) or capacity-based (per slot-hour) via Editions.
• GCP integration - Snowflake: available on GCP as a first-party service, but a separate vendor relationship. BigQuery: native; shares IAM, billing project, and networking with all GCP services.
• Serverless - Snowflake: no - virtual warehouses require explicit sizing and suspend configuration. BigQuery: yes - fully managed; BigQuery allocates compute per query automatically.
• Partitioning - Snowflake: automatic micro-partitioning based on column statistics. BigQuery: manual - requires an explicit partition column (date/timestamp/integer range).
• Clustering - Snowflake: optional explicit clustering via CLUSTER BY; Automatic Clustering available as a paid add-on. BigQuery: manual - up to four clustering columns; sorts storage blocks for pruning.
• Time travel - Snowflake: up to 90 days on Enterprise and above tiers. BigQuery: up to 7 days, configurable 2 to 7 days, plus a non-configurable 7-day fail-safe period.
• Semi-structured data - Snowflake: VARIANT, ARRAY, OBJECT types, native JSON path querying. BigQuery: native JSON type and STRUCT/ARRAY; VARIANT requires explicit conversion.
• SQL dialect - Snowflake: Snowflake SQL with proprietary extensions (e.g. FLATTEN, QUALIFY). BigQuery: GoogleSQL - ANSI-based, with documented translation guidance for Snowflake syntax.
• Governance / PII - Snowflake: row-level security, dynamic data masking, native to the platform. BigQuery: Cloud DLP, row-level security, column-level security via policy tags, VPC Service Controls.
• Multi-cloud - Snowflake: AWS, Azure, and GCP. BigQuery: GCP only (BigQuery Omni provides limited cross-cloud query federation).
• AI / ML integration - Snowflake: Cortex AI, Cortex Analyst. BigQuery: Vertex AI, BigQuery ML, Gemini in BigQuery.

A note on Apache Iceberg

Organisations evaluating Snowflake-to-BigQuery migrations frequently ask a related question: should we move to an open table format like Apache Iceberg instead of, or alongside, a managed warehouse? This question has changed materially over the past two years and deserves direct treatment, because most existing commentary frames it as a binary choice that no longer reflects how the platforms actually work.

As of 2026, BigQuery natively supports Iceberg as a storage format through Lakehouse for Apache Iceberg (formerly BigLake) - BigQuery can create, manage, and query Iceberg tables directly, with Google handling compaction, clustering, garbage collection, and metadata refresh automatically. This means "Iceberg vs BigQuery" is no longer a clean either/or: the real decision is between three distinct options, not two.

• BigQuery native tables: Google's proprietary storage format, fully managed. Best suited for single-cloud GCP organisations with no requirement for other engines to read the same data.
• BigQuery-managed Iceberg: open Iceberg format, but Google handles all table maintenance. Best suited for multi-engine interoperability (Spark, Trino, Flink alongside BigQuery) without taking on operational burden.
• Self-managed Iceberg: open Iceberg format with your own catalog (Polaris, Nessie, Glue) and your own compaction jobs. Best suited for genuine multi-cloud requirements, or Iceberg features BigQuery's catalog does not yet support.

Where the evidence points

Performance - Google's internal TPC-DS 10T benchmark reports that BigQuery's advanced runtime delivers roughly 2x faster query performance on Iceberg tables compared with a self-managed approach, and that automated table management alone improved the same benchmark by approximately 40%. This is a vendor-reported internal benchmark, not an independently audited one, so the precise magnitude should be treated with appropriate scepticism - but the direction of the finding (automated table maintenance outperforms unmanaged Iceberg) is consistent with every independent source reviewed for this paper.

Operational overhead - This is the dimension on which the evidence is most consistent and least disputed. Self-managed Iceberg requires active maintenance - compaction, snapshot expiration, and manifest management - or performance degrades and storage costs increase over time. Independent technical commentary is blunt about this: metadata bloat and the small-files problem are standard operational realities, not edge cases, for any team running Iceberg without a managed maintenance layer.

Multi-engine interoperability - This is Iceberg's clearest and most durable advantage, and it is not marketing - the table format question in the wider industry is now considered settled, with Snowflake, Databricks, AWS, Google, and Microsoft all reading and writing Iceberg natively, and open-source engines treating it as the default. If multiple engines genuinely need to operate on one physical copy of the data - for example, a data science team on Spark and a BI team on BigQuery, both against the same tables - Iceberg is the only architecture that avoids duplicating the data between systems.

Feature parity gaps - Externally-managed Iceberg tables (written by Spark, Trino, etc.) do not support materialised views, CDC-style updates, or BigQuery's native time travel - though FOR SYSTEM_TIME AS OF works via Iceberg's own snapshot history, dependent on your retention policy. Row-level security, column-level security, and data masking are all supported on Iceberg external tables. BigQuery-managed Iceberg tables additionally support native time travel and high-throughput streaming via the Storage Write API, but row-level security is not supported on managed tables.

Verdict: which is right for which organisation

There is no universal winner. The right choice depends on one variable above all others: how many engines need to read or write the same data, and whether GCP is the only platform in scope.

• Single-cloud on GCP, no other engines: use BigQuery native tables. Full feature parity (time travel, row-level security, materialised views), the lowest operational burden, and automatic table maintenance.
• Genuine multi-engine requirement, GCP-centric: use BigQuery-managed Iceberg tables, not self-managed Iceberg. This is the option that did not meaningfully exist two years ago - it gives Iceberg's openness and multi-engine interoperability while Google handles compaction, clustering, and garbage collection.
• Genuine multi-cloud, or specific unsupported Iceberg features: self-managed Iceberg (an independent catalog such as Polaris or Nessie, with your own compaction jobs) is the weakest default for most organisations and should be reserved for cases where data must genuinely live outside GCP, and only where a data platform team is large enough to own metastore and compaction operations as a sustained engineering responsibility.

Quick self-assessment for the BigQuery / Iceberg decision

• Do you need Spark, Trino, or Flink to read the same tables as BigQuery? → BigQuery-managed Iceberg
• Is your data genuinely required to live outside GCP (multi-cloud)? → Self-managed Iceberg
• Do you have a team comfortable tuning Spark jobs and JVM memory? → Self-managed Iceberg is viable
• Do you need time travel, row-level security, or materialised views on externally-written tables? → BigQuery native tables
• Is GCP your only platform with no near-term multi-cloud plan? → BigQuery native tables

Migration challenges: a technical deep dive

Snowflake-to-BigQuery is, in relative terms, one of the more tractable data warehouse migrations available - both platforms share a SQL-first model, columnar storage, and broadly similar relational semantics. What makes the migration non-trivial is the accumulation of differences across six specific technical dimensions.

4.1 SQL dialect translation

BigQuery uses GoogleSQL, which is broadly ANSI-compliant but differs from Snowflake SQL in specific, well-documented ways. Google publishes an official Snowflake SQL translation guide covering these differences in detail. Key areas requiring rewrite:

• Semi-structured data access: FLATTEN and the colon (:) path operator for VARIANT traversal have no direct equivalent - requires restructuring around UNNEST and JSON path functions.
• QUALIFY clause: QUALIFY is natively supported in GoogleSQL, so no translation is required.
• Stored procedures: Snowflake procedures are JavaScript, called with CALL. BigQuery procedures are SQL blocks (or remote functions via Cloud Run) - a genuine rewrite, not a syntax translation.
• UDF management: ALTER FUNCTION, DESCRIBE FUNCTION, and SHOW USER FUNCTIONS have no direct equivalent; workflows built around these need redesigning.
• Zero-copy cloning: BigQuery supports table clones via CREATE TABLE CLONE, which is a lightweight, writable copy of a base table. Only storage that differs from the base table is charged.
• File metadata on ingestion: Snowflake's COPY command captures ingestion time and filename automatically. BigQuery load jobs do not - pipelines relying on this metadata need extra columns or a separate tracking table.

Common syntax differences requiring manual review, Snowflake → BigQuery:

• Identifier quoting: "my_table" → `my_table`
• Date functions: DATEADD(day, 1, col) → DATE_ADD(col, INTERVAL 1 DAY)
• String functions: REGEXP_SUBSTR(str, pat) → REGEXP_EXTRACT(str, pat)
• QUALIFY clause: QUALIFY ROW_NUMBER() OVER (...) = 1 → use a subquery with WHERE on row_num
• Semi-structured access: col:field::STRING → JSON_VALUE(col, '$.field')
• Zero-copy cloning: CREATE TABLE t CLONE s → CREATE TABLE CLONE (native support)
• Time travel: AT (OFFSET => -3600) → FOR SYSTEM_TIME AS OF via table snapshots
• Stored procedures: JavaScript handler → SQL or remote function (Cloud Run)

Google provides a batch SQL translator (for bulk migration) and an interactive translator (for ad hoc queries), both supporting Snowflake SQL with Gemini-enhanced assistance. For most standard DML - SELECT, INSERT, UPDATE, DELETE, MERGE, window functions, CTEs - the automated translation rate is typically 70-90%. The residual cases requiring manual attention are concentrated in JavaScript stored procedures and functions with no direct BigQuery equivalent.

MitigationRun all existing SQL through Google's batch SQL translator during Phase 1 discovery, then triage the output into three effort tiers - low (minor syntax substitution), medium (function rewrites), and high (architectural changes such as stored procedure replacement). Sequence migration waves to tackle low-complexity tables first.

4.2 Data type mapping

Snowflake and BigQuery share most standard SQL data types, but naming differences require attention, particularly for numeric precision and timestamp timezone handling. Common scalar mappings, Snowflake → BigQuery:

• VARCHAR / TEXT → STRING (no length restriction in BigQuery)
• NUMBER / NUMERIC → NUMERIC / BIGNUMERIC (check precision ≥38 digits → BIGNUMERIC)
• INTEGER / INT → INT64 (auto-mapped by the BDTS connector)
• FLOAT / DOUBLE → FLOAT64 (auto-mapped by the BDTS connector)
• BOOLEAN → BOOL (identical semantics)
• DATE → DATE (identical semantics)
• TIMESTAMP_NTZ → DATETIME (no timezone; maps to DATETIME)
• TIMESTAMP_TZ → TIMESTAMP (timezone-aware; maps to TIMESTAMP)

Semi-structured types require a more deliberate decision per column. Snowflake's VARIANT type stores semi-structured JSON data in a flexible, hierarchical, validated format:

• VARIANT (regular structure) → STRUCT: strongly typed, more queryable. Comparisons ignore key names - value vs. value only.
• VARIANT (dynamic structure) → JSON: preserves flexibility; some query-performance cost vs. STRUCT.
• OBJECT → STRUCT or JSON: Snowflake OBJECT comparisons check both key and value - literal translation to STRUCT can silently change comparison results.
• ARRAY → ARRAY: cannot be exported as plain CSV from BigQuery - JSON export only, field order not guaranteed.

MitigationDuring discovery, run a schema audit specifically targeting VARIANT, ARRAY, and OBJECT columns. For each, determine whether the underlying structure is regular (favouring STRUCT) or genuinely dynamic (favouring JSON). Document the decision and the equality-comparison risk in a type-mapping registry before any data movement begins.

4.3 Partition and cluster design

Snowflake's micro-partitioning is automatic - the platform organises data into contiguous units based on column statistics with no user configuration required. BigQuery's partitioning and clustering are explicit, must be designed deliberately, and carry specific operational constraints:

• Partition column: a single DATE, TIMESTAMP, DATETIME, or INTEGER range column, fixed at table-creation time.
• Clustering: up to 4 columns; sorts storage blocks for pruning. Benefits tables/partitions larger than 64 MB only.
• Column order: BigQuery sorts by the first clustering column, then the second, etc. - filtering only on later columns gives a smaller pruning benefit.
• Repartitioning: not supported in place. Requires creating a new table and copying data - the single most common source of unplanned rework.
• Recommender: analyses up to 30 days of BigQuery query logs post-migration - useful for validation, not a substitute for upfront design.

MitigationFor every fact table, identify the partition column during Phase 1 discovery by analysing actual Snowflake query filter patterns. Enforce partition filter requirements at the dataset level using BigQuery's require_partition_filter table option before granting analyst query access.

4.4 Time travel and audit continuity

Snowflake Enterprise and above tiers provide time travel retention of up to 90 days, configurable per object. BigQuery's window is materially shorter and cannot be extended past a hard ceiling - a significant planning gap for regulated organisations.

• Snowflake time travel: up to 90 days on Enterprise and above, configurable per object.
• BigQuery time travel: 7 days by default, configurable down to a minimum of 2 days. Cannot be extended beyond 7 days under any configuration.
• BigQuery fail-safe: an additional 7 days after time travel expires. Not queryable directly - recovery requires a Google Cloud Customer Care support ticket, no public SLA.
• Effective recovery window: up to 14 days under default config (7-day default + 7-day fail-safe), but only the time travel portion is configurable.
• Storage billing: physical storage model - both time travel and fail-safe billed at active rates, a frequent cost surprise immediately after large deletions.

MitigationBigQuery table snapshots provide longer-term, lower-cost point-in-time recovery beyond the time travel window and do not expire automatically. Implement a scheduled snapshot policy (daily or weekly, retained per the organisation's regulatory audit look-back period) before cutover, and route any longer-term archival requirement through a dedicated GCS export pipeline.

4.5 Performance validation

BigQuery's Dremel-based execution engine is architected for large-scale parallel aggregation over well-partitioned, well-clustered tables. Snowflake's virtual warehouse model offers more predictable per-query isolation, since each warehouse is a dedicated compute cluster rather than a shared resource pool. Query patterns that performed well on Snowflake do not automatically perform equivalently on BigQuery without partition and cluster design tuned to those same patterns.

MitigationCapture baseline P50 and P95 latency for the organisation's most business-critical query patterns against Snowflake before migration. After migrating each dataset, run the equivalent queries against BigQuery during a minimum two-week parallel-run period and benchmark against the baseline before decommissioning the Snowflake source.

4.6 Governance and access control migration

Security in BigQuery is governed by Google Cloud IAM, which defines which principals - user accounts, service accounts, or groups - may perform which operations on which resources. This contrasts structurally with Snowflake's role-based access control (RBAC), where roles are granted to users and can be hierarchically composed. Common privilege mappings, Snowflake → BigQuery IAM:

• USAGE on warehouse → roles/bigquery.jobUser (project level)
• USAGE on database → roles/bigquery.dataViewer (dataset level)
• SELECT on table → roles/bigquery.dataViewer (table level)
• INSERT / UPDATE / DELETE → roles/bigquery.dataEditor (table level)
• CREATE TABLE → roles/bigquery.dataEditor (dataset level)
• ACCOUNTADMIN → roles/bigquery.admin (project level)
• Row access policy (RLS) → row-level security via authorised views or row access policies
• Column masking policy → policy tags with data masking in BigQuery

Beyond the coarse-grained privilege mapping above, several governance primitives require deliberate re-implementation:

• Row-level security: implemented in BigQuery via authorised views or, for simpler cases, row access policies.
• Column-level security: uses policy tags managed through Data Catalog taxonomies, which can trigger masking transforms for principals without the DATA_MASKED_READER role.
• PII detection: Sensitive Data Protection (formerly Cloud DLP) provides 100+ built-in infoType detectors that scan BigQuery tables and can automatically tag columns containing detected sensitive data.
• Network perimeter: VPC Service Controls (VPC-SC) provide an IAM-independent network perimeter, commonly required in regulated environments. Enforcing VPC-SC for policy tags and column-level security specifically requires restricting additional APIs beyond BigQuery itself.

MitigationTreat governance configuration as a Phase 2 deliverable with the same priority as data movement, not a Phase 3 afterthought. Audit both your Snowflake row access policies and column masking policies during the assessment phase, run a Sensitive Data Protection discovery scan before granting any analyst access, and verify the VPC Service Controls perimeter explicitly covers the Data Catalog and DLP APIs alongside BigQuery.

BigQuery pricing models: choosing and planning

Pricing model selection is consequential enough to merit separate treatment from the broader cost discussion. BigQuery's pricing is genuinely bimodal, and making no deliberate choice - defaulting to on-demand indefinitely as volume grows - is one of the most common sources of post-migration cost surprise.

• On-demand: fixed rate per TiB scanned, a few dollars per TiB depending on region. Principal risk: a single exploratory query against an unpartitioned multi-TB table can generate a disproportionate charge; risk scales with query-access headcount.
• Capacity (Editions): baseline plus maximum slots purchased; billed per slot-hour regardless of bytes scanned. Principal risk: committed baseline bills whether used or not - over-provisioning wastes spend, under-provisioning queues queries.
• Autoscaling nuance: scaled capacity is retained for a 60-second minimum scale-down window, in increments of 50 slots. A 5-second job can still bill the full 60-second minimum - observed to inflate bills 50%+ in poorly tuned reservations.

A practical decision framework

• Monthly scan volume: under ~400 TB/month with evenly distributed load, on-demand is typically cheaper. Above that with consistent patterns, capacity pricing tends to win.
• Workload shape: bursty workloads (e.g. nightly batch) favour capacity pricing with autoscaling tuned to the burst; steady, low-volume workloads favour on-demand.
• Feature requirements: on-demand maintains feature parity with Enterprise Plus except continuous queries and managed disaster recovery.
• Predictability of baseline spend: a reliable minimum monthly spend floor, identified from Snowflake query history, is a strong candidate for a committed capacity reservation.

RecommendationBegin on-demand for the first 60-90 days post-cutover while genuine BigQuery-native usage patterns establish themselves, then re-run the comparison using actual BigQuery INFORMATION_SCHEMA.JOBS billing data rather than projected Snowflake-derived estimates before committing to a capacity reservation.

Migration methodology

A Snowflake-to-BigQuery migration in a regulated services context is a structured data engineering programme, not a lift-and-shift exercise. The methodology below reflects the approach Beyond applies on engagements of this type, organised into three phases. The structure itself is source-agnostic - the same three-phase shape applies whether the source platform is Snowflake, Redshift, or a legacy on-premises warehouse.

Phase 1 - Discovery and schema analysis

Comprehensive technical auditing of the legacy architecture must precede any physical data relocation. This discovery phase culminates in a centralised migration registry - a prioritised, dependency-mapped inventory of database objects augmented with architectural complexity ratings, destination schema definitions, and a structural SQL refactoring backlog.

• Comprehensive estate inventory: catalog every source virtual warehouse, database instance, schema, relational table, logical view, stored procedure, user-defined function, and outbound data-sharing construct.
• Telemetry and workload profiling: export at least a thirty-day window of historical query logs to ascertain empirical consumption and data-access trends, specifically isolating columns utilised within evaluation filter predicates.
• Automated assessment execution: run the BigQuery Migration Assessment tool across the legacy environment to generate an operational footprint analysis and a strategic migration blueprint.
• Dialect translation triaging: process the entire corpus of active SQL scripts through the batch translation engine, segmenting results by conversion predictability metrics.
• Semi-structured data mapping: conduct an exhaustive structural audit targeting all semi-structured data elements; construct a specialised type-mapping registry.
• Physical layout optimisation: define explicit table partition criteria and multi-column clustering keys for each transactional fact entity.
• Security and role virtualisation: review existing granular security configurations, including row access constraints and column-level masking logic.
• Commercial model optimisation: conduct parallel financial modelling of destination compute structures using the compiled historical workload telemetry as the evaluation baseline.
• Operational baseline benchmarks: establish quantitative success thresholds prior to initiating initial deployment cycles.

Phase 2 - Schema translation and pipeline migration

Once the discovery deliverables are finalised, this engineering phase moves into physical schema deployment, data ingestion, and refactoring the underlying code pipelines.

• Target schema instantiation: enforce the type-mapping taxonomy established during discovery when creating destination tables, converting legacy Snowflake VARIANT objects into explicitly typed STRUCT or native JSON structures immediately upon creation.
• Physical layout design: embed explicit partition and clustering rules at table initialisation. Because BigQuery lacks support for in-place restructuring of existing tables, executing this layout accurately upfront prevents expensive, disruptive data re-engineering downstream.
• Managed ingestion pipelines: execute core schema replication and bulk historical loading via the managed Snowflake connector within the BigQuery Data Transfer Service. This infrastructure provisions extraction agents on Google Kubernetes Engine, staging assets inside a project-specific Cloud Storage container before executing native ingestion into target tables.
• Network and credential hardening: inject the designated egress IP allocations for the BigQuery Data Transfer Service into the source environment network policies prior to connector configuration.
• Dialect refactoring backlog: translate code components flagged for manual code modification during discovery, focusing efforts on refactoring proprietary JavaScript stored procedures and sophisticated nested traversal logic.
• Transformation layer modernisation: rebuild active data transformation workflows; adopting Dataform provides a native, serverless framework well-suited to replace legacy dbt architectures.
• Granular access controls: incorporate row-level restrictions through authorised views or specialised query policies, alongside column-level masking driven by Data Catalog policy tags.
• Perimeter and privacy enforcement: initiate an automated Sensitive Data Protection profiling run across all replicated datasets to dynamically discover sensitive attributes.
• Cost optimisation boundaries: enforce mandatory partition constraints using the require_partition_filter directive across high-volume fact entities before granting consumer query privileges.

Phase 3 - Validation and cutover

Operating within regulated environments demands exhaustive data verification prior to live deployment. Compressing this timeline to meet artificial project deadlines introduces substantial risk - resolving data discrepancies post-migration incurs far greater operational and financial costs.

• Execute dual-platform processing for no less than fourteen days on core analytical datasets. This entails running simultaneous validation checks - including total record counts, cryptographic or numerical checksums, and complex business logic assessments - across both environments.
• Evaluate the performance profiles by measuring median (P50) and tail-end (P95) query response times within the new destination, measured against the initial benchmarks established in the discovery phase.
• Conduct targeted audits of compliance and statutory reporting deliverables. Because oversight bodies permit zero deviation, these critical data products demand exhaustive validation and must serve as the final gateway for migration sign-off.
• Implement an automated strategy utilising table snapshots or persistent Cloud Storage archives configured to span the necessary institutional retention windows.
• Maintain the legacy data warehouse in an unmodifiable, read-only state for at least one month following decommissioning. This operational buffer provides an essential fallback mechanism for addressing unforeseen telemetry issues or data discrepancies that emerge in production.
• Schedule the final environment transition during off-peak hours to minimise disruption. Ensure that a comprehensive, fully verified regression and fallback playbook is thoroughly documented and simulated well in advance.

Where to begin

If you are mapping this paper against your current environment, the gaps that matter most to close first are:

• Type-mapping registry, before any data moves: audit VARIANT, ARRAY, and OBJECT columns now, while schema design is still malleable. Retrofitting type decisions after data has landed is materially more expensive than deciding upfront.
• Partition design, before table creation: BigQuery cannot repartition a table in place. Get the partition and cluster columns right at creation, grounded in actual Snowflake query patterns.
• Governance configuration, before analyst access: run a Sensitive Data Protection discovery scan and apply policy tags before any PII-bearing dataset is opened up. This is a Phase 2 deliverable, not Phase 3 clean-up.
• Audit retention bridge, before cutover: BigQuery's 7-day time travel window will not, on its own, satisfy most audit look-back requirements. Stand up the GCS snapshot or archival pipeline before it's needed, not after an auditor asks for data that has already expired.
• Pricing model decision, after 60-90 days of real usage: do not commit to a capacity reservation on projected Snowflake-derived estimates. Begin on-demand, then re-run the comparison against actual BigQuery billing data.

The organisations that get the most value from this migration are not the ones that move fastest. They are the ones that treat discovery as a genuine engineering phase - with a migration registry, a type-mapping decision per column, and a partition design grounded in real query patterns - rather than a formality to clear before the data movement begins.

About Beyond

Beyond is a global technology group, headquartered in London, backed by Marlin Equity Partners. It deploys experts and frontier technology, including AI, to help organisations thrive through change. With over 600 professionals - more than 75% hands-on technical talent - across Europe, North America, and Asia, Beyond combines the scale of a global delivery organisation with the technical depth of a specialist practice.

Beyond is a Google Cloud Premier Partner and Google Cloud Global Strategic Cyber Security Partner, with deep specialisation in data platform architecture, migration engineering, and AI enablement. Our practitioners bring more than fifteen years of experience building and operating production systems for some of the world's most demanding regulated institutions, including HSBC, Deutsche Bank, Lloyds Banking Group, and Santander.

• Methodology-led, not platform-evangelist: the three-phase structure in this paper is deliberately source-agnostic - the discipline of discovery, type-mapping, partition design, and staged validation transfers across source platforms.
• Hands-on Snowflake architecture experience combined with a track record supporting regulated services migrations.
• PII classification, audit trail continuity, and compliance sign-off treated as first-class programme requirements, not post-migration clean-up.
• We assess every migration on its merits and tell clients directly when the answer is not to migrate.

Beyond works with organisations at every stage of this journey - from initial assessment and planning through execution, validation, and post-migration optimisation. If you are evaluating a Snowflake-to-BigQuery transition, we are glad to provide an independent readiness assessment grounded in your actual query patterns and schema.

Get in touch: hello@beyond.com · beyond.com

References

All sources below were accessed in June 2026. Cloud platform documentation is updated frequently - figures and capabilities should be re-verified against current documentation at the point of decision.

Snowflake documentation

• Time Travel — Snowflake Inc. — docs.snowflake.com/en/user-guide/data-time-travel
• Semi-structured data types — Snowflake Inc. — docs.snowflake.com/en/sql-reference/data-types-semistructured
• Querying semi-structured data — Snowflake Inc. — docs.snowflake.com/en/user-guide/querying-semistructured
• Understanding micro-partitions and data clustering — Snowflake Inc. — docs.snowflake.com/en/user-guide/tables-clustering-micropartitions
• SnowConvert AI: BigQuery data type mapping — Snowflake Inc. — docs.snowflake.com/en/migrations/snowconvert-ai/bigquery/general/data-types

Google Cloud / BigQuery documentation

• BigQuery pricing — Google Cloud — cloud.google.com/bigquery/pricing
• Data retention with time travel and fail-safe — Google Cloud — cloud.google.com/bigquery/docs/time-travel
• Understand BigQuery editions — Google Cloud — cloud.google.com/bigquery/docs/editions-intro
• Introduction to partitioned tables — Google Cloud — cloud.google.com/bigquery/docs/partitioned-tables
• Introduction to clustered tables — Google Cloud — cloud.google.com/bigquery/docs/clustered-tables
• Snowflake SQL translation guide — Google Cloud — cloud.google.com/bigquery/docs/migration/snowflake-sql
• Snowflake to BigQuery migration overview — Google Cloud — cloud.google.com/bigquery/docs/migration/snowflake-overview
• Migration assessment — Google Cloud — cloud.google.com/bigquery/docs/migration-assessment
• Schedule a Snowflake transfer — Google Cloud — cloud.google.com/bigquery/docs/snowflake-transfer
• Understand slots — Google Cloud — cloud.google.com/bigquery/docs/slots
• Using Sensitive Data Protection with BigQuery — Google Cloud — cloud.google.com/bigquery/docs/scan-with-dlp
• Restrict access with column-level access control — Google Cloud — cloud.google.com/bigquery/docs/column-level-security-intro
• VPC Service Controls for BigQuery — Google Cloud — cloud.google.com/bigquery/docs/vpc-sc
• Apache Iceberg managed tables — Google Cloud — cloud.google.com/bigquery/docs/iceberg-tables

Google Cloud Blog

• SmarterX: migrating to BigQuery from Snowflake cut costs in half — Google Cloud Blog — cloud.google.com/blog/topics/partners/smarterx-migrates-from-snowflake-to-bigquery
• Separation of storage and compute in BigQuery — Google Cloud Blog — cloud.google.com/blog/products/bigquery/separation-of-storage-and-compute-in-bigquery
• Improved interoperability for your Apache Iceberg lakehouse — Google Cloud Blog — cloud.google.com/blog/products/data-analytics/improved-interoperability-for-your-apache-iceberg-lakehouse
• Classifying and tagging PII fields residing in BigQuery — Google Cloud Blog — cloud.google.com/blog/products/identity-security/how-to-classify-and-tag-pii-data-in-bigquery