How to evaluate a data warehouse migration tool: eight proof requests and a scoring sheet

Because most tools give a good demo, and far fewer can prove a full estate. The cost of a warehouse migration is set by its logic, not its data.

Stored procedures, ETL packages, scripts and job schedules are the hard part. Data migration is solved. Logic migration is not.

That logic is old and thinly documented. Much of it was written by people who have left, and it is trusted because it has always run. In a 2020 McKinsey survey, 60% of CIOs felt their tech debt had risen perceptibly over three years. The same research put tech debt at 20 to 40% of the value of the entire technology estate, before depreciation.

Generative AI made conversion quicker and made the proof problem worse. The question has moved from "can we convert it" to "can we prove it". This guide gives you a way to ask that of any vendor, including us.

A word on where I sit. I run Novuz, which sells deterministic conversion software. I have written this to be useful even if you choose another approach. Where another approach is the better fit, I say so plainly.

There are four broad approaches, and each is the right answer for some estates. They differ most on two things: whether the output repeats, and what evidence you get per object. The table compares them by category, not by vendor.

Two cautions before you read it. The categories blur: an SI may use a code assistant, and some converters have model-driven modes. The run-it-twice test in this guide applies to all of them. Treat each row as a starting point for questions, not a verdict.

• Manual or SI-led rewrite: engineers rewrite and test the logic by hand, usually run as a program by a systems integrator.
• AI code assistants: your team, or a vendor, feeds the old code to a language model and edits what comes back.
• Platform-native converters: tools from the target platform that translate SQL into that platform's dialect.
• Deterministic conversion software: fixed, versioned rules convert each object, so the same input gives the same output.

Each approach wins on a different kind of estate, so start from yours. Size, audit pressure, the mix of ETL and SQL, and how much you plan to redesign matter more than any feature list.

Two of these are often combined well. Many teams run a platform-native converter first and bring the remainder to a conversion vendor. Many SIs keep the program and run the conversion on software, including ours.

• Choose an SI-led rewrite when the work is mostly re-architecture rather than conversion, or you want one party for program and change management. A twelve-month, seven-figure quote is honest arithmetic for that method.
• Choose AI code assistants for a few hundred objects with an engineer who will own every line. They also suit greenfield work where the old logic is being redesigned anyway.
• Choose a platform-native converter when the estate is mostly SQL and views, the target is decided, and you have engineers to test. For that estate it may be all you need.
• Choose deterministic conversion software for large estates with ETL packages and scripted control flow. It also fits when an auditor will ask for evidence per object.

They are eight artifacts you ask every vendor to produce, us included. Ask for the artifact, not the answer. A vendor who cannot produce one has told you what you need to know.

These are the tests an auditor would apply to a code conversion. We can supply each one from the assessment or the First Domain. We fail some buyers' tests too: we do not convert Oracle, mainframe, Informatica or DataStage, and we say so first.

1. A two-run diff: the same object converted twice, with the diff of the outputs.
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.
4. The dead-code list from your own estate.
5. The guarantee clause: contract language, not a slide.
6. A deployment diagram showing where code and reports live at each stage.
7. The engineer-approval log for every step that is not rule-based.
8. The escrow and ownership clauses.

Ask the vendor to convert one source object twice and send you both outputs with the diff. If the diff is empty, you are looking at a rule. If it is not, you are looking at a generation step, and you will review every line.

This matters because proof depends on repeatability. Our CTO, Ted Ghose, puts it this way: "If a conversion gives a different answer each run, you cannot prove it. Auditors do not accept probabilities." Our diff is empty.

• Good answer: two output files, an empty diff, and the rule version that produced them.
• Weak answer: an explanation instead of files, or "the outputs are functionally the same".

Ask for one paragraph that states the counting rule before you look at any percentage. A rate means nothing until you know what was counted. What buyers ask us most is the percentage; ask for the rule first.

Ours: an object counts as automated only if it needs no manual edit. A one-line fix counts as manual, and dead code is excluded from the denominator. Under that rule, delivered estates typically see 95% or more of objects converted with no manual edit. That is the automation rate, not the rule share.

• Good answer: a written rule that names the unit (objects, not lines), how a small edit is counted, and how dead code is treated.
• Weak answer: an "up to" figure with no rule, a count of lines rather than objects, or dead code left in the denominator to lift the rate.

Ask for the full report on one object you choose, not one the vendor chooses. Pick the procedure you trust least. A vendor's chosen example tells you what they are proud of, not what you will get.

A real report runs the original and converted logic on the same inputs. It compares schema, row counts and column-level values, and marks the object pass, fail or review. Ours does this for every object, and the report names the misses. Reconciliation is above 95% on first pass, typically.

• Good answer: a per-object report with the inputs stated, the checks listed, and the misses named, exportable as audit evidence.
• Weak answer: a dashboard of green ticks, a vendor-chosen object, or "tested" with no inputs shown.

Ask for a list of dead code from your own estate, with the evidence for each item. It is the only proof request that uses your code rather than a demo. That is why we start every engagement with an assessment.

Dead code matters twice. Converting it wastes money, and counting it can flatter an automation rate. A good vendor recommends retiring it, not converting it.

• Good answer: a named list with the evidence (no caller, no schedule, no reads) and a recommendation to retire.
• Weak answer: no list, or a plan to convert and bill everything in the inventory.

Ask for the guarantee clause as contract text, not a slide. It should name the threshold, the objects and inputs it covers, the cure period, the exclusions and the remedy. A vendor who bills hours cannot carry a fee remedy, and that is a fair limit of the model, not a flaw in the people.

Ours is the equivalence guarantee in Part C of the First Domain charter. The charter states a reconciliation threshold, 95% by default, for the agreed objects on the agreed inputs. Miss it at the readout, after the cure period and exclusions, and the fee is waived or credited in full. It is in writing before work starts.

• Good answer: clause text with a number, a scope, a cure period and a remedy you can enforce.
• Weak answer: "best efforts", a satisfaction promise with no threshold, or a remedy that is only more hours.

Ask for a deployment diagram that shows where source code, converted code and reports live at every stage. It should mark what crosses your network boundary and which model, if any, sees which fragment. The first question every security team asks us is where the code goes.

Ours runs as a container or VM in your cloud or data center, air-gapped if you choose. No outbound connection is required. If you choose a hosted model for the resolver, only the edge-case fragments go to it, under your own agreement.

• Good answer: a diagram per stage, with the boundary drawn and every crossing labelled.
• Weak answer: a marketing architecture picture with no boundary, or reassurance in place of a drawing.

Ask for the engineer-approval log. For any output that was not produced by a rule, it should show a named engineer reviewing and approving it before it entered the build. "Human in the loop" is a claim; the log is the evidence.

In our case the log covers the resolver's share. About 95% of objects convert by fixed rules (the rule share). The rest, typically around 5%, go to a resolver on a model you approve, and your engineer approves every proposal. Nothing deploys unapproved.

• Good answer: a log with object, proposal, approver name, date and decision, kept in your environment.
• Weak answer: review by an unnamed team, or approval recorded only as a status flag.

Ask to see the ownership and escrow clauses in the contract. You want to own converted code, reports and logs on the day they are produced. You also want to know what still works if the vendor disappears.

With us, converted code, reports and logs are yours from the moment they are produced. The output is native code with no Novuz runtime, so it runs whether we do. Escrow of the conversion software and rules is offered in the First Domain charter. Score the mitigations, not the headcount.

• Good answer: ownership from production, native output with no vendor runtime, and escrow with stated release events.
• Weak answer: output that needs the vendor's runtime or license to run, or ownership only on final payment.

Weight evidence and coverage most, because they decide whether the program finishes. Adjust the weights to your estate, then publish them to every vendor before any demo. A sheet written after the demos tends to favor the best presenter.

Score each criterion from 0 to 5, multiply by the weight, and divide the total by five. A perfect vendor scores 100. Ask for the artifact behind every score above 3.

Use your code, your inputs and your counting rule, and give every vendor the same box. A bake-off on a vendor's sample estate tests the vendor's preparation, not your estate. Keep it to two or three weeks so it does not become a project of its own.

1. Write your counting rule and scoring weights first, and send them to every vendor on the same day.
2. Choose 10 to 20 objects yourself, starting with the ones you trust least. Include a long procedure, an ETL package, a scripted job and its schedule.
3. Freeze one input dataset and give the same copy to every vendor.
4. Ask each vendor to convert every object twice and return both outputs.
5. Run original and converted logic on the frozen inputs, or check each vendor's report against one object you rerun yourself.
6. Count under your own rule. Log every manual edit, including one-line fixes.
7. Record where the code went at each stage and who approved each non-rule output.
8. Ask each vendor for a fixed price for the full estate and the date it holds until.

A fixed price set after the vendor has read the whole estate protects you best. Any price quoted before that is an estimate. Each model below is honest for some work, so match it to yours.

Our ladder runs from a free scorecard to a $3,000 assessment in three business days, credited in full. Next is a First Domain at $25,000 to $40,000, also credited, then a fixed price for the full estate. On delivered estates we are about 40% cheaper than an SI-led rewrite, at a fixed price set before work starts.

We do not quote a percentage against AI tools, because there is no completed-migration baseline to compare with. The honest contrast is a fixed price against open-ended token spend.

Ask where code and data sit at every stage, and who or what can reach them. Most risk in a conversion sits in the answers to those two questions. The questions below work for any approach.

• Where does the software run, and who hosts it?
• What leaves our environment during the assessment, and during conversion?
• Which model sees our code, under whose agreement, and in which region?
• How do vendor staff get access, through whose identity provider, and how do we revoke it?
• Where are actions logged, including calls from scripts, pipelines or agents?
• How long does the vendor keep any code we share, and how is deletion confirmed?
• Which certifications does the vendor hold today, and which are only planned?

By running inside your environment by default. The software runs as a container or VM in your cloud account or data center, so residency follows your environment. Access is through your identity provider, and every action is logged there, whether the caller is a person, a pipeline or an agent.

The resolver runs on a model you approve: Claude, Gemini, or a local model through Ollama. If you choose a hosted model, only the edge-case fragments go to it, under your own agreement. An agent reaches only what you expose, under your access, approvals and audit logging.

For the assessment, you can share DDL and procedure code under NDA. We use it only to produce the report and delete it 30 days after delivery unless you ask otherwise. Security-first buyers can instead run a discovery container inside their network and send only the report.

Novuz holds no SOC 2 or ISO certification today; a SOC 2 Type I is planned. The software runs inside your existing security boundary and controls. In-environment deployment is the default, not a condition. A customer who prefers not to host it gets the same engine, proof and price.

Several kinds of buyer should not, and saying so early saves everyone time. If one of these describes you, another approach is likely the better fit.

• Estates under about 300 objects. A free converter or a hand rewrite is usually cheaper.
• Oracle-only or mainframe estates. We do not convert them. Informatica, DataStage, Netezza and Redshift are also not covered today.
• Teams with no target and no date inside 18 months. Decide the target first.
• Buyers who want staff augmentation rather than software. An SI is the right partner for that.
• Organizations that cannot run software inside their environment or share code for an assessment.

Every item below should have an artifact behind it before you sign. If a vendor cannot produce one, mark it as a gap rather than a promise.

• Our counting rule and scoring weights were sent to every vendor before demos.
• We hold a two-run diff for at least one object from each vendor.
• We hold a reconciliation report for an object we chose.
• We have a dead-code list from our own estate, with evidence.
• Coverage is confirmed for our sources, ETL packages, scripts and schedules.
• We have a deployment diagram with the network boundary drawn.
• We know which model sees which code, under whose agreement.
• We hold the guarantee clause as contract text, with threshold and remedy.
• We hold the ownership and escrow clauses, reviewed by counsel.
• We have seen an engineer-approval log format.
• We have a fixed price for the full estate and the date it holds until.
• We know who runs the program, who runs the conversion, and who approves.

Get a count of your own estate before you compare prices. Our logic debt scorecard is free and takes ten minutes. The estate assessment counts and bands every object, lists dead code, confirms coverage and fixes a price in three business days.

On estates of 1,000 to 1,600 objects, delivery typically takes 4 to 8 weeks from kickoff to reconciled output. Whatever you choose, ask every vendor for the eight artifacts. Find out what your logic debt is costing you.