For the team at gaiia
A migration mapper for legacy ISP exports, working
gaiia's Series B post says operator migrations take 12 to 18 months industry-wide, that gaiia averages 4 to 6, and that part of the round goes to the migration product. The slow hours in any of those months are spent on the old system's export: columns named by whoever set it up, three date formats in one file, statuses that mean different things to different people, services pointing at customers deleted years ago. I built a working tool for that first pass: drop the CSVs, a model proposes where every column goes, code checks every row, and a person only looks at what failed.
The model sees the headers, not the data
What I noticed
An operator's export is customer PII and billing history. Sending whole files to a model to get column mappings is a hard sell to an ISP's ops lead, and unnecessary.
Why it matters
Column names and a handful of sample rows are enough to decide that "Acct Status" is customers.status and "ONT MAC" belongs to devices, not subscriptions.
The fix
The tool parses the CSVs in the browser and sends only headers plus up to 8 sample rows per file to the mapping endpoint (Gemini, rate-limited, nothing stored). The full files never leave the page. When the model is unavailable or capped, a header-synonym mapper takes over and the page says so.
Every row goes through code, not a prompt
What I noticed
The migration failures that cost weeks are boring: a service for a customer who is not in the customers file, two active subscriptions on one account, an invoice due before it was issued, a Canadian postal code on a US address.
Why it matters
A model is the wrong tool for checking 40,000 rows; deterministic rules are cheap, explainable and repeatable on the next export.
The fix
After mapping, transforms normalise dates, money, phones, speeds and statuses, then rules check duplicates, orphans, formats and consistency across entities. Rows with errors are held back and listed with the reason; the rest become clean import files.
A number the ops lead can put in the migration plan
What I noticed
The post says gaiia invests hundreds of thousands of dollars per customer to get them live, and that a new CSP goes live roughly every other week.
Why it matters
Before a forward-deployed engineer touches an operator's data, a readiness score and an issues.csv tell both sides how much cleanup is ahead and where it is.
The fix
The report page shows a readiness score, clean-row counts per entity, issues grouped by rule with the exact file and line, and downloads: one CSV per entity, issues.csv, and report.md. The target schema is a generic one I wrote; gaiia's real import format is behind the help-center login.