Your VP of Operations just forwarded another complaint. Three shop floor supervisors spent Tuesday morning re-keying the same work order into a spreadsheet because logging one transaction in the ERP takes twelve clicks. Meanwhile, your IT director is holding a proposal for a full ERP replacement: eighteen months, seven figures, and a promise that this time it will finally fix things.
You’re stuck choosing between a system your team routes around and a project that’s statistically more likely to fail than succeed. Get this wrong and you either keep bleeding hours to workarounds, or you bet the operation on a multi-year rebuild with a documented 55 to 75% chance of missing its goals.
Here’s the piece nobody hands you before that decision: a diagnostic test that tells you whether you have a UX problem or a capacity problem, real costs and timelines for a web app vs. ERP replacement, the risks that don’t make it into the vendor deck, and a phased rollout plan you can hand your team on Monday. I’ve run this diagnostic with manufacturing and distribution operators who were one signature away from a replacement they didn’t need, and a few who genuinely did.
Run This Diagnostic Before You Approve an ERP Replacement
The fastest way to tell a UX problem from a capacity problem: ask whether the ERP can technically do the task, even if badly. If it can, and the complaint is about screens, click counts, mobile access, or training, you’re looking at a workflow layer problem that a web app fixes in weeks. If the system genuinely cannot handle the task at all, that’s a capacity problem, and no interface layer changes that.
Walk your loudest complaints through this checklist:
- Does the ERP already contain the data and the transaction type, just buried behind too many fields or screens? UX problem.
- Would a simpler, task-specific screen fix most of the complaint, even if the underlying ERP logic stayed identical? UX problem.
- Are people building spreadsheets around the ERP because it’s slow or confusing, not because it’s missing a feature? UX problem.
- Has the business outgrown what the platform can physically process: order volume, SKU count, concurrent users, entity count? Capacity problem.
- Is your vendor sunsetting support, or does a required certification (traceability, quality, financial) sit outside what the platform can do? Capacity problem.
If your list is mostly UX symptoms, you’re a strong candidate for a web layer, not a replacement. We’ve written a deeper walkthrough on diagnosing what’s actually broken in your ERP if you want to go further before committing either way.
What UX Friction Actually Costs on the Shop Floor
Operators don’t avoid the ERP because they dislike change. They avoid it because the screens don’t match how the work actually happens. Research into ERP rollouts consistently finds the same pattern: shop floor constraints go unaddressed during configuration, testing skips real user scenarios, and within a week of go-live, planners are back on spreadsheets and inventory staff stop trusting system quantities.
That gap has a name: shadow IT. When a system is too slow or too rigid for daily work, people build their own version of it in Excel, and now you have two sources of truth that quietly drift apart. It’s the exact visibility gap that keeps supervisors walking the floor with a clipboard instead of trusting what’s on screen.
The fix doesn’t always require touching the ERP core. Deloitte documented a case where a forklift manufacturer with $1.5 billion in annual revenue rebuilt only the plant maintenance interface for its existing SAP system, using a mobile-first UI layer instead of replacing the ERP. The result was a 10% annual productivity improvement worth roughly $150,000 in yearly savings, delivered by fixing the interface, not the system underneath it. That’s the mechanism behind operator-first dashboard design: the ERP kept doing its job, people just finally got a screen built for how they actually work.
Web App vs. ERP Replacement: The 5 Situations Where Replacement Is Actually Right
None of this means you should never replace an ERP. It means replacement should solve a capacity problem, not a UX complaint. Five situations genuinely call for it:
- A real transaction volume ceiling. The platform physically cannot process your current order, SKU, or concurrent-user load, no amount of interface work changes that.
- End-of-life vendor support. If your vendor is sunsetting the platform or its infrastructure, you’re not choosing between UX and capacity, you’re choosing between replacing now on your terms or later in an emergency.
- Multi-entity consolidation after M&A. Merging plants running incompatible systems onto one platform is a data-model problem a web layer can’t paper over.
- A certification or compliance workflow the platform can’t support. Pharma, aerospace, and food traceability requirements sometimes demand functionality no interface layer can fake.
- A fundamental process mismatch. A make-to-stock ERP forced onto job-shop or engineer-to-order work will keep breaking regardless of how good the screens look.
If none of these apply to you, keep reading. If two or more do, your energy is better spent scoping a replacement business case than a pilot web app.
Web App vs. ERP Replacement: What Each Path Actually Costs
Cost and timeline ranges vary by vendor and scope, but commonly cited 2026 industry figures make the gap clear enough to plan around:
| Path | Typical Year-1 Cost | Typical Timeline | What It Actually Fixes |
|---|---|---|---|
| Full ERP replacement (SAP S/4HANA tier) | $500K to $2M ($1.5M to $6M five-year TCO) | 12 to 24 months | Capacity, compliance, data-model problems |
| Full ERP replacement (NetSuite, Dynamics 365 tier) | $90K to $500K ($360K to $2M five-year TCO) | 6 to 12 months | Same, with less customization headroom |
| Web app layer on top of existing ERP | $25K to $150K | 8 to 16 weeks | UX, workflow friction, adoption |
The web app path doesn’t compete with the platform tiers above, it solves a different problem for a fraction of the cost. That’s exactly why running the diagnostic first matters: paying replacement money to fix a UX complaint is the expensive mistake, not the software choice itself.
Why 55 to 75% of ERP Replacements Miss Their Goals
This isn’t a scare number, it’s a documented pattern across thousands of implementations. Gartner and Panorama Consulting both put the ERP implementation failure rate in the 55 to 75% range industry-wide. A 2026 analysis of more than 2,400 discrete manufacturing implementations found a 73% failure rate specifically for that segment, with average budget overruns reaching 215%.
Look at the root causes and the pattern gets sharper: inadequate change management drives 42% of failures, poor data migration drives 38%, and inexperienced implementation teams drive 35%. Separate research from Prosci found that human and organizational factors matter roughly six times more than technical factors in whether an ERP delivers value. None of these root causes are about missing software features. They’re about the disruption of touching the core system at all.
A web layer sidesteps most of that risk by design. It doesn’t migrate your master data, it doesn’t require retraining every role in the company, and it doesn’t touch the system of record. You’re not avoiding the risk of replacement projects by luck, you’re avoiding it because the web app never triggers the failure conditions in the first place.
How a Web Layer Sits on Top of Your ERP Without Becoming a Second System
The pattern that makes this work is well established in enterprise software: an integration hub sits between the ERP and the web app, and the ERP stays the single source of truth for every master record. The web app never creates a customer, vendor, or item master, it only reads and writes transactional data through the ERP’s API.
Concretely, that means:
- The web app calls the ERP’s API to pull the data it needs (open work orders, inventory counts, quality checkpoints).
- Any transaction a user completes in the web app posts back to the ERP through the same API, not into a separate database.
- Master data (customers, vendors, items) lives in exactly one place, the ERP, full stop.
This is the same architecture behind proven ERP integration patterns already used across manufacturing software, and it’s why a well-scoped pilot doesn’t need to reinvent anything. If you want the engineering detail down to the API level, we’ve published a full technical spec for a production monitoring web app built on exactly this pattern.
The Governance Rules That Keep It From Turning Into a Shadow ERP
A badly governed web layer creates the same problem it was supposed to solve: a second system nobody fully trusts. The fix is a short list of rules, agreed before the pilot starts, not after something breaks.
| Risk | Governance Rule |
|---|---|
| Web app starts storing its own item, customer, or vendor records | Master data lives in the ERP only. The web app reads it, it never creates it. |
| Changes get made to the web app without IT visibility | Schema and field changes go through the same change control process as ERP changes. |
| Nobody owns the tool once the pilot ends | A named systems owner is assigned before go-live, not scrambled together after. |
| No plan for what happens when it breaks | Support model and response SLA are written into the pilot charter, not improvised later. |
Deciding where a heavier system like an MES fits versus a lighter web layer matters here too. If you’re weighing that boundary, our guide to composable MES and production efficiency walks through where each tool earns its place.
A Phased Rollout Plan: Pilot, Prove, Expand
Skip the temptation to start with your most complex, mission-critical process. That’s where you go third, not first.
- Weeks 1 to 2: Pick one bounded, painful workflow. Strong candidates include digital work instructions or quality control checkpoints, both narrow enough to scope cleanly and visible enough to prove value fast.
- Weeks 3 to 8: Build and test against the ERP’s API, with zero new master data created outside it.
- Weeks 9 to 12: Run the web app in parallel with the existing process. Track two or three hard metrics: time per transaction, error rate, and voluntary adoption (are people choosing to use it, or being forced to?).
- Week 12 checkpoint: Make the expand or kill decision based on those metrics, not on how the meeting felt.
- Months 4 to 6: Expand to a second workflow, only after the first one is stable and the metrics hold without hand-holding.
What About “Now We Have Two Systems to Maintain”?
This objection is fair, and it deserves a straight answer instead of a dismissal. Yes, a web app is another codebase, another deployment, another thing IT has to know about. That’s a real cost.
But compare it honestly to the alternative. A poorly scoped web layer with no named owner is a maintenance headache. A failed or over-budget ERP replacement is a multi-year maintenance headache with your core operations tied up in it. If you can’t commit to a named systems owner and a change control process before the pilot starts, that’s a legitimate reason to wait, not a reason to default to full replacement instead.
Frequently Asked Questions
How do I know if my ERP problem is UX or capacity?
Ask whether the system can technically complete the task, even badly. If yes, it’s a UX and workflow problem: look at your screens, click counts, and mobile access first. If the system genuinely can’t handle your transaction volume, entity count, or a required certification, that’s a capacity problem no web layer can solve.
Is a web app cheaper than replacing an ERP?
Usually, by a wide margin. Focused enterprise web app pilots commonly run $25,000 to $150,000 over 8 to 16 weeks, compared to $500,000 or more and 12-plus months for a large ERP platform replacement. Exact cost still depends on integration and role complexity on either path.
How long does a full ERP replacement actually take?
Commonly cited industry ranges put mid-size and enterprise ERP replacements at 12 to 24 months from selection to stable go-live. Cloud platforms like NetSuite or Dynamics 365 tend toward the shorter end, while large platforms like SAP S/4HANA tend toward the longer end.
Can a web app replace ERP screens without replacing the ERP itself?
Yes. A web layer sits on top of the ERP through its existing API, presenting a simpler, task-specific screen for something like receiving, work order logging, or quality checks, while the ERP keeps running the transaction and stays the single source of truth.
What happens if the web app becomes a shadow ERP?
It starts storing its own master data, drifts out of sync with the ERP, and recreates the same reconciliation mess spreadsheets caused in the first place. Named governance rules, especially “master data lives in the ERP only,” prevent this if they’re agreed before the pilot goes live, not after.
Key Takeaways
The choice between a web app vs. ERP replacement isn’t a preference, it’s a diagnosis. Most of what triggers a replacement proposal, bad screens, too many clicks, shop floor staff avoiding the system, lives in the workflow layer, not the data model, and a governed web app fixes it in weeks for a fraction of what a replacement costs. Full replacement earns its seven-figure price tag only when the problem is genuinely a capacity ceiling: volume, compliance, consolidation, or a process the platform structurally can’t represent.
Three steps to take this week:
- Run the diagnostic checklist against your team’s loudest ERP complaints and sort them into UX versus capacity.
- If it’s UX, scope one bounded pilot workflow with a named owner and a 12-week go or no-go checkpoint.
- If it’s capacity, build your replacement business case around the failure-rate data in this piece, not just vendor promises.
Which one is it for your operation: a screen your team hates, or a system that’s actually hit its ceiling?
