Most searches for an ERP alternative are really searching for a shortlist. That is the wrong artifact. Two trades businesses of identical size can need completely different answers, because one runs standardized service calls against a published price book and the other runs three customer models with negotiated contract pricing. The first should buy a product. The second probably cannot. This guide compares categories rather than named vendors, because the category decision determines whether the project works.
Start with the operating model, not the shortlist
Before evaluating anything, write down how work actually moves through the business: how a job is created and scheduled, what a technician sees on site, what has to be captured before the truck leaves, how the price is determined, and how that becomes an invoice. Do it by following real jobs, not by asking managers to describe the process. The gap between the two is usually where the current system is failing.
Then separate genuine requirements from habits the old platform created. Much of what teams call a requirement is a workaround that hardened into procedure: a duplicate entry step that exists because two modules never talked, a spreadsheet that exists because someone could not get a license. Carry those into the evaluation and you will score every option against a distorted picture of the business.
Two questions decide the category. How much of your operating model is genuinely unusual rather than merely unexamined? And how much operational risk can you carry during a transition? Can dispatch be degraded for a week, or is that a payroll-and-reputation event? Answer those honestly and most of the six categories below eliminate themselves.
Six categories, not a vendor ranking
Each of these is the correct answer for someone. Each of them fails in a specific, predictable way when applied to the wrong operation.
1. Stay and reconfigure
The cheapest credible option is almost always to keep the platform and fix the implementation. A large share of ERP dissatisfaction traces to configuration decisions made years ago by a partner who did not understand field work, not to the product itself. Cleaning up the item and customer master, rebuilding the workflow states, and giving field staff a usable mobile path is typically a fraction of a replacement and carries almost no continuity risk. It fits businesses whose complaints are about how the system was set up rather than what it can represent. It does not fit businesses whose objection is structural: per-seat pricing that keeps technicians out of the system, or a data model that cannot express the way they sell. The failure mode is spending a year improving a system you were always going to leave, then arriving at the same decision with less runway.
2. A vertical field service platform
Purpose-built field service products exist because dispatch, scheduling, mobile capture, price books, and job-to-invoice flow are a well-understood problem. For a business running conventional service and install work, these products encode more operational thinking than you would be able to specify from scratch. This is the right answer for most trades businesses, and we say so on engagements regularly. It does not fit when your revenue model or customer structure sits outside what the category represents: multi-entity structures, unusual contract or membership pricing, or work that is really project delivery wearing a service ticket. The failure mode is configuring around the edges until the platform carries customizations no upgrade survives, at which point you own the maintenance burden of custom software without owning the software.
3. A general ERP with a field service module
If financial consolidation, inventory, and manufacturing or distribution are central to the business, keeping everything inside one general ERP has real value: one ledger, one customer record, one reporting surface. This fits companies where the back office is the complex part and field service is a supporting function. It does not fit companies where the field is the business, because field service modules in general ERPs tend to be strongest at the accounting end and weakest at the truck. The failure mode is a good general ledger sitting on top of a mobile experience the crews route around, which recreates the problem you were solving: data captured on paper and re-entered at the office. Cost shape is the highest of the packaged options, because implementation labor usually exceeds licensing.
4. A composable stack of best-of-breed tools
Pick the best scheduling tool, the best accounting package, the best CRM, and join them with integration. Each component fits its job well, each can be replaced independently, and no single vendor holds the whole operation. This fits organizations with someone internally who owns systems and is accountable for the seams. It does not fit organizations without that person, because the integration layer is a real system that needs error handling, retries, monitoring, and an owner. The failure mode is silent divergence: a sync fails on a Tuesday, nobody notices until month end, and two systems disagree about what was billed. Component subscriptions look cheap in a spreadsheet; the integration build and its ongoing care are the cost line most often left out.
5. A no-code bridge stack as a deliberate interim step
Sometimes the binding constraint is a date. A renewal deadline, an acquisition, or a platform sunset forces a move before a considered replacement can be designed. A bridge stack (an operational database, a front end over it, and an automation layer between systems) can carry core job management, dispatch, mobile field updates, and customer records within weeks. On one trades services engagement we did exactly this with Airtable, Stacker, and Make.com ahead of a renewal deadline. It fits when the deadline is real and the alternative is another year of a platform you have already decided to leave. It does not fit as a permanent architecture: record limits, permission granularity, and automation reliability become constraints as volume grows. The failure mode is the bridge becoming the destination because it works well enough that nobody funds the next phase.
6. A purpose-built platform
Building means the data model, the workflow, and the field experience are shaped around how the business actually runs, with no per-seat calculation deciding who gets access. It fits when the operating model is the competitive advantage, when several distinct customer or pricing models have to coexist, or when integration with accounting, communications, and fleet systems needs to be a first-class capability rather than a connector you rent. It does not fit a business whose processes are conventional and simply badly configured. You would be paying to rebuild something the market already sells. The failure mode is scope: replacing every function at once instead of moving the highest-value capability first and retiring the old system only after users, data, integrations, and a fallback plan are ready.
The categories side by side
| Category | Fits | Does not fit | Cost shape | Failure mode |
|---|---|---|---|---|
| Stay and reconfigure | Complaints are about setup, not structure | Per-seat or data-model constraints are the real objection | $30K–$120K one-time, licensing unchanged | A year spent improving a system you were always leaving |
| Vertical field service platform | Conventional dispatch-to-invoice work | Multi-entity, unusual contract or membership pricing | Per-seat subscription plus $25K–$100K implementation | Customization creep that no upgrade survives |
| General ERP with a field module | Back office is the complex part | The field is where the business happens | Highest packaged option; implementation exceeds licensing | Crews route around the mobile experience |
| Composable best-of-breed stack | You have an internal systems owner | Nobody is accountable for the seams | Low subscriptions plus $60K–$200K integration build | Silent sync divergence found at month end |
| No-code bridge stack | A hard deadline forces a move now | You need a permanent architecture | $40K–$90K build, 6–10 weeks, modest tooling fees | The interim step quietly becomes the destination |
| Purpose-built platform | The operating model is the advantage | Conventional processes that are merely misconfigured | $250K–$1.5M phased, plus 15–25% per year after | Replacing everything at once instead of in stages |
Compare on five-year cost, not subscription price
Whichever categories make your shortlist, price them over five years and include the lines that never appear in a vendor quote: implementation and reimplementation, paid connectors, mandatory partner hours, version upgrades, and the labor cost of the manual workarounds people invent to route around a bad fit. That last line usually decides the comparison, and it almost never appears in a business case because nobody invoices for it.
- Per-seat cost multiplied by everyone who should have access, not everyone who currently does
- Implementation and any partner hours required to keep the configuration supported
- Connectors, add-on modules, and integration platform fees billed separately from the core subscription
- Hours per week spent on duplicate entry, reconciliation, and chasing missing field data
- The cost and elapsed time of leaving, including whether you can export your own history
When a phased path beats a single decision
The categories are not mutually exclusive over time. A business under renewal pressure can move to a bridge stack, use that period to observe how the work runs and clean up legacy data with real users, and only then decide whether the destination is a vertical product or a purpose-built platform. That sequence costs more than picking correctly on the first try, and considerably less than a twelve-month build specified against requirements nobody validated.
A trades services business facing a six-figure ERP renewal moved core dispatch, field updates, and invoicing onto a bridge stack in six weeks, avoiding roughly $100,000 in renewal cost while the real platform was designed around how the work actually ran.
What makes this work is treating each stage as reversible. Move the highest-value capability first, run it alongside what exists, validate with the people doing the job, and retire the old system only once data, integrations, users, and a fallback path are ready. A cutover you can undo is a decision. A cutover you cannot undo is a bet.
How to decide in four weeks
- 1
Follow five real jobs end to end, from intake to paid invoice, and write down every place information is re-entered or leaves the system.
- 2
Mark each pain point as configuration, licensing, or data model. Configuration problems argue for staying; data model problems argue for leaving.
- 3
Name the two or three things about your operating model that a packaged product would have to represent. If you cannot name any, buy a product.
- 4
Price your top two categories over five years, including workaround labor and exit cost, using the checklist above.
- 5
Establish whether a deadline is forcing the schedule. If one is, plan the interim step explicitly and fund the phase after it at the same time.
- 6
Run a two-to-four week assessment before committing to a build. It should end in a costed sequence and a recommendation you can act on, including the recommendation not to build.
Common questions
- How do I know whether to replace our ERP or fix the implementation?
- Sort your complaints into three buckets: configuration, licensing, and data model. Configuration problems (bad workflow states, a messy item master, awkward screens) are usually fixable in place for a fraction of a replacement. Licensing and data model problems are structural, and no amount of reconfiguration resolves them.
- Is a vertical field service platform better than building custom software?
- For most trades businesses running conventional service and install work, yes. Those products encode years of operational thinking about scheduling, price books, and mobile capture that you would otherwise have to specify from scratch. Custom becomes the better answer when your customer structure, pricing, or contract model sits outside what the category represents.
- How long does it take to move off an ERP?
- A no-code bridge stack that carries core job management, dispatch, and field updates can be live in six to ten weeks. A vertical platform implementation typically runs three to six months depending on data migration. A purpose-built platform is delivered in phases across six to eighteen months, with the first useful release well before the end.
- What is the biggest hidden cost in any of these options?
- Data migration, followed closely by the labor cost of manual workarounds in the option you keep. Migration cost tracks data quality rather than data volume. Twenty years of duplicate customers, orphaned records, and dates stored as text is more expensive to move than a much larger clean dataset. Ask every vendor how migration is priced; vague answers predict overruns better than any other signal.
- Can we use a no-code stack permanently instead of replacing the ERP?
- Some businesses do, and for small operations with simple workflows it can hold. It stops working as record volumes grow, permission requirements get finer, and automation reliability starts to matter for billing. Treat it as an interim step by default, and fund the decision about what comes next at the same time you fund the bridge.
- What should a serious evaluation produce?
- A mapped picture of how the work actually runs, an inventory of systems and data with owners, a five-year cost comparison of the two most plausible categories, and a costed delivery sequence. It should be finished in two to four weeks. If an evaluation runs longer than that without producing a recommendation you can act on, it has become a project of its own.