Migrating data from an old system: what to move, what to leave behind and why it gets estimated last

Short answer: data migration takes five to fifteen per cent of a new system’s budget, and ten to fifteen per cent when a large accounting system is being replaced. What moves across is reference data, balances and unclosed documents. History from past years more often stays in the old system, open for reading only. The volume of the data matters less to the price than its condition: duplicate counterparties, empty mandatory fields and relationships between tables that nobody remembered.

We quote in roubles, so the figures below are given as proportions and timelines rather than converted amounts — convert at the rate of the day if you need an absolute number, or ask us for a quote.

Migration is almost always estimated last, because until the development exists there is nowhere to migrate to. The condition of the old data, though, has to be examined at the very start, or work appears at the end of the project that is in neither the estimate nor the plan.

What moves across

Reference data. Customers, counterparties, products, staff, warehouses. Without them the new system is empty, so this part is never optional.

Balances as of the switchover date. How much stock is in the warehouse, who owes whom, what credit limits customers have. These move as a single figure on a specific date, with no movement history.

Unclosed documents. Orders in progress, unpaid invoices, contracts still being delivered against. Work on them continues in the new system from the next day.

History. The most contested item. Closed orders from five years ago are rarely needed and expensive to move: every document refers to reference data that has changed over those years. History more often stays in the old system with writing disabled, or is exported into a separate store for reporting.

Attachments and files. Scanned contracts, photographs, correspondence. They get forgotten because in a table they look like a single column with a link. Why attachments rarely appear in a standard export is covered in what happens to your data if the vendor shuts down.

Where the money goes

Duplicates. One customer entered three times with the name spelled differently, one product with two cards and two codes. A new system with a uniqueness check will refuse those records, and deciding which of the three is the real one is a job for someone on the client’s side.

Empty fields. In the old system a tax ID was optional; in the new one a counterparty cannot be saved without it. Every field like that turns into a list of records somebody fills in by hand.

Hidden relationships. A customer’s discount lives in a comment on their card, the responsible manager is encoded in a group name. In the old system that worked because people knew. In a migration it is lost, unless somebody asks in advance.

Several sources. Half the customers are in the CRM, half in a spreadsheet kept by the sales team, and some records are in both. First decide which source wins, then migrate.

How a migration runs

An audit of the export. The vendor looks at a real export from the old system, because a verbal description is not enough. Counts duplicates, empty fields, relationships. Only after that can the migration be estimated properly.

Mapping rules. A table stating which field of the old system becomes which field of the new one, and what to do when a value is missing. It is signed off by someone on the client’s side who knows the data.

Trial runs. The migration is run several times against a copy of the data, with the rules corrected each time. Usually two or three runs before the result matches the old system.

The switchover day. The old system is closed for writing, a final export is taken, the data is moved and reconciled. Most often a weekend or a month end, when there is less movement.

Reconciliation. Balances, debts and the count of open documents in the new system have to match the old one as of the switchover date. The old system is not turned off until they do.

Who does what

Technically the vendor runs the migration. The decisions about duplicates, empty fields and which source wins belong to the client, because they are decisions about the business. One person is needed who knows the data and can say “these three records are one customer.” Without that person, the migration turns into weeks of waiting.

Common questions

Can everything be moved as it is? Yes, if the new system is built the same way and is just as permissive. Usually it is not, and migrated rubbish gets in the way from the first day.

How long does a migration take? The switchover itself takes a day or two. The preparation, with the audit, the rules and the trial runs, goes on in parallel with development for several weeks.

What happens to the old system afterwards? Keep it readable for as long as people still refer to it, usually until the financial year is closed. Then export an archive and switch it off.

The rule

Ask the vendor to look at an export of your data before they name a price for the project. If migration is a line in the estimate and nobody has looked at the data, that line was written blind.