Data warehouse migration: the complete guide to moving legacy logic, and proving it

A migration's cost is set by how many procedures, packages, scripts and jobs the estate holds, not by its terabytes. Data migration is solved. Logic migration is not.

Most of a warehouse is logic nobody can fully explain: procedures written by people who have left, trusted because they have always run. Moving the logic means reading, converting and proving each object.

As Deb puts it, "Migration cost is set by how much logic you have, not how much data." Data volume still matters. It sets how long reconciliation takes to run. It does not set how much effort an object needs to convert.

The wider problem has been measured. In a 2020 McKinsey survey, CIOs estimated tech debt at 20 to 40 percent of the value of their technology estate before depreciation. And 60 percent said it had risen over the past three years. Gartner expects 80% of technical debt to be architectural by 2027 (Magic Quadrant for Technical Debt Management Tools, May 2026). We call the warehouse share of it logic debt.

Every unit of convertible logic, counted once, with its type, database, dependencies and schedule. The inventory is the base for the price, the plan and every percentage anyone will quote later.

We count as an object any stored procedure, function, view, trigger or SSIS package. BTEQ scripts, Hive queries and UDFs, Snowflake procedures and tasks, and job definitions count too. Tables belong on the list, but they are rarely where the effort is.

A spreadsheet built from memory is a start, not an inventory. Parse the code itself, because configuration often sits in files, the SSIS catalog and SQL Agent at once. External dependencies, such as linked servers, external schedulers and application databases, go on the list with the object that depends on them.

• Objects by type and database, each counted once
• Lineage: what each object reads from and writes to
• Jobs and schedules, with dependencies in and out of scope
• A complexity band per object
• A dead-code flag per object, with the evidence
• A coverage column: converts by rule, goes to the resolver, stays manual, or not supported

More than most teams expect. Real estates have it, and every dead object you carry over is paid for to convert and then paid for to run.

The evidence for dead code is simple: no caller, no schedule and no reads. Our counting rule removes dead objects from the denominator before any percentage is reported. They are listed separately so you can decide to retire or keep each one. Many teams find the migration is smaller than they feared once the dead code is out.

Dead by reference is not always dead. A procedure may be called from outside the warehouse, or a package run by hand. The business owner of each domain should confirm the list before cutover.

• Tables and views: drop from scope and archive the DDL
• Procedures and functions: drop from scope and confirm with the business owner
• ETL packages: drop from scope and confirm there are no manual runs
• Jobs: disable before cutover rather than delete

A band per object tells you which code converts by rule, which needs review and which needs an engineer. The split between bands sets the effort more than the total count does.

Two estates with the same count can need very different plans. Band every object before anyone prices the work.

• T-SQL to Spark SQL: collation, NULL handling and date functions differ
• Teradata: QUALIFY, SET tables, implicit casts and macros that depend on volatile tables
• Teradata load logic: FastLoad and TPT steps that sit outside the SQL
• SSIS: precedence constraints and event handlers that carry error logic

Choose with your own code, not a vendor demo. The count, the dead code and the lineage do not depend on the target, so one inventory can price more than one target.

Novuz converts to Databricks, Microsoft Fabric, Snowflake, Apache Iceberg and Delta Lake. Often the choice is already made by an enterprise agreement or a platform mandate. If it is not, convert a sample of hard objects to two targets side by side and have your engineers read the output.

The output should be native code on the target, with no vendor runtime inside it. If an agent program is under way, ask how the new pipelines will be operated. Agents can run Novuz, and agents can run what Novuz builds: the delivered pipelines can be exposed as MCP tools, under your own access, approvals and audit logging. The conversion in between stays deterministic.

Coverage matters as much as the target. Our sources are SQL Server, SSIS, Teradata including BTEQ, Hadoop (Hive and Impala) and Snowflake. Oracle, mainframe, Informatica, DataStage, Netezza and Redshift are not covered today. Coverage is confirmed per estate during the assessment.

A domain that is self-contained by lineage, with a business owner who will test. We call it the First Domain. It proves the method on your code before you commit the estate.

A domain is a set of objects that share tables and schedules, usually matching a business area. Shared objects, such as reference data, utility functions and logging, are converted first, with the First Domain. After it, the next domains move in parallel and the rest follow the lineage. An estate usually moves in two to six waves.

The First Domain takes 5 to 6 weeks. Its charter states a reconciliation threshold for the agreed objects on the agreed inputs. The default contract threshold is 95% of in-scope objects passing. Miss it at the readout, after the cure period and the charter's exclusions, and the fee is waived or credited. That is the equivalence guarantee, in writing before work starts.

1. Week 0: deploy the software in your environment and onboard your engineers
2. Weeks 1 to 2: your engineers run the conversion, with us beside them
3. Weeks 3 to 4: reconciliation and exceptions
4. Week 5: cutover rehearsal and go-live
5. Week 6: the expansion readout, with what the domain says about the rest

There are four broad ways to convert legacy logic: manual rewrite, AI code assistants, platform-native converters and deterministic software. They differ most in what they can prove.

A manual rewrite, in-house or SI-led, is slow and inconsistent. Each engineer rewrites a procedure differently. An SI-led rewrite is priced by the hour against an estimate made before anyone read the code, and that estimate moves.

AI code assistants draft a single object quickly. But they are probabilistic, so the same input can give a different output on the next run. As Ted says, "If a conversion gives a different answer each run, you cannot prove it. Auditors do not accept probabilities." They also hand back files. Deployment, orchestration and proof stay with you.

Platform-native and free converters are a good start for SQL translation to their own platform. They often stop before ETL control flow, orchestration and per-object evidence. Many teams run one first and bring us the remainder.

Deterministic software converts with fixed, versioned rules. Same code in, same code out. About 95% of objects convert by fixed rules; that is the rule share. Under our counting rule, typically 95% or more of objects need no manual edit; that is the automation rate. The rest go to a resolver on a model you approve, at 700 to 1,000 tokens per edge case. Your engineer approves every proposal. Nothing deploys unapproved.

Ask for the artifact, not the answer. A vendor who cannot produce the artifact has told you what you need to know. These eight requests apply to every vendor, including us.

1. A two-run diff: the same source object converted twice, with the diff of the outputs. Ours is empty.
2. The counting rule in writing: what counts as converted, what counts as manual, and whether dead code is in the denominator.
3. One reconciliation report, for an object you choose rather than one the vendor chooses.
4. The dead-code list from your own estate, with the evidence for each object.
5. The remedy if the threshold is missed, as contract language rather than a slide.
6. A deployment diagram showing where source code, converted code and reports live, and what crosses the network boundary.
7. The engineer-approval log for every step that is not rule-based. Ours covers the resolver's share, typically around 5% of objects.
8. The ownership and escrow clauses: who owns the output on the day it is produced, and what is held in escrow.

Run the original and the converted logic on the same inputs and compare them, object by object. A reconciliation report per object, marked pass, fail or review, is evidence an auditor can read.

The checks run in order: schema, row counts, column aggregates, sampled rows in a fixed order, then your business-logic checks written as queries. Each report can be exported per object as audit evidence. On delivered estates, reconciliation is above 95% on first pass, typically, and the report names the rest.

Know what the report proves. It shows equivalence on the tested inputs. It does not show that the original was correct. Source objects that give different answers on each run are flagged by design.

Agree the tolerances before the first run, not after the first failure. The people who hold the undocumented rules should add their checks to the reconciliation. They become approvers, not converters.

• The input snapshot, with its location and hash, used on both platforms
• Floating-point tolerance
• Ordering, with any undefined order flagged
• Date, time zone and precision
• Collation and case

Run old and new side by side one domain at a time, and cut each domain over when its objects pass. The parallel run should end on a date, not when the whole estate is done.

An estate-wide parallel run is the year nobody budgets. Every month it runs, you pay for two platforms. Reconcile per object, by domain, instead. A domain whose objects all pass can cut over on its own. The parallel run then lasts as long as the flagged objects take, not as long as the estate.

Orchestration is rebuilt on the target to the original schedule and dependencies. Production cutover stays your decision.

1. Freeze the source for the period, or notify changes in writing so changed objects are reconverted and reconciled
2. Confirm the dead-code list and disable dead jobs
3. Rehearse the cutover on the target with the rebuilt schedule
4. Clear every object marked fail or review, or record why it is accepted
5. Have the business owner sign the equivalence record
6. Cut over the domain and switch off its legacy jobs

They turn a deferred decision into a dated one. Work back from the date, and count the estate first, so you negotiate with two numbers rather than one.

For SQL Server, the dates are public. Extended support for SQL Server 2016 ended in July 2026, and Microsoft lists three years of Extended Security Updates running to July 2029. Extended support for SQL Server 2017 ends in October 2027. Security updates buy time. They do not move the logic.

A Teradata or Snowflake renewal gives you a date and a price. What you lack is the other price: what it costs to leave, fixed. With it, you can renew knowing the exit price, or move some domains first and negotiate on a smaller footprint.

A Hadoop decommission date or a Fabric mandate works the same way. The date does not move, so the plan must end before it.

On delivered estates of 1,000 to 1,600 objects, Novuz typically takes 4 to 8 weeks from kickoff to reconciled output. Moving the same logic by hand typically takes a year and a team.

Ask every vendor how they measure time. We count business days from code received to reconciled output, excluding time waiting on the customer. Hand-run timelines slip after the demo, because the demo was conversion. Nobody demos validation.

Your side sets much of the pace. Environment access, input data and a named engineer for approvals sit on the critical path. Functional testing comes on top.

Budget on objects and complexity, not hours or terabytes. A price can be fixed only after something has read the whole estate. For Novuz, that is a three-business-day assessment.

We can fix the price because the output is deterministic. The same estate gives the same result, so it can be counted and priced before work starts, with the equivalence guarantee in writing. A firm that bills hours cannot do that. At a fixed price, Novuz is about 40% cheaper than an SI-led rewrite of the same estate.

AI code assistants have no completed-migration baseline to compare against, so we give no percentage there. The honest contrast is a fixed price against open-ended token pricing. Our resolver uses 700 to 1,000 tokens per edge case on your own model, and we add no usage, token or hourly charges.

Keep a line for the work around the conversion: target design, data movement, change management and functional testing. Many teams buy those from their SI.

Most risk sits in a handful of constructs and in what a few people know but never wrote down. Name the risks for your estate before work starts, each with its response already in the plan.

Ask what still runs if the vendor disappears: native code with no vendor runtime is the answer you want. Ask too where your code goes. Novuz runs as a container or VM in your cloud or data center, with no outbound connection required. If you choose a hosted model for the resolver, only the edge-case fragments go to it, under your own agreement.

Some estates are not a fit for us. That includes estates under about 300 objects and Oracle-only or mainframe estates. It includes teams with no target and no date inside 18 months, and buyers who want staff augmentation. It also includes organizations that cannot run software in their environment or share code for an assessment.

Count, choose, prove. Read the whole estate in the first month and move one domain in the next six weeks. Then plan the rest with real numbers.

1. Week 1: name the date that drives the move and its executive owner. Take the logic debt scorecard for a first count.
2. Weeks 1 to 2: share the code for an estate assessment. The three-day clock starts when complete code arrives.
3. Weeks 2 to 3: hold the readout. Confirm the dead-code list with domain owners and agree the First Domain, threshold and inputs.
4. Weeks 3 to 5: sign the charter, provision the environment and name the engineer who approves resolver proposals.
5. Weeks 5 to 11: run the First Domain through conversion, reconciliation, exceptions and a cutover rehearsal.
6. Weeks 11 to 12: review what the domain says about the rest: constructs, bands and coverage.
7. Week 13: decide on the full estate at a fixed price, set the wave order and give the parallel run an end date.