The first BigQuery table loads successfully, but the finance dashboard still reads Snowflake. A scheduled transformation writes to an old schema. An analyst can query data they should not see. A warehouse migration is incomplete when it moves rows without moving the workloads and access rules that give those rows meaning.
Plan the Snowflake to BigQuery move as several connected workstreams. Keep data movement, query translation, identity mapping and consumer cutover separately testable. The checklist below is an engineering approach for coordinating them. It does not promise a particular transfer speed, lower bill or interruption window.
Inventory the workloads, not just the tables
Record the source database and schema for each table. Add its owner, upstream writer, refresh pattern and downstream consumers. Include views, scheduled queries, transformation jobs, dashboards, exports and applications that issue SQL. A table with no dashboard can still support a business process through an overnight export.
Classify each workload as migrate, rebuild, retain or retire. Ask the business owner to approve that choice. Record which system will own writes after cutover and how current the target must be. These decisions determine whether a one-time load is sufficient or whether you need a separately verified synchronization process.
| Workstream | Required decision | Acceptance evidence |
|---|---|---|
| Table data | Transfer route and exact table scope | Counts, values and freshness reconcile |
| SQL and transformations | Translate or rewrite each workload | Business results match agreed expectations |
| Access | Map users, services and data restrictions | Allowed and denied queries behave correctly |
| Consumers | Switch connections and scheduled writers | Actual reports run against the target |
Choose the data transfer path deliberately
The BigQuery Data Transfer Service has a Snowflake connector. Its documented flow stages Snowflake data in Cloud Storage and then loads it into BigQuery. A transfer job covers tables within a single Snowflake database and schema. If your inventory spans multiple databases or schemas, plan separate jobs and reconcile the combined coverage.
Google also documents export and load pipelines using Snowflake’s COPY INTO command, object storage and BigQuery loading tools. Select a route based on the data you actually have, the access your security team permits and the transformations you need. A managed connector does not remove the need to understand staging files and failed loads.
For the connector, prepare the target dataset, staging bucket, source permissions and network configuration. Use a dedicated Snowflake migration identity with the required privileges. Keep credentials out of general job output. Check access to the staging location separately from permission to read the source tables and load the destination.
Resolve timestamp and schema exceptions before the full load
The connector’s documented Parquet path has limitations for Snowflake TIMESTAMP_TZ and TIMESTAMP_LTZ data. Google describes a CSV export through Amazon S3 and import route for affected data. Do not assume every timestamp column can move through the default path unchanged. Test the selected route before committing to it.
Write a mapping record for each column. Include source type, destination type, null handling and any transformation. Use examples that exercise precision, empty values and time boundaries. If the business expects a local calendar date, check that the migrated report preserves that date rather than merely preserving a displayed timestamp string.
Keep rejected rows visible. Record the source table, load batch and reason for each exception. Do not make a load pass by dropping inconvenient columns or coercing values without an approved mapping change. Rerun the test after a change and compare the corrected output with the source.
Translate SQL and compare its results
BigQuery Migration Service provides batch, interactive and API SQL translation options for converting Snowflake SQL to GoogleSQL. Use the option that fits your query inventory. Treat the output as code to review and test, not as proof that the workload now behaves identically.
Choose representative reporting periods and run the source and target queries against comparable data. Compare row sets, grouping behavior, totals and date boundaries. Test empty inputs and missing values. Investigate differences in business terms before deciding whether a numerical tolerance is appropriate.
Keep a query register linking each source workload to its target version, owner and test result. Include views and scheduled transformations, not just dashboard queries. A successful syntax check should not close a migration task whose report owner has not checked the resulting numbers.
Rebuild permissions around the destination
BigQuery access is integrated with Google Cloud IAM. Snowflake’s role hierarchy is not a permission map you can copy directly into IAM. Translate the intended access for people and services, then apply the relevant resource permissions and any required row or column restrictions.
Test using representative identities. Confirm that an analyst can run their approved report and cannot read restricted data through another table or view. Check service accounts used by scheduled jobs separately. A migration administrator’s successful query says little about the access ordinary users will have.
Include staging files in the review. Data can be correctly restricted in the destination while an overly broad bucket permission exposes the export. Agree on file retention, cleanup ownership and which operational logs may contain sensitive values. These checks belong in the migration acceptance criteria.
Reconcile the dataset at an agreed boundary
Compare source and target at the same logical point in time. Counts taken before a source refresh cannot be reconciled fairly with target counts taken afterward. Record the extraction boundary, completed jobs and any source changes still awaiting transfer.
Check table counts, key coverage, null patterns and business totals. Then run the important queries. If an incremental route is needed, verify its supported change behavior separately instead of treating the label as proof that every update or deletion will appear correctly. Document the reconciliation for the actual route selected.
A broader data migration plan should connect these checks to named owners. Decide who can accept an explained difference and who must stop the release when a gap remains unresolved.
Rehearse cutover and rollback
- Pause or coordinate source writers at the agreed release boundary.
- Complete the planned final transfer and reconcile target freshness.
- Switch reporting connections and scheduled transformations in a recorded order.
- Run real consumer checks with the intended user and service identities.
- Monitor failed jobs and stale reports before removing source access.
- Use the agreed rollback path if acceptance checks fail.
Rollback needs a data ownership rule. If new writes have reached the target, pointing a dashboard back at the source may not restore a consistent view. Decide how those writes will be handled and rehearse the decision before release.
How Remqa can help
Remqa supports data and application migrations with engineers who can work across transfer jobs, query conversion, validation and cutover. Bring the warehouse inventory, representative reports and the access restrictions that must survive. Scope the first workload around evidence that the team can verify before moving the rest.