Workload

SQL / query migration

Workload scope

SQL query migration covers dialect conversion, semantic preservation, query validation, and target-native rewrites for analytical workloads and downstream reporting logic.

Shared migration method

Classify SQL by business criticality and conversion risk before translating it. Preserve intent, not syntax: null behaviour, type coercion, date and timezone boundaries, ordering and ties, joins, aggregation grain, and side effects must be explicit. Build a traceable mapping from each source query to its target rewrite, test data, acceptance threshold, and reviewer.

Use golden queries and representative edge cohorts to prove semantics. Optimise only after the semantic contract passes; performance rewrites must be checked against the same accepted output.

Conversion controls

  • Flag dialect functions, implicit casts, positional references, and non-deterministic ordering for review.
  • Define the expected result grain and tie-breaking rule for ranking and window operations.
  • Test null, empty, timezone, boundary-date, duplicate, and malformed-value cohorts deliberately.
  • Maintain an exception queue for unsupported or intentionally changed behaviour rather than masking differences.

When to use a pair-specific guide

Use a retained pair-specific page where the named source has constructs that change the conversion decision, such as Oracle date semantics, Snowflake semi-structured functions, or a source-specific analytical dialect. The shared guide is the canonical conversion discipline.

Review points

  • Function, operator, and dialect differences
  • NULL, type coercion, and timestamp semantics
  • Window ordering, dedupe, and top-N stability
  • Golden-query parity and edge-cohort diffs

Acceptance criteria

A sql / query migration page is complete when the migration team can identify source assets, understand conversion assumptions, review unsupported or ambiguous constructs, run validation checks, and decide whether the workload is ready for cutover.

For each related path, confirm that the child page explains what changes, how conversion works, which patterns are supported, what can drift, and which evidence is required before production traffic moves to the target platform.

Related migration paths

  1. Databricks to BigQuery /migrations/databricks-to-bigquery/sql-query-migration
  2. Databricks to Snowflake /migrations/databricks-to-snowflake/sql-query-migration
  3. Hadoop (legacy clusters) to BigQuery /migrations/hadoop-legacy-cluster-to-bigquery/sql-query-migration
  4. Hive to BigQuery /migrations/hive-to-bigquery/sql-query-migration
  5. Impala to BigQuery /migrations/impala-to-bigquery/sql-query-migration
  6. Impala to Snowflake /migrations/impala-to-snowflake/sql-query-migration
  7. Oracle to BigQuery /migrations/oracle-to-bigquery/sql-query-migration
  8. Redshift to BigQuery /migrations/redshift-to-bigquery/sql-query-migration
  9. Redshift to Snowflake /migrations/redshift-to-snowflake/sql-query-migration
  10. Snowflake to BigQuery /migrations/snowflake-to-bigquery/sql-query-migration
  11. Spark SQL to BigQuery /migrations/spark-sql-to-bigquery/sql-query-migration
  12. Teradata to BigQuery /migrations/teradata-to-bigquery/sql-query-migration
  13. Teradata to Snowflake /migrations/teradata-to-snowflake/sql-query-migration