When a business replaces an old system, everyone talks about the shiny new software. The demos look great, the sales deck promises a smooth transition, and the budget covers licenses and training. Then reality arrives, and it arrives as data. This legacy data migration guide is about the part of the project nobody budgets for and everybody underestimates: moving ten years of messy records into the new system without breaking the business.

I have watched more system replacements stumble on data than on any feature gap. The new system works fine. The problem is that the old data was never as clean as anyone believed, and moving it exposes every shortcut and inconsistency accumulated over a decade.

You do not need to run the migration yourself. But if you own the business, a handful of decisions are yours to make, and making them well is the difference between a calm go-live and a month of firefighting.

Old Data Is Never As Clean As You Think

The first hard truth of any legacy data migration guide worth reading: your existing data is dirtier than you believe. It always is.

Ten years of humans typing into forms produces:

  • The same customer entered three times with slightly different spellings.
  • Phone numbers in five different formats, some with country codes, some without.
  • Blank fields that a required field in the new system will refuse to accept.
  • Codes and categories that made sense to someone in 2015 and mean nothing now.
  • Records that reference other records that no longer exist.

None of this mattered in the old system, because the old system was tolerant and your staff worked around the gaps by memory. The new system will not be so forgiving. It expects clean, consistent, complete data, and it will reject or mangle anything that does not fit.

This is why the first phase of a migration is not moving data. It is cleaning it. And that phase almost always takes longer than the technical work of actually transferring the records.

Owner-Level Decision One: What to Migrate, What to Archive

Here is a decision only the business can make, and it is worth real thought. You do not have to move everything.

Ask a blunt question: how much history do you actually need live in the new system? There is a strong case for migrating less than you assume.

  • Migrate: active customers, open orders, current inventory, anything you touch in daily operations, and enough recent history to run the business, often the last two to three years.
  • Archive: old closed transactions, inactive customers, records you keep only for legal or tax reasons. These can live in a read-only export or a simple archive database you can search if you ever need them.

Migrating everything sounds safe but it is not free. Every additional record is more to clean, more to test, and more that can go wrong. Dragging ten years of dead data into a fresh system slows the migration, inflates the cost, and clutters the new system from day one. Decide the cutoff deliberately. Keep what runs the business, archive what you only need for reference.

Owner-Level Decision Two: Who Owns the Cleaning

This is the decision most projects get wrong, and it is not a technical one.

Developers can move data and transform its format. They cannot decide that "PT Maju Jaya" and "Maju Jaya PT" are the same customer, or which of three duplicate records is the real one. That judgment requires someone who knows the business. Data cleaning is a business responsibility, not a developer task, and pretending otherwise is how migrations go sideways.

Assign it explicitly:

  • Name an owner from your operations or finance team who knows the records and can make the judgment calls.
  • Give them time. Cleaning is not something done in spare moments between other duties. It is a real workload for real weeks.
  • Let them define the rules. How to merge duplicates, what to do with blank fields, which historical categories map to which new ones. These are business rules, and only the business can set them.

If you skip this and hand the whole thing to the technical team, they will make guesses. Those guesses become wrong data in your new system, and you will discover them at the worst possible moment, usually when a customer or an auditor points them out. This is closely tied to the people-dependency risk I wrote about in Your Biggest Single Point of Failure Is Probably a Person, because the knowledge needed to clean the data often lives in one person's head.

Parallel Running Beats the Big Bang

There are two ways to switch to a new system. The big bang: shut off the old one on Friday, turn on the new one Monday, and hope. And parallel running: operate both systems side by side for a period before fully committing.

The big bang is tempting because it is cheaper and faster on paper. It is also where the horror stories come from. If something is wrong with the migrated data or the new system's behavior, you find out with no fallback, in production, with the whole business depending on it.

Parallel running costs more in the short term, and it is almost always worth it:

  1. Run both systems for a defined period, often a month, entering real transactions in both.
  2. Compare the outputs. Do the reports match? Do the balances agree? Do the inventory counts line up? Mismatches reveal migration errors while you still have the old system as ground truth.
  3. Build confidence before you commit. By the end of the parallel period, you are not hoping the new system works. You have proof.
  4. Keep the old system readable for a while even after cutover, so you can check anything that looks off.

Yes, running two systems is extra work for your team for a month. That extra work is insurance, and it is far cheaper than discovering three months later that your financial history migrated incorrectly and nobody noticed.

Practical Takeaways

If you are about to replace a core system, treat the data as the main event, not an afterthought:

  • Budget for cleaning, not just moving. The first phase is fixing dirty data, and it takes longer than the technical transfer.
  • Migrate less than you think. Move what runs the business, archive what you only keep for reference. Old dead data is a cost, not a safety net.
  • Assign a business owner to data cleaning. Developers move data, but only someone who knows the business can decide what is correct.
  • Choose parallel running over the big bang. A month of running both systems and comparing outputs is the cheapest insurance you will ever buy.

A system replacement lives or dies on its data. The new software is the easy part. The old data debts you have been carrying for a decade will surface during the move, and the businesses that plan for that come through calm. If you want someone to plan the migration properly and keep it from becoming a crisis, that is work I take on as a technical partner.