A medical supplies distributor, imagine, has used the same desktop program for nine years and is now moving to a new order and inventory system. In the project meeting everyone talks about screens, reports and the mobile app. When someone asks how the old data will be moved, the answer is short: "We'll transfer it over a weekend."
Two days before go-live, the first real transfer runs. The same pharmacy appears in the list as four separate records, one product is kept in "units" while an old card for the same product is kept in "cases", closed branches still show open balances, and accounting says the total receivables in the new system don't match the old one. The go-live date slips.
The cause is rarely technical. Data migration looks like a software task, but most of its decisions belong to the business itself: which records are actually alive, what each field really means, when the old system goes quiet. The seven steps below pull those decisions to the start of the project.
1. Decide first what you won't move
The first instinct is to take everything: nine years of invoices, every product card, every contact. Yet the data the new system needs on day one is usually a small part of that.
Splitting the data into three groups helps. Live records: active customers, products on sale, open balances, stock in the warehouse, pending orders. These always move. Reference history: information that is useful to see in reports and on the customer card, such as a summary of the last year or two of sales. This can often move as a summary rather than line by line. Archive: cards that haven't moved in years and old documents. These don't enter the new system; when needed, they are read from the old system or from an export file.
This split shrinks the amount of data to move, but its real benefit is that the new system starts clean.
2. Give every data group an owner
A developer can't answer "Is the customer list correct?" The sales manager knows the customer cards best, the purchasing or warehouse lead knows the product cards, and accounting knows the balances.
Write down one person's name for each data group. That person makes the cleanup decisions, checks the result of each trial transfer and gives the "ready to move as is" sign-off. A data group with no owner turns into a question everyone asks each other during go-live week.
3. Clean up in the old system
Duplicate customers, products with mixed units, required fields left empty and spelling variants ("Ist.", "Istanbul", "ISTANBUL") become more visible once they reach the new system, but they don't fix themselves.
Do the cleanup at the source as far as possible, in the old system or in a working file exported from it. First list the records to be merged, then write down which record wins for each merge. Cleanups covering hundreds of records aren't done in one go but spread over weeks, which is why they go at the start of the schedule, not the end.
4. Write a mapping table
A plain table that maps every old field to its place in the new system is the most valuable document in a data migration. Its rows hold the old field, the new field, the conversion rule and a note.
The difficulty usually lies in codes. What does order status "3" in the old system correspond to in the new one? Are the old price lists a price list in the new system, or a customer group? How many units are in a case? When each of these questions is written into the table as a one-line rule, the migration script becomes nothing more than a tool that applies those rules. If a rule isn't written, the developer guesses, and guesses surface in production.
5. Run the trial transfer at least twice
Making the first real transfer the go-live weekend is the riskiest decision in the project. Instead, a few weeks earlier, run a full trial transfer with a copy of the real data, and once more after the fixes.
After each trial, the data owners check their own areas. The check is done with numbers, not by glancing around: is the number of active customers the same in both systems, does the total open balance match to the cent, are stock totals per warehouse equal, do the cards and recent transactions of twenty randomly chosen customers look right? Running this comparison with the same list every time shows whether the second trial really is better.
Also watch who can access the personal data in the copy used for trials; decide up front how that copy will be deleted once the trials are over.
6. Tie the cutover date to the calendar
At some point, new entries into the old system stop and the new system becomes the single source. This moment is called the cutover, and it shouldn't be left to a random day.
For most businesses the best time is right after a period close, so accounting keeps the closed period where it was and opens the new period in the new system. Write down in advance which transactions will be held back in the last days before cutover, where orders that arrive between cutover and go-live will be recorded, and how only the records that changed after the last transfer will be moved. If there is a field team, making sure the records waiting on their devices are sent before cutover goes on this list too.
7. Leave the old system on for now
In the first weeks after the switch, the question "how did this look in the old system?" always comes up. Keeping the old system open read-only for a while is the cheapest way to answer it.
Decide up front how long it stays open, who can access it, and which data will be archived where before it is switched off. For documents with a legal retention period, the archive needs to be in a readable format and within the business's own reach; a file only the old program can open may not open a few years from now.
In short
Data migration isn't a weekend job but a separate line item that starts at the beginning of the project. Decide which data won't move, give each data group an owner, clean up at the source, write the field and code mapping into a table, check trial transfers with numbers, tie the cutover date to a period close and keep the old system read-only for a while. When these steps are written down, go-live day becomes the day of a plan that has already been rehearsed, not a day of surprises.
In custom software and ERP projects, we plan data migration as a separate line item at the proposal stage and write the dates of the trial transfers into the project schedule from the start.
Planning a project like this?
Plan it in 10 steps