AI-Assisted Migration, Start to Finish: A Realistic Workflow

The Shape of the Work

A database migration is not one task; it is a sequence of them, and AI helps unevenly across that sequence. Some steps are finite problems with known-correct answers, where a deterministic rule beats a model every time. Others are judgement calls where a model that reads context well genuinely saves hours. Knowing which is which is most of what makes an AI-assisted migration faster instead of just louder.

Here is the workflow we actually run, step by step, with an honest note on where the AI earns its place and where it stays out of the way.

Step 1 — Connect and Discover

You point the tool at the source. It reads the catalog — tables, columns, constraints, indexes, sequences, views, PL/SQL packages, jobs — and produces a measured inventory rather than a remembered one. This is where the biggest early time saving hides: discovery that used to take weeks of spreadsheet archaeology becomes an afternoon, and it is more accurate because nothing is estimated.

Where AI sits: mostly out. Counting objects and reading a data dictionary is deterministic. The model only enters to summarise and explain — "here is what this 4,000-line package appears to do" — which is comprehension, the use case models are genuinely reliable at.

Step 2 — Assess Complexity

Not every object is equal. A table with three numeric columns is trivial; a package that uses collection types, autonomous transactions, and dynamic SQL is not. The assessment scores each object by conversion difficulty so you can see the real surface area before committing a date.

Where AI sits: interpretation. Detecting that a construct exists is a rule; judging how hard it will be to re-express in PostgreSQL — and flagging the handful that need a human — is where a model that has read a great deal of PL/SQL adds value.

Step 3 — Convert Schema, Then Code

Schema conversion comes first because it is the most rule-driven: type mapping, identity columns, default expressions, index definitions. These are finite problems, handled with deterministic rules rather than a model, because a rule that is always right beats a model that is usually right.

PL/SQL is the harder half. Packages, procedures, triggers, and functions get transpiled toward PL/pgSQL, and this is where the model does real work — but every non-trivial routine still lands in front of a human.

Oracle PL/SQL  --->  transpile  --->  PL/pgSQL draft  --->  human review
                      (rules +          (compiles,          (you own the
                       model)            flagged gaps)        final version)

Step 4 — The Human Review Gate

This is the step that separates an assisted migration from an automated one. Anything the tool cannot convert with confidence produces a warning or a gap entry — never quiet, plausible output that looks done and is wrong. You review the flagged items, accept or rewrite, and move on. The goal is not zero human work; it is to concentrate human attention on the few things that actually need it.

Step 5 — Bulk Load

With the schema in place, data moves in batches, with live per-batch progress so a long-running load never looks frozen. LOBs and wide tables get smaller batches to keep memory flat. This step is pure engineering — no model involved — and correctness here is measured, not assumed.

Step 6 — Validate

Generating a migration is becoming commoditised; proving it correct is not, which is why validation is the part we treat as the product. Row counts are the cheap first pass, but they match even when a numeric was silently truncated — so the tool also compares per-row hashes and, where you ask for it, cryptographic per-partition fingerprints. The report shows exactly what matched and what did not, with row-level detail.

Where AI sits: nowhere. You cannot eyeball whether forty million rows arrived intact, and you should not ask a model to vouch for it. Validation is deterministic arithmetic, and that is the point.

Step 7 — CDC and Cutover

For systems that cannot take downtime, change data capture keeps the target in sync with the source until the moment you switch. Cutover is a deliberate, human-approved action — the tool will not flip production on its own. When lag is near zero and validation is green, you cut over.

The Honest Takeaway

AI does not remove the migration; it re-shapes where your time goes. Discovery collapses, rote conversion scales down to the flagged remainder, and rework shrinks because defects surface before UAT instead of after. What does not change is that a human owns the hard constructs, the cutover decision, and the sign-off. A tool that claims otherwise is describing a migration you would not want to run.