FDE Times: SnowConvert moved your Oracle/Teradata SQL to Snowflake — what an FDE still has to check
A 6 November FDE Times guide argues that a clean SnowConvert deploy only proves syntax. FDEs must catch semantic traps (Oracle empty-string=NULL, Teradata case-insensitive GROUP BY, lenient casts) and validate schema, metrics, then row-level hashes before cutover.
After SnowConvert AI converts a customer’s Oracle or Teradata estate, scripts can deploy cleanly while the numbers are still wrong. FDE Times frames the FDE’s job as proving semantic equivalence with data before the old system is switched off.
The tool’s EWI/FDM list is only a map. Oracle treats empty strings as NULL; Snowflake does not — and REPLACE/CONCAT with '' are deliberately left alone. Teradata is lenient on string-to-number casts and case-insensitive GROUP BY by default, so a city report can split ‘Ha Noi’ and ‘HA NOI’ after migration while table totals still match.
Validation should climb Snowflake’s three levels: schema, aggregate metrics (default tolerance 0.001 — confirm with the customer for money columns), then row-level primary-key + MD5 checks for tables that feed finance or regulatory reports. Matching row counts alone prove nothing.
For FDEs on Snowflake migrations, the CV-worthy story is which tables you validated, which semantic gaps you found, and how you fixed them — not how many lines the converter moved.
Source: fdetimes.net