ERP at a Crossroads: Modernise the Core Without Stopping the Business

A generation of ERP estates is reaching the end of its useful life at roughly the same time. Vendor support deadlines, the shift to cloud editions and the promise of AI features embedded in the core have put ERP modernisation on board agendas in almost every industry. These programmes remain among the most expensive and risky commitments an organisation makes, and the ways they go wrong are remarkably consistent.

The argument here is that the difference between a contained programme and a multi-year ordeal is settled before any software is selected. It lies in a handful of decisions about process, data, scope and governance, and in how seriously the organisation plans to keep trading while the core is replaced underneath it.

Why ERP modernisation is on every agenda

Three pressures arrive together. Older on-premise versions are moving out of mainstream vendor support, which raises cost and risk for anyone who stays put. Vendors are steering investment towards their cloud editions, so new capability appears there first. And leadership teams want to apply AI to finance, supply chain and service, which is hard when the system of record is heavily customised, poorly documented and difficult to get data out of.

Treat embedded AI features as a benefit to evaluate, not as the business case. What prepares an ERP estate for AI is unglamorous: standard processes, clean master data and accessible interfaces.

Doing nothing is now a decision with its own cost, and it should be made deliberately. Confirm the actual support dates and commercial terms for your products with your vendor, because they vary by product and version and they change.

The decisions that matter more than the software

ERP programmes are won or lost on choices made before vendor selection.

• Clean core or custom core. Two decades of customisations encode how your business actually works, and many of them exist because nobody challenged a process at the time. Modernisation is the rare chance to standardise. Organisations that carry every customisation across pay for them at each upgrade, indefinitely. Keep the few that are a real source of advantage, and build those outside the core where you can.
• Process before platform. Define the target operating model first, then configure the system to it. Programmes that let an implementation partner's template define how the business runs tend to discover the consequences a few years later.
• Data is half the programme. Master data quality, ownership and migration are routinely under-funded and are a common source of go-live incidents. Treat data readiness as a workstream with its own leader, its own plan and an early start.
• Phased beats big-bang. Sequencing by geography, business unit or process domain spreads cutover risk and lets the programme learn. A big-bang go-live can be right for a small, simple organisation. For most, it concentrates risk in a single weekend.
• Integration by design. An ERP sits at the centre of dozens of interfaces. Deciding early to connect through governed APIs, as set out in our piece on API-first integration strategy, avoids rebuilding the old tangle around a new core.

Keeping the business running during ERP modernisation

The quiet success factor is dual-running discipline. For months, sometimes longer, the organisation operates an old world and a new one side by side, and ordinary business does not pause to make room.

• A freeze policy on legacy change. Agree what may still be changed in the old system, who approves exceptions, and how each approved change is replicated in the new design. Without this, the target moves every week.
• A synchronisation strategy. During phased rollouts, some units are live on the new platform while others are not. Decide how orders, stock, intercompany transactions and reporting will work across both, and test it as seriously as the new system itself.
• Honest capacity planning. The programme needs your best operational people at exactly the moment operations needs them most. Backfill them properly, and early. Asking them to do both jobs is the most common false economy in ERP.
• A cutover calendar the business owns. Avoid year-end, peak season and major customer events. Rehearse cutover more than once, with a tested route back.
• Support that outlasts go-live. Plan an extended period of heightened support and expect a temporary dip in productivity. Declaring victory on day one is how small issues become lasting workarounds.

An ERP programme is an operating-model transformation with a software delivery attached. Fund and govern it accordingly.

Governance and people

Because the programme changes how the business operates, it needs business ownership. Process owners with real authority should make design decisions, with a steering group that resolves cross-functional disputes quickly. When IT is left to arbitrate between finance and operations, decisions drift and customisation creeps back in.

Independent programme management and assurance matters here. The implementation partner reports on its own progress, and its commercial interests are not identical to yours. Someone on your side of the table should be testing the plan, the readiness criteria and the go-live decision.

Adoption deserves the same rigour. People who have used the same screens for fifteen years will not change how they work after one training session. Role-based training, super-users in each team and visible leadership involvement all matter, and so does pacing, a point we develop in change fatigue and sustainable transformation.

Questions to ask before you commit

• What business outcomes justify this? Ask for outcomes stated in operational terms, such as faster close, better inventory visibility or lower cost to serve, not "a modern platform".
• Which customisations will we retire? Ask for a list with named owners who have agreed to standard process, and a short list of exceptions with a justification for each.
• Who owns the data? Ask who is accountable for customer, supplier, product and finance master data today, and who will be after go-live.
• Who is being released, and who backfills them? Ask for names, not percentages of time.
• How do we run the business during transition? Ask to see the freeze policy, the synchronisation design and the cutover rehearsal plan.

Common questions

How long does an ERP modernisation take?

It depends on the size and complexity of the organisation, the number of entities and countries, and how much process standardisation is involved. A focused mid-market programme is typically measured in many months, and a multi-country enterprise rollout in years. Be wary of any estimate given before scope, data condition and customisation have been assessed.

Should we move our existing ERP to the cloud as it is, or re-implement?

Moving as-is is faster and preserves what people know, but it also preserves every customisation and workaround. Re-implementing on standard processes costs more effort up front and tends to lower the long-term cost of ownership.

What is the biggest risk in an ERP programme?

Rarely the software. The recurring risks are poor data, unresolved process decisions, key people stretched across two jobs, and a go-live date defended after the evidence says the business is not ready. All four are governance matters, which is why independent assurance earns its place.

Where Ganexa can help

Ganexa's enterprise application platforms practice guides ERP modernisation from case for change through go-live: operating model design, clean-core governance, vendor and partner selection, data readiness and programme assurance, supported by organisational change and adoption work so that the new system is actually used. If an ERP decision is approaching, book a free consultation.