Legacy ISP export in. Clean, checked import files out.
Drop the CSVs a billing or OSS system hands you on the way out. The mapper reads only the headers and a few sample rows per file, proposes where each column goes in a normalized schema, then runs every row through duplicate, orphan, format and consistency checks in your browser. Nothing but those samples leaves the page.
Up to 6 files, 25 MB total. Column headers and up to 8 sample rows per file go to Google Gemini for the mapping proposal, so use an anonymised export if that matters; everything else stays in this tab. The sample is three files from an invented ISP with the usual problems planted in them.
Drop CSV files anywhere on the page
Files
Mappings
Each source column gets a target of entity.field and a transform. Change anything that looks wrong, then apply.
Readiness
Issues by rule
Downloads
Clean files contain every row that passed, with transforms applied. Rows with errors are left out and listed in issues.csv with the reason, so nothing fails silently on import.
What this is
gaiia's Series B post says the industry takes 12 to 18 months to migrate an operator onto new OSS/BSS, that gaiia averages 4 to 6, and that part of the round goes to the migration product. The slow part of any of those months is the export: columns named by whoever set up the old system, three date formats in one file, "Disco" and "ACTIVE" and "Active" meaning three different things to three different people, services pointing at customers who were deleted in 2019. This is a working concept of the first hour of that work: the model proposes where columns go, code checks every row, and a human looks only at what failed.
The target schema here is a generic one I wrote (customers, service addresses, subscriptions, devices, invoices). gaiia's real import format is behind their help-center login, so the exports from this page are a starting point, not a drop-in. More on the pitch page.