The 5% problem

There are two loud positions on AI in warehouse migration. One says a language model can now rewrite your whole estate. The other says no model should ever touch production logic. Both are wrong, and the interesting engineering is in the narrow space between them.

Can a language model convert stored procedures?

Yes, often impressively. Paste a T-SQL procedure into a capable model and ask for Spark SQL, and you will usually get something plausible, idiomatic and close.

The problem is the word "usually", and the word "close". Ask again tomorrow and you may get a different, equally plausible answer. Run it against production data and it may differ from the original in the handling of a NULL, a tie in a sort, or a rounding step, none of which shows up in a code review. Across four thousand objects, "usually close" is not a migration strategy. It is a testing backlog.

Why rules beat models for most warehouse logic

At Novuz, about 95% of objects convert by fixed, versioned rules with no model calls. That figure varies by estate, which is why the assessment measures it on your code rather than quoting ours. Using a model for this part buys nothing: it is slower, it costs tokens for work a rule does for free, and it introduces variance where there was none.

What a rule-based rewrite looks like

Notice the details a rule has to get right and a reviewer can check: DATEDIFF's argument order flips between dialects; GETDATE() returns a timestamp where current_date() returns a date, which matters at midnight; rounding of halves must match. A rule encodes those decisions once and applies them identically everywhere. Then reconciliation confirms it.

-- Source: T-SQL, cursor over open invoices
DECLARE c CURSOR FOR
  SELECT invoice_id, amount, due_date FROM dbo.invoices WHERE status = 'OPEN';
OPEN c;
FETCH NEXT FROM c INTO @id, @amt, @due;
WHILE @@FETCH_STATUS = 0
BEGIN
  UPDATE dbo.invoices
     SET late_fee = CASE WHEN DATEDIFF(day, @due, GETDATE()) > 30
                         THEN ROUND(@amt * 0.015, 2) ELSE 0 END
   WHERE invoice_id = @id;
  FETCH NEXT FROM c INTO @id, @amt, @due;
END
CLOSE c; DEALLOCATE c;

-- Target: Spark SQL on Delta Lake, set-based
MERGE INTO invoices AS t
USING (
  SELECT invoice_id,
         CASE WHEN datediff(current_date(), due_date) > 30
              THEN round(amount * 0.015, 2) ELSE 0 END AS late_fee
  FROM invoices
  WHERE status = 'OPEN'
) AS s
ON t.invoice_id = s.invoice_id
WHEN MATCHED THEN UPDATE SET t.late_fee = s.late_fee;

Where rules run out

Here a language model is genuinely useful. It can read the surrounding code, infer intent, propose a notebook equivalent of a Script Task or a parameterized rewrite of dynamic SQL, and explain its reasoning.

Useful is not the same as trusted.

• Dynamic SQL assembled at run time from table contents, so the real logic does not exist until it executes.
• A C# or VB.NET Script Task inside an SSIS package that calls an external service or parses a file format.
• A cursor whose output depends on an undocumented processing order the business relies on.
• A vendor-specific function with no equivalent on the target.

How to use a model in a migration without trusting it

Treat it as a capable junior engineer who drafts and never merges.

1. It only sees what rules could not settle. The model is asked to propose a fix for one object, with the rule context and the reason the rule did not apply, not to convert the estate.
2. It runs on a model you choose. A hosted model such as Claude or Gemini under your own agreement, or a local model through Ollama with no outbound connection. Configured per estate and written into the contract.
3. It is cheap because it is narrow. Each resolution takes about 700 to 1,000 tokens, so cost is bounded by the size of the remainder, not the estate.
4. A person approves every proposal. Your engineer approves, edits or rejects it. Nothing deploys unapproved. Proposal, approver and timestamp are recorded per object.
5. The result is still reconciled. An approved proposal faces the same schema, row-count, aggregate, sample and business checks as everything else. Sounding confident earns no exemption.

Won't better models make the deterministic layer unnecessary?

The opposite. A better model writes more convincing code, which makes unverified code more dangerous, because reviewers trust it more. The value of a deterministic core with a narrow, supervised and reconciled edge is that it stays auditable however good the model at the edge becomes.

We call the edge Resolve. We do not call the engine agentic, because it is not: it is rules. The model is a tool your engineer uses, on your terms.