Guide
Rehearse the Data Migration at Full Volume Until Go-Live Is Routine
Data migration is often planned as a late task. We rehearse it early, at full volume and against the clock, with a reconciliation signed by the people who own the data.
5-minute read5 November 2026
In Brief
- When data is left to the end of an ERP programme, extraction problems, rejected records and slow steps are discovered in the first live week, at the point where they cost most.
- Four actions: extract everything once, rehearse the real sequence with the real people, reconcile with owners, and let evidence decide go-live.
- Thinqmesh asks first whether your current system can export its data, then moves your records across and checks them, with extraction dated separately where it cannot.
In many ERP programmes, data migration appears on the plan as a task near the end, sized in weeks and assigned to the supplier. Configuration receives the design workshops and the steering attention, while the data waits its turn. Public bodies carry particular exposure, because their records are old, have passed through several systems and answer to auditors and citizens.
A Migration Earns Trust Through Repetition
A migration can load every record and still be wrong, so the first full attempt on go-live night is the most expensive place to discover that. Extraction turns out to be slower than planned, a vendor has been merged twice, a budget head was restructured years ago and the opening balance does not agree to the closed books.
We treat migration as a stage of its own, and we ask one question first: can your current system export its data? Where it cannot, extraction gets its own date, planned openly from the start. Records are then moved across and checked, and the evidence from repeated rehearsals decides whether go-live happens. A go-live date should follow from that evidence. Where the two conflict, we think the date should move.
Four Actions That Make Go-Live a Routine Event
Each one begins on a single data set this month, and each brings problems forward to the point where they are cheap.
Extract One Complete Data Set and Time Every Step
Vendors or employees make a good first data set, because everyone has an opinion about them.
Take all of it from a current copy of the source, profile it for duplicates, missing mandatory values and inactive records, load it into the target environment and record the hours each step takes. A sample on a quiet afternoon proves little about go-live, because time and failure both behave differently at scale.
Get started
- Choose one master data set and extract all of it from a current copy.
- Write down the elapsed hours for each step.
Run the Real Sequence With the Real People
Freeze, extract, transform, load, reconcile and hand over, in the order of the night itself.
The people who will carry out the cutover work from the runbook, against the actual window. A fix made by hand in the target means that step has not been rehearsed, so every correction goes back into the scripts or into the source. The next run then does it unaided.
Get started
- Write the runbook and have someone other than its author follow it.
- Log every manual fix and move it into the scripts.
Reconcile as an Auditor Would
A green load log says little. Counts, totals and traced samples say more.
Reconciliation is prepared by people independent of those who ran the scripts and signed by the owners of the data. It covers counts by record type, control totals tied to closed books, traced samples weighted towards awkward cases and a register in which every rejected record has a cause, an owner and a decision.
Get started
- Reconcile counts between source and target and list every difference.
- Give the rejected records to the person who owns that data.
Set the Exit Criteria for Go-Live in Advance
When the evidence meets the criteria, the date follows.
Agree them early: two consecutive rehearsals inside the window, no new class of defect, every reject explained, a rehearsed way back with its point of no return named, and a runbook someone else has followed successfully. If the date cannot move, reduce scope by migrating less history or fewer units in the first wave.
Get started
- Write the exit criteria on one page for your steering board.
- Decide what you would leave behind if the date could not move.
How Thinqmesh Solves This
Stock, purchasing and job costing are configured around your process and introduced one part at a time, alongside the systems you already run. Your records are moved across and checked before go-live.
- Week 1
The Export Question
We first establish whether your current system can export its data. If it cannot, getting the data out is planned as its own job with its own date.
- Week 2
Your Rules, Set Up Your Way
Approvals, access levels and costing rules are configured around how you operate, with a record of who asked and who approved.
- Week 3
Records Moved and Checked
We connect the systems you rely on, migrate your existing records and check them against the source.
- Week 4
Real Work, Running
The one job you named goes live on your own system, beside what you already run, so you can judge it on real work.
You finish with one job running on your own system, with your records moved across and checked. Further modules are agreed one at a time, in writing.
