Training Data for Migration AI: What We Actually Used

What We Trained On, Exactly

“Trained on migration data” is the kind of claim that means nothing without an inventory. So here is ours, honestly: a small, entirely owned corpus — currently 174 instruction/response pairs — assembled from assets we generated ourselves. No scraped forums, no customer schemas, no licensed documentation.

Small is deliberate. The model is not learning SQL from scratch; it starts from open weights that already know SQL. Fine-tuning teaches it our answers to Oracle-to-PostgreSQL questions — the house position on empty strings, on DATE, on package state — which is a narrow target that a few hundred high-quality examples hit better than a few million scraped ones.

The Five Sources

• The curated knowledge base. Hand-written house answers on type mapping, PL/SQL swaps, packages, sequences, validation, CDC cutover, encoding, dates, nulls. Each answer is paired with several natural phrasings of the question, so the model learns the answer rather than one prompt’s wording.
• Real transpiler output. Before/after pairs generated by running our own converter over PL/SQL fixtures. These are genuine conversions, not hand-waved examples — which also means a transpiler bug becomes a training-data bug, so the corpus is rebuilt whenever the converter changes.
• DDL conversions. Index and partition DDL through the same pipeline.
• Type-mapping Q&A. Generated from the mapping rules themselves, so the model and the deterministic engine cannot disagree.
• Issue-to-fix pairs. Every problem the engine can detect, paired with its explanation and remedy — the duplicate-key/sequence-resync case, the empty-string case, and the rest.
• Published articles. Our own blog corpus, mined into question/answer form.

Why Owned Data Only

Three reasons, in order of importance. Provenance: we can say precisely where every example came from. Correctness: scraped Q&A about Oracle-to-PostgreSQL is full of confidently wrong answers, and training on those teaches the model to be confidently wrong in the same places. And consistency: because the corpus is generated from the same rules the engine uses, the assistant’s advice and the tool’s behaviour stay in step.

Customer schemas are never training data. The model ships pre-trained and runs locally; nothing you connect to it is collected, and nothing leaves your machine.

The Shape

{"messages": [
  {"role": "system",    "content": "You are DBMigrateAIPro..."},
  {"role": "user",      "content": "why do I get duplicate key errors after loading?"},
  {"role": "assistant", "content": "Sequences don't move with the data...
     SELECT setval('hr.employees_id_seq', (SELECT max(id) FROM hr.employees));"}
]}

Standard chat-format JSONL, built by a script that runs with no GPU and no network, so the corpus can be rebuilt from source at any time and the count is always a fact rather than a memory.

The Floor Underneath

The same curated knowledge that seeds the corpus also ships as a deterministic responder. If no model file is present, the assistant still answers — from rules, with zero dependencies. That matters more than it sounds: it means the fine-tune is an upgrade rather than a prerequisite, and the product is never dead because a model didn’t load.