Nobody trusts an empty system.
Adoption succeeds or fails on day one, when your team opens the new system and looks for what they know. Retrotech has spent eighteen years around legacy systems — including maintaining our own — so we know how operational history actually lives: half in the old database, half in spreadsheets, all of it load-bearing. Migration runs inside our implementations, planned from the first scoping call. We treat migration as part of the product, not an afterthought bolted to the invoice.
What we migrate
Your operation’s memory, record by record.
Maintenance & technical
Equipment hierarchies, running hours, job histories, defects, and certificates.
Stock & procurement
Spares and stores ledgers, vendor masters, price history, and opening balances.
Operations & commercial
Tanks and movement history, contracts, customers, and open transactions.
Documents & registers
Document registers, revision histories, and the metadata that makes them findable.
The method
Five steps, nothing on faith.
Extract & assess
Get it out, and get honest about it.
We pull the data from wherever it lives — legacy databases, exports, spreadsheets that grew into systems — and profile it before anything moves: what exists, what’s duplicated, what’s missing, and what state it’s really in.
- Extraction from legacy systems, exports, and spreadsheets
- Data profiling: gaps, duplicates, and quality
- An honest scope of what can move and what can’t
Map & cleanse
Old fields, new model, one meaning.
Every source field is mapped to its place in the new system, and the data is cleansed on the way: duplicates merged, codes and units standardised, and naming brought to one convention — so the system starts consistent instead of inheriting chaos.
- Field-by-field mapping to the new data model
- De-duplication and standardised codes and units
- Cleansing rules agreed with you, not assumed
Trial loads
See your own records on real screens.
We load the mapped data into a test instance — not once, but in staged passes — so your team reviews real records on real screens and corrections happen before go-live, not after.
- Staged loads into a test instance
- Your team reviews real records on real screens
- Corrections fed back into the mapping
Reconcile & sign off
Proven against the source, then signed.
Counts, balances, and spot checks are reconciled against the source system, differences are explained line by line, and the migration is formally signed off — by you — before anything goes live.
- Counts and balances reconciled to source
- Differences explained, not waved through
- Formal sign-off before cutover
Cutover
The final delta, then the switch.
At go-live we load the final delta — everything that changed since the last trial — freeze the source as the archive, and the new system takes over as the single record from day one.
- Final delta load at go-live
- Source system frozen and archived
- One system of record from day one
When the data doesn’t exist yet
Migration moves data that exists. When the records were never built — no equipment tree, no spares catalogue, no job library — moving is not the problem; building is. That is a different service, and we offer it.
Explore Operational Data BuildingQuestions, answered
What evaluators ask first
What can you migrate from?
Legacy systems, database exports, reports from the system being retired, and the spreadsheets that grew into systems. Sources are profiled in the first step, and the approach is scoped per project.
How do you make sure nothing is lost?
Trial loads into a test instance, reconciliation of counts and balances against the source, differences explained line by line, and your formal sign-off before cutover.
Will we see our data before go-live?
Yes. Staged trial loads put your real records on real screens, and your team’s corrections are fed back into the mapping before the final load.
What if our records are messy or incomplete?
Messy is normal: cleansing, de-duplication, and standardisation are part of the mapping step. Data that never existed can’t be migrated — building it is our Operational Data Building service.
Which systems does this cover?
All three products — RETRO.RTMS, RETRO.FMS, and RETRO.DCS — and the custom applications we build.