Data migration is the part of a system change that is most often underestimated. Shortly before the start it turns out that the customer list from the old system contains the same customer three times, that item numbers have two different meanings and that nobody remembers what the field “Flag2” was for.

That is why it pays to plan the migration early and not to answer the question “what do we take with us?” with “everything”.

What is migrated

Three groups of data almost always come along:

  • Master data: customers, suppliers, items, prices, staff, sites.
  • Open orders: orders not yet delivered, invoices not yet paid, quotes still open. It must be possible to carry on working on them in the new system.
  • Ongoing matters: the complaint being handled right now, the project that is half done, the maintenance contract still running.

Stock levels, if a warehouse is involved, and the open items in accounts, if they move too, are counted and reconciled afresh at the time of migration rather than copied from the old system.

What is better left behind

  • Closed matters from many years. Every invoice, every delivery note, every quote since the old system started - that is a lot, and hardly anyone will look at it in the new system. An archive with read access is better: the old system in read-only mode, or an export into files that can be searched.
  • Duplicates. The customer created three times because the search found nothing. The item under two numbers. Migrate them and you have them again - and staff lose faith in the new system.
  • Fields nobody uses any more. Every old system has fields set up long ago for a purpose nobody remembers. A field that is empty almost everywhere, or holds three different things, is questioned rather than migrated.
  • Notes fields used as a database. In many businesses the most important information sits in the remarks field: “delivers Tuesdays only”, “invoice to head office”, “discount as branch north”. In the new system they get fields of their own - which means reading and sorting them beforehand.

How long closed matters have to be kept and in what form is not a question for the software. Settle it with your tax adviser before the old system is switched off.

Preparation: cleaning and mapping

Clean up before migrating

Cleaning happens in the old system, not in the new one. Merging duplicates, flagging inactive customers, weeding out items without movement, checking addresses. This is the department’s work, because only they know which of the three “Müller GmbH” is the real customer. The vendor can supply lists of suspicious entries - the business has to decide.

A side effect: whoever cleans up sees their business - how many customers are active, which items do not sell, which prices are out of date. How master data then stays in one place is covered in the article on master data.

Mapping the fields

For every field in the old system it is decided where it belongs in the new one. In words, not arrows: “The customer number from the old system becomes the customer number in the new one. The field Flag2 means payment term and becomes the payment condition. The remarks field is read and distributed across delivery instruction, invoice address and discount group.” This list is the most important document of the migration. It also shows where the new system needs a field it does not yet have.

Trial migration and checking

Before the data goes live it is migrated on a trial basis - into a test environment of the new system that looks exactly like the real one will later. Then the department checks with samples: ten customers they know well, with all addresses and contacts. Ten items with prices and stock. Five open orders. One ongoing matter with its full history.

Counting records is the easy check, and the vendor does it. What the department checks is whether, with the migrated data, the clerk could create the order they created yesterday in the old system. If something turns up, the mapping is adjusted and the trial migration repeated. Several rounds are normal - that is what the trial is for.

The moment of migration

At the end comes the real migration. The last document is entered in the old system, then it is locked for changes. The data is migrated exactly as in the trial runs - the same path, the same mapping, no last-minute changes. The department checks its samples once more. Then the new system is released to the staff.

In a step-by-step replacement this happens per area: first complaints with their customers and matters, later the warehouse with items and stock. Each area has its own trial migration and its own moment.

What happens to the old system

The old system is not switched off on the day of migration. It keeps running read-only, so old matters can be looked up and anything missing in the new system checked against it. When nobody looks into it any more, it is no longer needed.

Before it is finally switched off, it needs an export into a format that is readable without the old program, a backup of that export in a second location, and confirmation from your tax adviser that the retention requirements are covered.

Questions before the migration

  • Which data does the first morning in the new system really need?
  • Who cleans the master data, and by when?
  • Is it settled for every old field where it goes - or whether it is dropped?
  • Is there a test environment in which the department can check the migrated data?
  • What stays in the archive, how do you get into it, and who has discussed it with the tax adviser?

How data migration fits into a step-by-step replacement is shown on our page on replacing old systems.