The migration you should not do

A business about to adopt a new system naturally wants its history in it. Years of customers, transactions and stock movements, all in one place, so nothing is lost.

It sounds like diligence. In practice it is the single most reliable way to turn a four-week rollout into a six-month one.

Old data is inconsistent in ways nobody remembers. Customer names spelled three ways. Items renamed twice. A period where somebody used a different code convention. Balances that were adjusted manually for reasons lost to time.

Every one of those becomes a decision somebody has to make, and each decision needs somebody who knows the history. That person also has a day job, and the project waits on them.

• Opening balances, agreed rather than imported. Every customer and supplier balance confirmed with the other side.
• Current stock, counted physically at cutover rather than carried across.
• Active customers and suppliers. Not the ones who last traded in 2019.
• Open orders, unpaid invoices and anything else still live.

That is a few days of work rather than a few months, and it produces a clean opening position instead of importing the previous system's accumulated errors into a new one.

History is not lost by not migrating it. Keep the old system available read-only, or export it to files that can be searched.

Businesses that do this consult the archive far less than they expected. The demand for a transaction from four years ago is real but rare, and it does not justify holding up the entire changeover.