A converted query can be syntactically valid and still be wrong.
That is one of the most important lessons in database migration. Different database engines may accept similar SQL while producing different results because of NULL handling, date rules, data types, rounding, sorting, or implicit conversions.
Use the following checklist before treating converted SQL as production-ready.
1. Confirm the purpose of the query
Write down what the source query is expected to accomplish.
Does it calculate revenue? Find overdue invoices? Prepare a dashboard? Update account status? The expected business result gives reviewers something concrete to protect during conversion.
2. Save a representative source result
Run the original query against data that includes normal and unusual cases.
Include:
• NULL values
• Empty strings
• Zero and negative numbers
• Boundary dates
• Duplicate records
• Large numeric values
• Non-ASCII text when relevant
Save the result so it can be compared with the target database.
3. Compare row counts
Start with the simplest signal. If the source query returns 2,410 rows and the target returns 2,397, something changed.
Different row counts often point to join behavior, filtering, NULL comparisons, date boundaries, or duplicate handling.
4. Check calculated values
Compare totals, averages, percentages, and grouped results.
Pay special attention to integer division, decimal precision, rounding, overflow, and implicit type conversion. These differences can produce small errors that become significant across large datasets.
5. Review NULL and empty-string behavior
Databases do not always treat NULL values and empty strings the same way.
Check expressions, concatenation, comparisons, aggregate functions, and conditional logic. A query may run correctly while silently excluding or changing values.
6. Test date and time logic
Date arithmetic is one of the most common migration trouble spots.
Verify:
• Added or subtracted intervals
• Time-zone handling
• Month and year boundaries
• Week numbering
• Date truncation
• Current date and current timestamp behavior
Use fixed test dates when possible so the comparison remains repeatable.
7. Confirm sorting and text comparison
Collation and case sensitivity can affect ORDER BY, equality checks, grouping, and duplicate detection.
Test text with different capitalization, accents, and whitespace when those values exist in the real dataset.
8. Inspect database-specific features
Look closely at vendor-specific functions, temporary tables, procedural SQL, dynamic SQL, JSON operations, and unusual data types.
These areas may not have a safe one-to-one translation and often require a developer or database specialist to make the final decision.
9. Review diagnostics instead of ignoring them
A warning is not necessarily a failed conversion. It is a signal that the translated SQL deserves attention.
Use diagnostics as a review queue. Resolve the highest-risk behavioral differences before spending time on cosmetic changes.
10. Test before deployment
Run converted SQL in a safe environment with representative data. Compare outputs and test dependent reports, applications, and scheduled jobs.
The final workflow should be:
Convert
Review
Compare
Test
Deploy
Conversion quality is not measured only by valid syntax. It is measured by how reliably the target SQL preserves the meaning of the source.
