“We’ll lose records and not notice.”
Every run reports how many records went in, what was left out and why, and fails outright when a record points at something that did not come across.
Product
Legacy data migration
Moving years of records out of an old system is the part of every modernization people lose sleep over. Sapilon turns it into a written plan you approve line by line, rehearses it on a real server as often as you like, and only lets it near your Live data once a rehearsal has come back clean.
Nothing copied until you run it Every decision in writing Rehearsed before Live Safe to run twice
Why data migration is the scary part
A new app can be clicked through and judged in an afternoon. Data can’t. A migration that goes wrong usually looks fine on the day: the screens load, the counts look about right, and three weeks later finance notices that a quarter’s invoices point at customers who never came across. The fear is reasonable. What it calls for is a process that finds those problems while nobody depends on the answer yet.
“Nobody knows what half these columns mean.”
Every assumption is written down in plain language on a card, for you to accept or disagree with. Nothing is inferred silently.
“We get one shot at cutover.”
You get as many shots as you want. Each rehearsal replaces the last, and Live only accepts a mapping that has already rehearsed cleanly.
“Our customer data can’t just float around.”
Sources are read in place, uploads are encrypted and deleted after the migration or 30 days, and nothing of the old data is kept between runs.
Three jobs, kept apart
Most migrations that go wrong treat moving data as one job. It is three, with different risks, and Sapilon keeps a clear seam between them.
- 01
Read it out
Get the rows out of the old system, whatever it runs on. An engine problem, handled by the platform.
- 02
Work out what becomes what
Your old tblCustomer is not the new customers table. One old record may become a customer and an address; CustType = 3 may mean “internal”. This is the real work: the agent proposes, you confirm, an expert can check.
where the risk lives
- 03
Put it in safely
Back up the target first, load in the right order, then check what landed. Nothing reaches your Live data unverified.
Six steps, described before anything runs
The Data migration page in your project is a row of steps. The first five describe the job. Only the last one touches data.
-
01
Who looks after it
Your own team, or a verified expert who reads SQL and knows what old data tends to hide. The request already describes your source, and the expert quotes before starting.
-
02
Where the old data is
An export, a database dump, or a read-only connection. Sapilon reads the structure where it lives and copies nothing.
-
03
What it holds
Every table, its columns, how many rows it has and a sample of what the values look like.
-
04
What to bring
Untick the tables you don’t need and narrow the rest with a condition, such as only orders since 2018. A misspelled column is caught when you save, not halfway through a run.
-
05
What becomes what
Your project’s agent reads the old tables and the new schema and proposes one card per new table: where its rows come from, what identifies a record, which assumptions it made. You accept or disagree line by line. Leaving a table behind is a decision too, written down with its reason.
-
06
Run it
Read the old data fresh, load it through the mapping into your Rehearsal Server, and check what landed. As often as you like.
customers
3 of 4 acceptedProposed by your project's agent · from old.tblCustomer
- Each record of old.tblCustomer becomes a row of customers
- A record is identified by CustID
- CustType 1 / 2 / 3 read as retail, trade, internal
- Fax is not carried: empty in 94% of rows You: “Keep it. Trade customers still order by fax.”
Accept or disagree, line by line. A table is confirmed once every line is accepted.
What Sapilon reads
- CSV, Excel, JSON, or a .zip of them: the export button in Salesforce, HubSpot, Airtable, Bubble, Notion, spreadsheets, and almost any business system
- A Postgres dump file, plain or compressed
- A read-only connection to a Postgres database
On SQL Server, MySQL, Oracle or MongoDB? Export the tables you need as CSV or Excel. It is usually the faster route anyway: a file uploaded on a Friday evening skips the firewall ticket and the week-long security review a live connection needs.
Rehearsal run 7 · Rehearsal Server
Clean- Customers
- 18,204 in · 312 left out (deleted)
- Orders 2019–2025
- €4,182,336.20 in both
- Records pointing at nothing
- 0
- Status codes
- 11 of 11 mapped
Same mapping version as the Live cutover will use.
A report you can actually read
Every run ends with a report written for the person who has to sign off, not for the person who wrote the SQL. It leads with the checks people trust.
-
Before and after
A few real records side by side. Find a customer you know and look at them.
-
Do the totals match
Money and quantity columns, old total against new. “Orders 2019–2025: €4,182,336.20 in both” settles more arguments than any spreadsheet.
-
Records pointing at nothing
An order whose customer did not come across fails the run outright.
-
Every code, and what it became
Each distinct status or type value and what it turned into. A value that became nothing is the most common real problem, and here it is impossible to miss.
-
What was left out, and why
Leaving records behind is fine. Leaving them behind for a reason nobody can explain is not.
Rehearse until it is boring, then go Live
The rule the product enforces is short: your Live Server only runs a migration that has already rehearsed cleanly with exactly the same mapping. Change one line after your last rehearsal and you rehearse again. The cutover itself happens inside the Go Live step, together with the freeze of the old system, the sign-off, and the plan for old accounts, because those decisions belong together.
Safe to run twice
Every record keeps its old identifier, so a second run updates rather than duplicates. A mapping fix is a correction, not a clean-up job.
Traceable for years
“Which old record did this come from?” still has an answer long after the old system is switched off.
Versioned with your code
The mapping lives in your project’s Git repository, so every change to it is a version you can look back at.
Closed out cleanly
When the old system is retired, closing out deletes the uploads, the stored connection and the working area. Your data then lives in one place: the new system.
Questions people ask first
Can Sapilon move the data from my old system into the new one?
Yes. Point Sapilon at an export, a database dump or a read-only connection. Your project’s agent proposes how each old table maps onto the new schema, you confirm every decision, and the migration is rehearsed on your Rehearsal Server with a reconciliation report before it is allowed to run on Live.
Which databases and systems can Sapilon migrate data from?
Sapilon reads CSV, Excel and JSON exports (which covers Salesforce, HubSpot, Airtable, Bubble, Notion, spreadsheets and most business systems), Postgres dumps, and read-only Postgres connections. For SQL Server, MySQL, Oracle or MongoDB, export the tables you need as CSV or Excel.
How do I know the migrated data is correct?
Every run produces a report: sample records before and after, record counts with reasons for anything left out, old and new totals for money and quantity columns, every code value and what it became, and a hard failure for any record that points at something missing.
What happens if a migration run goes wrong?
Nothing that matters. Runs go to the Rehearsal Server first and each one replaces the last. Records keep their old identifiers, so running again after a fix updates rather than duplicates. Live only accepts a mapping that has already rehearsed cleanly.
Do I need a data engineer to migrate my data with Sapilon?
Not for the common cases: the steps are written for the person who knows what the data means. If nobody on your team reads SQL, you can ask a verified Sapilon expert to look after the migration; they quote first and work on the same steps with you.
Bring the system and its data
Modernize the app and move its records in the same project, rehearsed on the same servers.
Publicly available on 15 November 202650 days to go
Start nowWant a person on it?
A verified data expert can look after the whole migration: check the mapping, read every rehearsal report, and sign off before Live. They quote before they start.