Replacing Infor or Sage: data migration is the real work

Replacing Infor or Sage is not a project of weeks. Installing the software is easy, cleanly transferring your grown data is the real work. Whoever promises you "done in a few weeks" has not looked at your data foundation. Honest depth beats fast promises.

Why does grown legacy data repeat the chaos?

Legacy ERP systems accumulate inconsistent master data over the years: duplicate vendors, inconsistent item numbers, repurposed fields. Tipping that data one to one into Business Central only reproduces the grown chaos in a new and more expensive system.

The reason is simple: a modern system checks more strictly. What passed as free text in the legacy system collides with a mandatory check in the target system, and then you get either failures or, worse, quiet workarounds that nobody documents.

Replacement is the only moment at which you can shed that ballast without a running operation. Afterwards the same cleansing costs a multiple, because it has to run against productive processes and every change wants to be agreed. That opportunity comes exactly once in the life of an ERP system, and it stays open for only a few months.

What does data migration really include?

Data migration does not mean copying. It is a chain of five work steps, and every one of them belongs in a test run with real data before anything goes live.

• Clean: remove duplicates and errors in the legacy data.
• Map: translate fields and structures onto the BC data model.
• Validate: check whether balances, totals and references are correct.
• Test: run a complete rehearsal with real data.
• Load: only then transfer into the production system.

The test run is the step most often dropped, and the only one that secures the other four. Without it, you find out on the migration weekend whether the balances add up, and by then there is no time left for an orderly correction.

For the loading step, Business Central brings its own tools that can be run repeatedly, which is what makes repeated trial runs practical in the first place.

Source: Microsoft Learn: Set up company configuration packages

Why should you not rebuild processes blindly?

History and open items belong cleanly separated: what does day-to-day work need live, and what is enough as an archive? That separation lowers migration effort and risk at the same time, because archive data does not have to be in the same structure as productive documents and needs no ongoing upkeep.

Equally important is not to rebuild processes from Infor or Sage blindly. Much of it was a workaround for limits of the legacy system and is simply superfluous in Business Central. The test sentence for it is short: if nobody can explain what business purpose a step serves, it is an inheritance.

We name the realistic complexity up front and not after the project has started, because a date that rests on unexamined legacy data does not hold three months. Let us look at your data foundation before anyone promises a date: we show honestly what the replacement really involves.