Modernising a legacy ERP without stopping the factory

Most ERP modernisation programmes are framed as a choice between two extremes. Either you keep the existing system as is, with all its known quirks, or you commit to a full replacement, with all its known risks. Framed that way, doing nothing usually wins.

The framing is wrong. There are at least three things going on inside an ERP, and they don't have to move at the same time: the data, the user experience, and the underlying transactional engine. You can modernise the first two long before you touch the third.

Before any modernisation talk, the existing system should be in a stable, supported, monitored state. That means current Windows Server, current SQL Server, current backups, and a clear inventory of customisations.

Many older ERPs are running on infrastructure that's a generation old because nobody wants to touch them. Lifting them onto modern Azure or on-prem infrastructure, without changing the application, removes a whole category of risk and buys time. It's not glamorous; it's a precondition for everything else.

The biggest practical problem with legacy ERP is usually that the data is trapped. Reports come out as overnight CSVs. Power users hold the spreadsheets that translate them. The business can't see a clean view of stock, production, margin or lead times without a person in the middle.

A modern data layer fixes that without touching the ERP. A Fabric or Synapse data platform, fed by a daily extract from the ERP, surfaces the data into Power BI and into Microsoft 365 generally. Suddenly the business has live dashboards, the finance team has a single source of truth, and the dependency on the spreadsheet wizard reduces.

Crucially, the data layer doesn't go away when you eventually replace the ERP. It's reused, with a new source feeding it. The investment compounds rather than getting thrown away.

Once the data is liberated, you can put modern interfaces on top of the legacy engine. Power Apps for the shop floor and warehouse. Power Automate for the ten or fifteen approval flows that currently live in email. A clean Teams-integrated experience for the planners.

This is the bit that the business actually notices, and it tends to be cheap and fast compared to a full migration. It also reveals which parts of the ERP are genuinely doing useful work and which parts are inherited habit.

By the time you've stabilised, liberated the data and modernised the experience, the replacement conversation looks completely different. You've already moved the user-facing layer. You already have a clean data platform. The remaining question is whether the underlying transactional engine - the bit that posts journals, runs MRP and books stock - is worth replacing.

For some manufacturers, the answer is yes, and Dynamics 365 Finance and Operations or Business Central is the right target. For others, the legacy engine is fine and the modernisation has already delivered most of the value without the migration risk.

Either way, the decision is now driven by genuine business need rather than vendor end-of-support pressure.

Month one to three: stabilise the platform. Lift to modern infrastructure if needed. Document customisations.

Month three to nine: stand up the data platform, surface the priority reports into Power BI, retire the worst of the spreadsheet dependencies.

Month nine to fifteen: ship two or three Power Apps and Power Automate flows that visibly improve daily work for the planners, the warehouse and the shop floor.

Month fifteen onwards: have the replacement conversation as a genuine choice, not as a panic.

The whole point of this approach is that nothing stops. The ERP keeps running. The line keeps producing. The business gets visibly better at using its own data and quietly accumulates the foundations for whatever comes next.

That's a less dramatic story than a big-bang replacement, which is exactly why it tends to land better with the people who actually have to live with the result.