Migrations fail on meaning, not on transfer
Moving rows is straightforward. What goes wrong is meaning: a status code the old system used differently, a field two teams filled with different things, a relationship that was implied rather than declared. Those surface after cutover unless something forces them out first.
How DataLens approaches it
Discover what is actually there
The source model is inferred from the values in the legacy system, not from its documentation — which is where the surprises are.
The target is explicit
Design the schema you actually want, including the junction tables the old system faked with delimited columns.
Mapping is field by field
Every target field is either mapped or visibly unmapped. A required field nothing can fill is found at design time, not at cutover.
Gates catch the losses
Row counts, key uniqueness and referential rules as gates, so a migration that dropped 3% of records fails rather than completing.
Rehearse it
The migration is a flow. Run it against a copy as many times as you need, and promote the version that worked.
Lineage for the audit
What came from where and what was applied to it is recorded, which is the question every post-migration audit asks.
The stages this leans on
The rest of the lifecycle is there when you need it.
Questions
Can I run the migration repeatedly before cutover?
Yes, and you should. It is a flow — run it against a copy, inspect what the gates said, adjust the mapping and run it again.
What about data the new system has no home for?
It shows as unmapped source fields rather than being silently dropped, which turns it into a decision someone makes rather than a loss someone discovers.
How do we prove the migration was complete?
Gate results and lineage together: row counts and key checks at each stage, and a record of what was applied to what.
See it on your own data
DataLens is in private beta. Bring a file, a database or an API and work through the whole lifecycle in one sitting.
Request beta access