Converting the code: the real cost of a non-Oracle source
For Teradata, Netezza, SQL Server or Db2, the project lives or dies on the logic, not the data.
For a Teradata, Netezza, SQL Server or Db2 source, the data movement is the well-understood part. The project lives or dies on the logic.
A mature reporting platform on any of these carries a substantial body of platform-specific code: BTEQ and macros, T-SQL procedures, dialect-specific analytic SQL, platform-specific loading utilities, and a scheduling layer that encodes years of undocumented dependency knowledge. None of it moves. All of it has to be converted, re-implemented or retired.
Some hard-won observations:
Inventory the code before you estimate anything. Not the object count — the line count, the dependency depth and the proportion that is genuinely in use. Estimates built on table counts are systematically wrong for heterogeneous migrations because the effort does not correlate with data volume at all.
Automated conversion gets you a first draft, not a result. Conversion tooling handles the mechanical dialect differences well and the semantic differences badly. The residue — the things that ran correctly on the source for reasons nobody documented — is where the time goes. Plan for conversion output to be reviewed, not accepted.
Watch for behaviour that was never specified. Implicit type conversion, null ordering in sorts, empty-string-versus-null semantics, date arithmetic at boundaries, division-by-zero handling, and the collation and case-sensitivity rules of the source. Each of these differs between platforms, none of them appears in any specification, and all of them will change a number in a report that someone reconciles monthly.
Retire aggressively. A significant proportion of the code on a decade-old platform produces output that nobody reads. Converting it is pure waste. Use finding out what nobody uses to find it.
The scheduler is a dependency graph, and it is probably the only surviving documentation of how the platform works. Extract it, read it and preserve it, whatever else you convert.
I would treat code conversion as the critical path on any heterogeneous migration and staff it accordingly, ahead of the data movement workstream.