Nearly every ERP replacement conversation starts with a list of complaints. The list is usually accurate and usually beside the point. Slow screens, ugly reports, a month-end close that takes eleven days, and a mobile app the field team refuses to open all describe pain, not cause. Some of them mean the platform is wrong for the business. Most of them mean the platform was implemented badly, configured for a company you no longer are, or handed to users with two hours of training and no follow-up. Replacing an ERP costs six or seven figures and eighteen months of organizational attention. Before you spend that, it is worth knowing which kind of problem you have.
This page is a diagnostic. It separates the symptoms that genuinely justify replacement from the ones that do not, and gives you a way to score your own situation before anyone builds a business case around it.
The distinction that matters: structural versus fixable
A structural problem is one the vendor cannot solve for you at any reasonable price, because it comes from a decision baked into the product. The data model, the licensing model, and the extension model are structural. You do not configure your way out of them. A fixable problem is one where the product is capable of the thing you need and is simply not doing it: the wrong fields, the wrong permissions, an integration nobody maintained, a process that was designed around a constraint that expired three years ago.
The reason the distinction matters commercially is that fixable problems are between one and two orders of magnitude cheaper to solve. A configuration and process remediation engagement runs tens of thousands of dollars. A replacement runs hundreds of thousands and consumes your operations team for a year. If you treat a fixable problem as structural, you pay the second number to get the first result, and you frequently rebuild the same bad process in new software.
Four conditions that justify replacement
These are the signals we treat as genuine. They come from engagements where replacement turned out to be the right call, and each one shares a property: it survived a serious attempt to fix it in place.
The data model contradicts the operating model
This is the strongest single signal. It shows up when the central object of your business has no honest representation in the system, so people encode it somewhere else. A service business whose work is a multi-visit job gets an ERP that models a sales order. A company with three genuinely different customer types and three pricing structures gets a platform that supports one. The tell is a custom field named something like Type2 or a text field where people write instructions for the next human. When the system cannot hold the shape of the work, every downstream report is a reconstruction, and no amount of configuration fixes it.
Licensing excludes the people who do the work
Per-seat pricing becomes structural the moment it changes who gets access. If technicians, warehouse staff, or part-time schedulers are kept out of the system because a seat costs more than their marginal contribution, the company has quietly decided that its system of record will always be incomplete. Someone else re-enters their work later, from paper or a text message. This cost is real, grows with headcount, and does not appear on any invoice. It is also the one constraint a vendor will never negotiate away permanently.
The workarounds have become the actual process
Spreadsheets exist in every company and most of them are fine. The signal is not the existence of a spreadsheet; it is dependency. When a shared workbook is the only place a schedule lives, when three people have the same login, when an operation cannot run if a specific person is on vacation, the ERP is no longer the system of record. You are paying enterprise licensing for a filing cabinet while the business runs on undocumented artifacts with no audit trail and no backup.
Change has become economically irrational
In a healthy system, a modest process change is a modest cost. When a new field, a new approval step, or a new report requires a specialist partner, a five-figure statement of work, and a wait measured in months, the platform has stopped being an asset and started being a toll. Watch what the business stops asking for. The clearest version of this signal is a backlog of improvements nobody bothers to request anymore because everyone knows the answer.
Four conditions that do not justify replacement
These come up in almost every discovery conversation and they are almost never sufficient on their own. They are worth naming plainly, because each has a cheaper fix that gets skipped when a replacement program is already in motion.
| Complaint | Usual root cause | Response before replacing |
|---|---|---|
| Nobody uses it correctly | Rollout training was one-time and role-generic; nothing reinforced it | Retrain by role against the real workflow, then measure adoption for a quarter |
| The reports are wrong | Inconsistent data entry upstream, or a report definition nobody owns | Fix entry validation and assign a named owner to each report |
| It was configured for a company we no longer are | Configuration frozen at go-live, three acquisitions ago | Scope a reconfiguration engagement; it is typically 5–10% of replacement cost |
| The executive team hates it | One or two loud stakeholders whose specific workflow was never fitted | Interview the people doing the work daily; check whether the pain is broad or narrow |
| We are missing one critical report or screen | A genuine gap in a system that otherwise fits | Build the gap alongside the ERP and keep the platform |
The fourth row deserves particular attention. A single senior stakeholder with a bad experience can generate enormous momentum toward replacement, and the momentum is very hard to reverse once a budget line exists. The corrective is cheap: spend two days with the people who use the system every day. If their complaints match the executive's, you have a real problem. If they shrug and describe a workaround they consider normal, you have a different one.
A triage score you can run in an afternoon
Score each signal honestly, with evidence rather than impression. The point is not precision; it is forcing the conversation to name specifics.
| Signal | 0 points | 1 point | 2 points |
|---|---|---|---|
| Data model fit | Core objects map cleanly to how work runs | Some workflows need custom fields to survive | The central object of the business has no honest representation |
| Access and licensing | Everyone who needs access has it | Access is rationed but the gaps are minor | People who do the work are deliberately kept out on cost grounds |
| Shadow systems | Spreadsheets are for analysis only | One or two workflows depend on a shared workbook | Operations stop if a specific undocumented file or person is unavailable |
| Cost of change | Configuration changes happen in-house within days | Meaningful changes need a partner and a few weeks | The business has stopped asking because the answer is always no |
| Remediation history | No serious fix attempt has been made yet | One partial attempt, abandoned mid-way | A funded remediation ran and the same problems returned |
| Trajectory | Fit is improving as the platform is tuned | Fit is flat while the business changes around it | Fit is degrading and licensing is rising each renewal |
The remediation history row exists to prevent the most expensive mistake in this category: replacing a system that was never actually fixed. If nobody has tried, you do not yet know whether the platform is the problem. Skipping that step is how organizations spend a migration budget to arrive at the same operating model in different software.
What replacement looks like when the score justifies it
A high score does not mean switching everything off in one weekend. The pattern that works is to move the highest-value capability first, validate it under real operating conditions, and retire the old system only once users, data, integrations, and a fallback path are all ready. That sequencing is what keeps a replacement reversible while it is still cheap to reverse.
A trades services business facing a six-figure NetSuite renewal moved job management, dispatch, mobile field updates, and invoicing onto a temporary no-code bridge in six weeks, then used the bridge period to clean legacy data and observe how the work actually ran before designing the permanent platform.
- 1
Confirm the score with the people doing the work, not only with the people who sign the invoice.
- 2
Fund one honest remediation attempt if none has happened, and set a date by which it either worked or did not.
- 3
Map current workflows and system boundaries before evaluating any replacement product.
- 4
Separate genuine requirements from habits the old platform created; a surprising share of the requirement list is scar tissue.
- 5
Move one high-value capability first and run it in parallel with the ERP.
- 6
Retire the ERP only after data reconciliation, user acceptance, and a documented rollback path are all in place.
The uncomfortable conclusion of most honest diagnostics is that the platform stays. That is a good outcome. A reconfiguration, a role-based retraining pass, and two or three purpose-built capabilities built alongside the ERP will resolve the majority of situations that arrive described as a replacement project, for a fraction of the cost and none of the operational risk. Replacement is the right answer when the constraint is structural, has been tested, and is getting worse. It is the wrong answer when it is being used to avoid a harder conversation about process.
Common questions
- How do we know whether our problem is the ERP or our configuration?
- Ask whether the product is capable of what you need and simply is not doing it. If the capability exists and is misconfigured, unowned, or untrained, the problem is fixable and costs a fraction of a replacement. If the capability cannot exist because of how the vendor modeled the domain, priced seats, or restricted extension, the problem is structural.
- How long should an ERP last before replacement is reasonable?
- There is no useful age threshold. We have seen four-year-old implementations that were structurally wrong from go-live and fifteen-year-old ones that still fit the operation well. What matters is trajectory: whether fit is improving, flat, or degrading as the business changes around it.
- Is a bad implementation partner a reason to replace the platform?
- Usually not. A poor implementation produces exactly the symptoms of a poor platform fit, which is why the two get confused. Before concluding the product is wrong, have someone independent assess whether the configuration reflects how you operate today. That assessment typically costs less than a month of the licensing you are already paying.
- Can we replace part of an ERP instead of all of it?
- Frequently, and it is often the better answer. Keeping the general ledger and core financials while moving dispatch, field operations, or customer-facing workflows onto purpose-built software is a common and lower-risk pattern. It requires deliberate integration work and clear decisions about which system owns which data, but it avoids putting the entire operation at risk at once.
- What does an ERP replacement typically cost?
- A platform that replaces a core system generally runs $250,000 to $1.5M, delivered in phases rather than as one payment. The honest comparison is not that number against zero, but total five-year cost including the licensing, implementation partners, and manual workaround labor you would keep paying if you stayed.
- What is the most common mistake in this decision?
- Replacing a system that was never seriously fixed. The second most common is carrying the old process into the new platform, because requirements were gathered by describing current behavior rather than the underlying business need. Both are avoidable with a short discovery phase before any product is selected.