A SQL Server to Azure SQL Database move keeps the engine family and the T-SQL. That’s the good news: unlike a move to Fabric, your column types mostly survive. It also means a failing comparison test usually points at a real problem, not a type rule.
The general migration method covers the five pieces every migration needs. This page is the Azure SQL version.
What to compare
| Check | What it catches |
|---|---|
| Row and column counts per table | Rows left behind, columns dropped |
| Null and distinct counts per column | Defaults applied, collation changes |
| Minimum, maximum, and total length | Truncated text from a narrower column |
| Sums, minimums, and maximums of numbers | Rounding, lost decimals |
| Minimum and maximum dates | Time zone shifts |
| Value hashes, with and without the key | Values changed or swapped between rows |
Row counts sit at the top of that list for a reason: they’re necessary. They just aren’t enough.
The steps with TestGen
TestGen’s Verify a Data Migration procedure, applied to Azure SQL:
- Connect to SQL Server with a read-only SQL login. In the source table group, turn on Profile for table comparison and turn off profile sampling.
- Run data profiling on the source and generate a suite with only the Table Comparison set.
- Connect to Azure SQL Database with a SQL login, managed identity, or Entra ID service principal, and add a firewall rule for the TestGen host. Create the destination suite and exclude it from quality scoring.
- If tables or columns were renamed, write the mapping CSV:
source_table,source_column,target_table,target_column. - Run
transfer_tests.pyto preview, read the report, then run it with--apply. - Run the destination suite after each load and match every failure to your expected-differences list.
TestGen never copies rows between the two. It profiles the source where it lives, queries the target where it lives, and compares results, so a failure names the column that changed. Query both sides by key to find the rows.
SQL Server details that bite
- Version. Text-hash tests need UTF-8 collations, so the source should be SQL Server 2019 or later. On older versions those tests miss text changes (migration docs).
- Collation. Case-insensitive collations, the SQL Server default, count
ACMEandacmeas one distinct value, and trailing-space variants count as one under any collation. - Reloads. A reload that regenerates surrogate keys fails every keyed hash test on that table.
- Source changes. Profile the source after the last copy. If it changes in between, the tests compare against the wrong baseline.
In DataKitchen’s testing on three public datasets, Table Comparison caught 774 of 785 planted changes. The Jaffle Shop write-up shows the 61 failures and the planned change behind each.
Start at the Azure SQL install page, and see the Azure SQL setup answer for grants and firewall rules.