Data Migration · Software Insight

What migration involves

Demonstrations show clean screens and a tidy chart of accounts. Then someone asks what happens to the eleven years of history in the old system. Migration is the middle of every implementation: extracting records from software that was not designed to give them up, mapping them to a new structure, reconciling the two, and proving they agree before go-live. It is often quoted as an afterthought.

Two systems, reconciled line by line before one is switched off

The first reconciliation

The first reconciliation is where organisations meet their own records, and the result is rarely tidy: customers duplicated with three spellings, suppliers long deregistered, opening balances that never balanced. This is the consequence of years of local decisions, not carelessness. The cost of discovering it belongs in the plan, before go-live.

How migration is quoted

Migration is quoted as its own line item, per data set. The method has three fixed elements: profile the source data before promising anything; map in a workshop with the people who know the data; and reconcile line by line for one full business cycle before the old system is switched off. The freight operator’s two-month parallel consolidation is an example.

What to do about it, whatever you buy

Profile before you promise: a sample extract of each data set tells you more than any scoping questionnaire, and it takes a day rather than a month. Decide explicitly what you are not migrating — a clean archive of the old system, kept readable, is a legitimate answer for cold history and a far cheaper one than cleansing it. Set an accuracy target per data set, in writing, and agree in advance what happens when a set misses it. And keep a named person on your side whose job is to know the old data; the consultant can learn the new system, but only your staff know why the 2016 exception exists.

The clean-start option

Starting fresh is correct when the old records are unreliable, when the business has changed shape so much that history is not comparable, or when cleansing costs more than what survives. Otherwise the cost does not disappear: statutory records must still be retained, and comparative figures are still requested. The clean start should be a recorded, signed-off decision.

Questions this view raises

How much of our history should we actually migrate?
Enough to answer the questions you will be asked, and no more. Two full financial years of transactions covers most comparative reporting; master records — customers, suppliers, assets — go back as far as they are still live. Cold history belongs in a readable archive of the old system rather than in the new one. The discipline is deciding this in writing before the extract, because the cost of migrating a data set rises sharply once it has been promised.
What happens when the reconciliation does not agree?
It does not agree on the first pass, in every project we have run, which is why the run is useful. Variances are triaged: mapping errors are fixed in the mapping, source errors are fixed at source, and genuine disagreements are documented with the figure the client accepts. Go-live waits on the third category being closed out, not on a perfect match; a signed variance list closes out the parallel run.
Where this shows up in our software

Migration is quoted as its own line item, per data set, with a parallel run before the old system is switched off. You can see these principles applied on the projects pages and throughout the InsightSuite module pages.

« All Insights Next Insight »