10 Reasons Mid-Market ERP Modernisation Programmes Stall
ERP programmes rarely fail because of software alone. Governance sequencing is usually the hidden issue.
- ERP programmes rarely fail because the software is wrong. They fail because the architectural decisions were sequenced wrong — and sequencing failures compound through every subsequent phase.
- The cost of fixing a sequencing failure rises sharply across programme phases. Recoverable for low cost at design stage. Multiplied through configuration. Far more expensive post-launch.
- The board-defensible position is not “we delivered on the SOW.” It is “we delivered the operating model the business needs.” The ten reasons below describe where the gap usually opens.
Of every transformation programme commissioned by UK mid-market boards in the last five years, ERP modernisation has the highest profile and one of the lowest completion rates against the original business case.
What gets reported when these programmes stall is almost always technical. The platform was wrong. The partner underperformed. The integration was harder than expected. The data was dirtier than expected. None of these observations are incorrect. But they are symptoms, not causes.
The actual cause, in nearly every stalled mid-market ERP programme, is architectural sequencing. The decisions that should have been made before platform selection were made after. The governance that should have been defined before configuration began was defined after. The customer operating model that should have shaped the platform was shaped by the platform.
This is not a vendor failure. The vendor delivers what the SOW specifies. It is a sequencing failure — and sequencing failures are recoverable upstream, expensive mid-build, and structurally damaging after go-live. The ten reasons below describe how the sequencing typically breaks down in mid-market ERP programmes. They appear in clusters. The earlier you can name them, the cheaper they are to fix.
The future operating model wasn’t defined before platform selection
The board approves ERP modernisation. Procurement issues an RFP. Vendors respond. The selection committee evaluates on functional fit. Implementation begins.
Nobody on the executive team has documented what the future operating model needs to look like. The vendor’s standard configuration becomes the default. By the time the gap surfaces — usually two or three months into configuration — the cost of reshaping the platform is several times what it would have been at design.
This is not a discovery failure. The vendors usually run discovery workshops. The discovery is constrained by what the current operating model looks like, not what the future one should be. Without an architectural specification of the future state, vendors cannot configure for it. They configure for the average mid-market firm in your sector. The fix is upstream. Define the commercial operating model — pricing, channels, customer journey, governance, data ownership — before the RFP is issued. The RFP then specifies what the platform must support. Vendors compete on architectural fit, not functional comparison.
Master data ownership wasn’t defined before migration began
Customer data lives in three places. Product data lives in five. Supplier data lives in two. The new ERP demands a single authoritative source for each. Nobody at executive level owns the question of which source becomes the master.
The data team is asked to resolve it. They cannot. The question is architectural, not technical. Which finance system is authoritative for customer credit limits? Which operational system owns product attributes? Which procurement system holds supplier terms? These are governance decisions that touch revenue recognition, regulatory reporting, and operational accuracy.
Resolving them mid-migration is the most expensive way. The data team builds workarounds. The new platform inherits the workarounds. Reconciliation processes appear that nobody designed. The fix is to assign architectural data ownership before migration scoping begins. Every master-data domain — customers, products, suppliers, employees, locations, accounts — needs a named owner at executive level. The owner is not the data team. The owner is the function that uses the data most authoritatively.
The implementation partner’s industry template became the design by default
Every implementation partner brings a “best practice” template configured for your sector. The template is genuinely useful as a starting point. It becomes a problem when it is treated as the design.
The template was built for the average mid-market firm in your industry. Your business is not average. Your competitive advantage — the operational practices that distinguish you from competitors — does not appear in the template. If the configuration follows the template, your competitive advantage either gets configured out, or sits as a backlog of change requests behind the template.
This pattern is particularly visible in retail and telecoms, where partners have deep industry templates that work well for generic businesses and poorly for distinctive ones. The architectural discipline is to use the template as a baseline against which your specific deviations are explicit and named. Each deviation is a configuration cost. Each one is also an architectural choice. The choices need to be made by the business, not by the partner.
ERP programmes rarely fail because the software was wrong. They fail because the architectural decisions were sequenced wrong.
Finance and operations didn’t agree on the chart of accounts before configuration
Trivial-sounding. Devastating in practice. The chart of accounts is the spinal column of the ERP. It determines how transactions are recorded, how reports aggregate, how performance is measured.
In a well-architected programme, finance and operations agree on the chart before configuration starts. The new chart reflects how the business should be measured going forward — which dimensions, which hierarchies, which mappings to statutory reporting. Both functions sign it. The platform is configured against it.
In a poorly sequenced programme, the chart is configured against finance’s current view, and operations discovers the gaps later. Operations needs cost centres that finance didn’t define. Finance needs profit centres that operations didn’t anticipate. Reconciling the two requires reworking configurations that have already been built around the original chart. The reconciliation also produces audit-trail complexity that compounds across financial close cycles — visible to the board and the auditors for years afterwards. The architectural discipline is straightforward. Lock the chart before configuration. Both functions sign. No exceptions.
Tax, compliance and regulatory requirements were treated as a configuration phase
In retail and telecoms especially, jurisdiction-specific regulatory requirements are not configuration tasks. They are architectural inputs. VAT and intrastat handling for multi-country retail. Universal service obligations and number portability for telecoms. Consumer Duty for any retailer with financial services exposure.
These get treated as configuration items in many programmes — handled by the tax or compliance team alongside the implementation, as a parallel workstream. The reality is that the regulatory architecture needs to shape the platform configuration, not run alongside it. A platform configured without the regulatory architecture in place rarely accommodates it well when it arrives.
The cost surfaces in two ways. Technical rework when the regulatory requirements clash with the configured platform. And regulatory risk — where the platform is technically live but cannot demonstrate the controls regulators expect. The architectural discipline is to bring tax, compliance and regulatory owners into the design phase, not the deployment phase. Their requirements need to be architectural inputs. Their sign-off needs to be on the design, not on the deployment. This is governance work, not engineering work.
Naming the sequencing pattern is the first step. Validating your foundations is the next.
The free Commercial Readiness Assessment positions your organisation across six dimensions of commercial architecture. About ten minutes. No payment. No sales call.
Take the Free Assessment →The change management plan assumed adoption would follow training
Adoption does not follow training. Adoption follows engagement. Training is a small part of engagement. The mid-market change management budget routinely under-resources the engagement side.
A typical mid-market ERP programme budgets change management as a training programme — a few days of classroom or e-learning per user, delivered by the implementation partner. The reality of changing how an operational team works is significantly more substantial. It involves rebuilding informal routines, redefining team accountabilities, renegotiating cross-functional handoffs, and managing the inevitable productivity dip that follows any system change.
When this work is under-resourced, two failure modes appear. Either adoption stalls — the team continues to use the old system or builds workarounds around the new one — or adoption is forced through, with significant productivity loss and a spike in customer-facing errors during the first six months. Both appear in the year-end review as “transformation impact.” Both are recoverable with architectural change management. Neither is recoverable through more training.
Architectural decision made before RFP. Cost is the design effort itself.
Mid-build correction. Change request at consultancy rates plus retest.
Late correction. Integration rework, data re-migration, regression testing.
In-production correction. Operational disruption plus architectural rework.
Based on the Boehm rework curve, observed across decades of enterprise software programmes.
Data migration was treated as IT work, not business work
Cleaning, mapping and reconciling data is business work that IT enables. It is not IT work that the business consumes. Treating it as IT work — handing the migration to the data team and expecting them to deliver clean, mapped, reconciled data — produces the most common late-stage ERP failure.
The data team can move data. They cannot decide what is authoritative. They cannot resolve duplicates without business judgement. They cannot map historical categorisations to new ones without business policy. Every one of these is a business decision dressed up as a technical task.
In a well-architected programme, the data migration plan is owned by the function that uses the data. Finance owns financial data migration. Operations owns operational data migration. The data team enables. The business decides. In poorly sequenced programmes, the data team carries decisions they are not authorised to make. They escalate. The escalation goes through programme management. Programme management resolves them by deferring to defaults. The defaults bake assumptions into the new platform that surface as problems months later.
There was no defined ownership of post-launch process exceptions
The system goes live. Exceptions appear. Customers cannot complete orders. Suppliers cannot be paid. Stock numbers don’t reconcile. Compliance reports won’t generate.
Each exception is real and operational. None of them have a defined owner. The team that built the platform — usually a project team — was disbanded or redeployed at go-live. The operational team is overwhelmed. Exceptions accumulate in a backlog.
This is the period that determines whether the programme succeeds or stalls. A well-architected programme has a defined post-launch operations function — sometimes called a centre of excellence, sometimes called a platform team — with the authority and resources to resolve exceptions as they arise. A poorly sequenced programme treats exceptions as one-off issues to be solved when they appear, by whoever is available. The cumulative effect of unresolved exceptions is platform erosion. Workarounds appear. Trust in the system drops. The business reverts to old habits where possible. Adoption stalls. The architectural fix is to define the post-launch operations function before go-live, not after.
Five questions to ask before signing the ERP implementation SOW
- What is the documented future-state operating model the platform will support, and who has signed it?
- Which master-data domains have named executive owners, and have those owners agreed on authoritative sources before migration scoping?
- What is the regulatory architecture the platform configuration must accommodate, and which compliance owners have signed the design — not just the deployment plan?
- What is the size, structure, authority and funding of the post-launch operations function — through which fiscal years?
- How is the benefits case structured: as a project case (cost vs savings) or as an operating-model case (cost vs operational change vs savings)?
The benefits case was a project case, not an operating-model case
The business case approved by the board usually shows project investment against forward savings or capability gains. Implementation cost versus benefits realisation. The financial logic is sound. The structural problem is that the business case rarely shows how the operating model changes to produce the savings.
Where does the saving come from? Faster month-end close. Reduced manual reconciliation. Better stock accuracy. Improved decision-making cycle times. Each of these requires specific operational change. Without naming the change — and assigning ownership for delivering it — the saving exists only in the business case, not in the operating model.
This is the gap between project completion and benefits realisation. The platform goes live. The project closes. The benefits don’t materialise — because the operating-model change supposed to deliver them was never explicitly funded, owned, or measured. The architectural fix is to design the benefits case as an operating-model case, not a project case. Every saving needs a named operational owner. Every owner needs explicit accountability for delivering the operational change that produces the saving.
Go-live was treated as completion, not midpoint
The hardest six to twelve months of an ERP programme is after go-live, not before. Mid-market business cases routinely treat go-live as the endpoint. The project team is reassigned. The implementation partner’s engagement ramps down. The change management budget is exhausted. The post-launch operational function — if it was even defined — is under-resourced.
What follows is predictable. Adoption stalls in pockets. Exceptions accumulate without clear ownership. The benefits case starts to slip. Senior leadership attention moves to the next priority because the programme is “done”. By the time the slippage is visible at board level, the cost of remediation is several times what it would have been when the gap first appeared.
A well-architected ERP programme treats go-live as the midpoint of a two-to-three-year operating-model transformation. The first half is design, build, and go-live. The second half is adoption, stabilisation, exception resolution, and benefits delivery. Both halves are explicitly budgeted, owned and tracked. This is the single most important sequencing decision for any board approving an ERP programme. Funding the first half without the second is the most common failure pattern in mid-market ERP modernisation.
What this means for the boardroom
These ten reasons describe how mid-market ERP programmes most commonly stall. They share a single underlying cause. Architectural decisions that should have been made before platform selection were made after. The platform was selected before the operating model was defined. Configuration began before the master data was owned. Go-live happened before the post-launch function was funded.
This is sequencing, not technology. The technology in any modern ERP platform is genuinely capable. What determines whether the programme delivers is the architectural sequencing that surrounds it — and the discipline to make architectural decisions in the correct order, at the correct phase, with the correct ownership.
The economic argument is compelling. A sequencing error at design stage costs an order of magnitude less to fix than the same error at configuration. An error at configuration costs an order of magnitude less than the same error at go-live. The compounding works in both directions. The earlier you act, the cheaper. The later, the more expensive.
This is where commercial-first transformation pays back. Where the operating model is defined upstream, the platform configures cleanly to it. Where it is undefined, the platform imposes its defaults, and the ten reasons above accumulate. The starting point is naming where you currently sit.
Are your ERP transformation foundations operationally aligned?
The free Commercial Readiness Assessment positions your organisation across six dimensions of commercial architecture. You receive a personalised report naming where the operating model is most defined, where it is most exposed, and which of the ten reasons above are most likely to surface in your programme.
Take the Free Assessment →About 10 minutes · No payment · No contract · No sales call