Legacy warehouse to modern platform
On-premises to cloud, or between cloud warehouses, with reconciliation at every stage.
The problem
The risk in a migration is not moving the data. It is that nobody can demonstrate afterwards that the new system says the same thing as the old one — so finance keeps the legacy platform running "just to check", the cutover slips a quarter, and the saving that justified the project never arrives. Meanwhile every migration surfaces data quality problems that were invisible while one system owned them.
Who this is for
- CIOs and platform ownersA cutover that happens rather than one that keeps slipping
- Finance and reportingEvidence, period by period, that the reported figures still reconcile
- Data engineering teamsProfiling and mapping done once, properly, instead of discovered during cutover weekend
What people use it for
Application or ERP replacement
Moving master and transactional data into a new system whose model is not the old one.
Consolidation after an acquisition
Merging two estates that define a customer, a product or a period differently, and deciding which wins.
Ongoing replication
Change data capture where the old system stays live during a phased move.
What it needs to work
- Access to source and target, and agreement on the target model
- The reports and figures that must reconcile — the ones people will check
- Business rules that changed between systems, stated rather than discovered
- A cutover window and a rollback position agreed in advance
How it works
-
Profile the source
What is actually there — types, ranges, nulls, duplicates and the fields nobody has populated since 2019.
-
Map, with the rules explicit
Field to field, and where the meaning changes, that change is written down rather than encoded silently.
-
Transform and load
In batches that can be re-run, with the raw extract retained so any figure can be re-derived.
-
Reconcile
Counts, sums and key reports compared old against new, period by period, with differences explained not averaged.
-
Run in parallel
Both systems producing the same reports until the numbers agree for long enough to trust.
-
Cut over, with a way back
A rehearsed cutover and a rollback that has been tested rather than assumed.
How we deliver it
-
Assessment and profiling
Source reality, target model and the gap between them, including the data quality nobody knew about.
-
Mapping and rules
Agreed with the business, because a mapping decision is usually a definition decision in disguise.
-
Trial loads and reconciliation
Repeated until reconciliation is clean or every difference is explained and accepted in writing.
-
Cutover and stabilisation
The rehearsed switch, then a period of watching before the legacy platform is switched off.
Where it runs
- Between on-premises systems, on-premises to cloud, or cloud to cloud
- Batch migration, or change data capture for a phased move
- Runs inside your environment; data does not transit ours
Security and governance
- Raw extracts retained so any migrated figure can be traced to source
- Reconciliation evidence produced as a deliverable, not on request
- Mapping rules under version control and signed off by the business
- Sensitive fields masked in non-production environments
Timeline
Profiling and mapping dominate, and they are where the surprises live. The load itself is usually the shortest phase. Where reconciliation will not close, that is almost never a migration bug — it is two systems that were always calculating differently, and finding that out is worth the delay it causes.
What you receive
- A profiling report on the source, including the quality problems found
- Documented, version-controlled mapping and transformation rules
- Reconciliation evidence per period and per key report
- A rehearsed cutover plan with a tested rollback
- Re-runnable pipelines, so a correction does not mean starting again
Related work
Published projects where we did this.
What this does not do
A migration cannot improve data it did not create. Where the source is wrong, the choice is to migrate the error faithfully or fix it — and fixing it changes historical figures, which is a business decision, not ours. We also will not sign off a cutover while reconciliation is unexplained: an unexplained difference at cutover becomes an unexplained difference in your annual report.
Questions we are asked
How do we know nothing was lost?
Counts, sums and key reports reconciled period by period against the old platform, produced as evidence rather than asserted. Where a figure legitimately changes, the reason is documented and signed off.
Can the old system stay live during the move?
Yes, with change data capture keeping the target current during a phased cutover. It costs more to run and is usually worth it where a big-bang switch is not acceptable.
About the figures on this page
This page describes capability and method. It does not publish accuracy figures, throughput numbers or delivery dates, because those depend on your data, your systems and your scope — and a number published here would be wrong for most readers. You get them, in writing and against your own data, at scoping.
A first call is a technical conversation, not a pitch: what you have, what you need, and whether this is the right approach at all.
Key capabilities
- Enterprise data
Built on the Unified Intelligence Layer
Every InsAI product runs on the same four-stage backbone.
- 1
Data Integration
ERP · IoT · BIM · CRM
- 2
AI Models & Predictive Engines
Forecasting, detection, optimization
- 3
Automation & AI Agents
Acting on predictions, end to end
- 4
Real-time Dashboards & Decision Systems
From the floor to the boardroom
DataFlow Migrateware
Secure, scalable data migration to warehouses.