Copilot for DBAs: Where We're Headed with DBMigrateAIPro

An Assistant That Can Actually Do Things

A chat window that explains PostgreSQL syntax is a search engine with better manners. What makes an assistant useful during a migration is that it can reach the engine: inventory the schema you are connected to, transpile the package you are looking at, run the validation you just asked about — and show you the result rather than a description of what the result might look like.

It Runs on Your Machine

The default provider is our own model, loaded in-process from a local file. No API key, no per-token bill, no network call, and no schema leaving the laptop. Schema and query text are among the most sensitive assets an organisation has, and “where does it go?” should have a boring answer.

Underneath the model sits a deterministic knowledge base. If no model file is present, the assistant still answers — from curated rules, with zero dependencies. The assistant is never dead, and never depends on an external service being up.

Cloud providers remain available as an opt-in upgrade for anyone who wants to bring their own key. That is a choice, not a requirement.

What It Can Reach

• Discovery and assessment. Object inventory, data profile, PL/SQL surface, conversion rate.
• Planning. A dependency-aware migration order with risk flags.
• Conversion. Type mapping and PL/SQL transpilation, through the same engine the CLI uses — one implementation, so the assistant and the tool cannot disagree.
• Validation. Row counts, column checksums, and the per-partition proof.
• Execution. The migration itself — behind a confirmation gate on every destructive call.

What It Won’t Do

It will not silently run destructive operations, invent a conversion for a construct it doesn’t recognise, or claim a migration is validated when it hasn’t checked. When it doesn’t know, saying so is an available answer — which is a design decision, because a confident wrong answer during a cutover is far more expensive than an admission of ignorance.

Where This Goes

The near-term work is the model itself: a fine-tune on our own corpus so the local default gets materially better at the narrow thing it does, benchmarked against the deterministic floor so we can prove the upgrade rather than assert it. Packaging follows — the model as a post-install download, so the installer stays small.

The longer arc is verification. Generating a migration is becoming commodity; proving it correct is not. Expect our effort to keep concentrating there.