---
title: "SQL / query migration"
description: "SQL / query migration"
canonical: https://www.smartmigrate.ai/workloads/sql-query-migration
htmlPath: /workloads/sql-query-migration
markdownPath: /workloads/sql-query-migration.md
schema: Service
updatedAt: 2026-02-11T00:00:00.000Z
---
# SQL / query migration
SQL / query migration
Canonical: https://www.smartmigrate.ai/workloads/sql-query-migration
Public path: /workloads/sql-query-migration
Markdown resource: /workloads/sql-query-migration.md
## 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.

<!-- Related paths are generated from the remaining published, pair-specific guides. -->

<!--

## Related migration paths

- [Databricks to BigQuery](/migrations/databricks-to-bigquery/sql-query-migration) - Convert Databricks SQL to BigQuery with parity for MERGE, windows, NULL/type coercion, and time semantics, with validation gates and pruning-aware rewrites.
- [Databricks to Snowflake](/migrations/databricks-to-snowflake/sql-query-migration) - Convert Databricks SQL (Spark SQL) to Snowflake SQL with parity for MERGE, window logic, null/type behavior, and timezone handling, with validation gates.
- [Hadoop legacy cluster to BigQuery](/migrations/hadoop-legacy-cluster-to-bigquery/sql-query-migration) - Convert Hive/Impala/Spark SQL from Hadoop to BigQuery Standard SQL with parity for partitions, windows, NULL coercion, and time semantics with KPI gates.
- [Hive to BigQuery](/migrations/hive-to-bigquery/sql-query-migration) - Convert HiveQL to BigQuery with parity for partition pruning, window functions, NULL/type coercion, and time semantics, with golden-query validation.
- [Impala to BigQuery](/migrations/impala-to-bigquery/sql-query-migration) - Convert Impala SQL to BigQuery Standard SQL with parity for partitioning, NULL/type behavior, windows, and Hive idioms, with validation gates and pruning.
- [Impala to Snowflake](/migrations/impala-to-snowflake/sql-query-migration) - Convert Impala SQL to Snowflake SQL with parity for partition filtering, window functions, NULL/type behavior, and golden-query validation without credit spike.
- [Netezza to BigQuery](/migrations/netezza-to-bigquery/sql-query-migration) - Convert Netezza SQL to BigQuery with parity for window functions, NULL/type coercion, and time semantics, with golden-query validation and pruning rewrites.
- [Oracle to BigQuery](/migrations/oracle-to-bigquery/sql-query-migration) - Convert Oracle SQL to BigQuery Standard SQL with parity for analytics, date/time semantics, NULL behavior, and Oracle constructs with validation gates.
- [Redshift to BigQuery](/migrations/redshift-to-bigquery/sql-query-migration) - Convert Redshift SQL to BigQuery Standard SQL with parity for windows, date/time semantics, NULL/type coercion, and UPSERT patterns, validated with drift gates.
- [Redshift to Snowflake](/migrations/redshift-to-snowflake/sql-query-migration) - Convert Redshift SQL to Snowflake SQL with parity for window functions, NULL/type coercion, date/time semantics, and MERGE patterns with golden-query checks.
- [Snowflake to BigQuery](/migrations/snowflake-to-bigquery/sql-query-migration) - Convert Snowflake SQL to BigQuery with semantic parity for QUALIFY, JSON handling, timezones, and MERGE patterns.
- [Spark SQL to BigQuery](/migrations/spark-sql-to-bigquery/sql-query-migration) - Convert Spark SQL to BigQuery Standard SQL with parity for window functions, NULL/type coercion, arrays/structs, and time semantics with validation gates.
- [Teradata to BigQuery](/migrations/teradata-to-bigquery/sql-query-migration) - Convert Teradata SQL to BigQuery Standard SQL with parity for QUALIFY, date/time semantics, analytics, and joins, with validation gates and safe rewrites.
- [Teradata to Snowflake](/migrations/teradata-to-snowflake/sql-query-migration) - Convert Teradata SQL to Snowflake SQL with parity for QUALIFY, window functions, NULL/type coercion, date/time semantics, and golden-query validation.
- [Vertica to BigQuery](/migrations/vertica-to-bigquery/sql-query-migration) - Convert Vertica SQL to BigQuery with parity for windows, NULL/type coercion, and date/time semantics, with golden-query validation and pruning-aware rewrites.

-->

## 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.

<!-- Source: Git-managed MDX content derived from migrated Sanity workload metadata and migration workload child pages. -->
Intent: