Most businesses convinced they need a full ERP need three integrations and one custom module. That costs roughly a quarter of a full build and carries a fraction of the risk.
Nobody proposes it, because it is the smallest invoice available to everyone in the conversation. ERP vendors want a licence. Implementation partners want an implementation. Custom agencies want a build.
The question that reframes it
“What is actually broken?”
Not “what would a complete system look like” — but what, specifically, costs you money today.
When people answer honestly, the list is usually short and sounds like this:
- Stock levels in the warehouse system do not match what the website shows
- Someone retypes every order into the accounting system
- Nobody can see job profitability without building a spreadsheet
- Customers ring to ask where their order is, and three people have to be asked
None of those requires replacing everything. Each is a connection that does not exist, or one report nobody can produce.
What a full ERP replacement means
Replacing your accounting, stock, CRM and operations with one unified system.
| Cost | £60,000 – £400,000+ |
| Duration | 5–18 months |
| Risk | High — Panorama found ~30% go over budget |
| Disruption | Every department, every process, all at once |
| Migration | Everything, simultaneously |
| You get | One system, one source of truth, genuine consistency |
Genuinely right when: your systems are so fragmented that nothing agrees with anything, you are at a scale where per-seat licensing across many products exceeds a build, or you are replacing something unsupported that is now a liability.
What the integration approach means
Keep what works. Connect it. Build only the gap.
| Cost | £15,000 – £60,000 |
| Duration | 6–16 weeks |
| Risk | Much lower — each piece independently useful |
| Disruption | Minimal — people keep using familiar tools |
| Migration | Little or none |
| You get | Systems that agree, without replacing any of them |
Right when: your individual systems work adequately and the pain is that they do not talk to each other — which describes most businesses that think they need an ERP.
The question to ask before anything else
“Is this system inadequate, or just disconnected?”
Almost every decision on this page follows from the answer, and people get it wrong in both directions.
Disconnected means the system does its job but nothing else knows what it did. Stock is accurate inside the warehouse system; the website simply cannot see it. The accounting package is fine; orders just arrive there by retyping. That is an integration problem and replacing the system fixes nothing.
Inadequate means the system cannot represent how you work. It has no concept of a batch, or allocation priority, or your contract pricing. No amount of connection fixes that — you would be synchronising the wrong model faster.
How to tell them apart: ask the people using it what they cannot do. “I can see it but the website can’t” is disconnection. “I have to keep a spreadsheet alongside because it won’t let me record that” is inadequacy.
The expensive mistakes:
- Treating disconnection as inadequacy — replacing a working system at full cost when £8,000 of integration would have solved it. The commonest error, and vendors have every incentive not to correct it.
- Treating inadequacy as disconnection — integrating around a system that fundamentally does not fit, accumulating workarounds until the integration layer is doing the real work badly.
A worked comparison
UK wholesaler, 30 staff. Xero for accounting, a warehouse spreadsheet, a website taking orders, a courier portal.
The pain: orders retyped into Xero. Stock in the spreadsheet, out of date by the time anyone reads it. Customers ring asking where things are. Nobody knows real margin by product line.
Full ERP replacement
- Replace Xero, the spreadsheet and the order flow with one system
- £110,000, 9 months
- Risk: migration, retraining everyone, HMRC-compliant accounting now part of the project
Integration approach
| Piece | Cost |
|---|---|
| Website orders → Xero automatically | £6,000 |
| Stock system (custom, replacing the spreadsheet) with live website sync | £22,000 |
| Courier integration + customer order-status page | £9,000 |
| Margin reporting pulling from Xero and the stock system | £7,000 |
| Total | £44,000, 14 weeks |
Every listed pain solved. 60% less cost. Xero stays — compliant, familiar, maintained by someone else.
What you do not get: one unified system. You have four things talking to each other rather than one thing. That is a genuine trade-off — more moving parts, more integration points that can break.
For most businesses at this size, it is the right trade.
When integrations are the wrong answer
Be honest about these, because the integration route is not always correct.
The underlying systems are genuinely inadequate. Integrating a bad system makes a bad system better connected. If your stock software is fundamentally wrong for how you work, connecting it does not fix that.
You would need more than about five integrations. Past that, you are building a distributed system with no central design, and the maintenance exceeds what a unified system would cost.
Something you depend on is unsupported. An integration extends its life and increases the eventual cost of replacing it.
The data model genuinely conflicts. If two systems disagree about what a “customer” or an “order” fundamentally is, syncing them creates permanent reconciliation work.
You are at real scale. Past roughly 100–150 users, per-seat licensing across several products starts to make a unified system look reasonable on cost alone.
Designing the shape before building the pieces
The legitimate criticism of the integration approach is that it can become a mess. Five years of ad-hoc connections with no design genuinely is worse than one system.
That outcome is avoidable, and avoiding it costs about a day.
Decide what owns what. For every important piece of data — customer, product, price, stock level, order — one system is authoritative and the others receive. Write it down. Most integration messes trace back to two systems both believing they own the customer record.
Decide the direction of each flow. One-way is dramatically simpler than two-way and is usually sufficient. Two-way sync should be a deliberate choice with a conflict rule, not a default.
Decide the latency each flow needs. Real-time is expensive. Nightly is cheap. Stock on a trade portal needs minutes; the accounting ledger does not. Treating everything as real-time is a common and costly default.
Draw it on one page. Boxes for systems, arrows for flows, a label on each arrow saying what moves and how often. If it does not fit on a page, you are heading toward the mess and should reconsider.
Then build in stages against that design. Each integration delivered independently, but to a shape decided in advance.
This one page is what separates a best-of-breed architecture from an accident. Insist on it before anyone writes an integration, and keep it updated.
How to tell which you need
1. List what is actually broken. Specific problems with costs attached, not “our systems are a mess”.
2. For each, ask: is this a missing connection, or a missing capability?
- Missing connection → integration
- Missing capability → build that one thing
- The system itself is wrong → replacement may be justified
3. Count the integrations needed. One to four, integrate. Six or more, reconsider.
4. Check whether any core system is genuinely inadequate rather than merely disconnected. This is the distinction people get wrong most often.
5. Model five years on both. Include licences, maintenance and the labour cost of the current workarounds.
What the hybrid looks like in practice
Four shapes we build repeatedly, with what each actually involves.
Accounting stays, operations get built. Xero or Sage keeps doing accounting and VAT. A custom operational system handles stock, jobs, scheduling or costing. One integration syncs invoices and payments. £25,000–£50,000. The most common thing we ship.
Product stays, the gap gets built. You keep an industry product that does 80% well. A custom module handles the 20% it cannot represent — your pricing rules, your allocation logic, your compliance tracking — reading from and writing to the product. £15,000–£40,000.
Everything stays, nothing agrees — so connect it. No new system at all. Two to four integrations so stock, orders, pricing and customers are consistent across what you already run, plus reporting that spans them. £12,000–£35,000. The cheapest meaningful improvement available to most businesses.
Spreadsheets replaced, the rest untouched. The critical spreadsheet becomes a proper system with permissions, history and validation, integrated with accounting. £18,000–£45,000.
What all four have in common: nothing compliance-sensitive is rebuilt, migration is small or absent, people keep using tools they know, and value arrives in weeks. The risk profile is entirely different from a full replacement.
The practical risk of integrations
Being straight about the downside.
More moving parts. Four systems and three integrations is seven things, each capable of breaking.
Vendor dependency. If Xero changes its API, your integration needs updating. In practice, major platforms deprecate with long notice — but it is real.
No single source of truth. Data lives in several places kept in sync. Well-built sync is reliable; poorly built sync creates duplicates and silent divergence.
It can become a mess. Five years of ad-hoc integrations with no design is genuinely worse than one system. Design the shape up front even if you build it in stages.
Mitigation: build integrations with proper error handling, logging and alerting, not as a one-off script. An integration that fails silently is worse than no integration, because people trust the number.
What a good integration actually contains
The difference between an integration that works for years and one that becomes a liability. Worth knowing, because the cheap version looks identical on day one.
Error handling. What happens when the other system is down, slow, or returns something unexpected. An integration without this fails silently, and silent failure is worse than no integration because people trust the number.
Retry logic with backoff. Transient failures are normal. Retrying immediately and forever makes an outage worse; retrying sensibly recovers without anyone noticing.
Idempotency. Running the same sync twice must not create two orders. This sounds obvious and is the single most common defect in hand-rolled integrations.
Logging. What synced, when, and what failed. Without it, “the stock number looks wrong” is unanswerable.
Alerting. Somebody is told when sync has been failing for an hour. Not a dashboard nobody opens — an actual alert.
Reconciliation. A periodic check that both systems agree, and a report when they do not. Drift happens; catching it in a day rather than a quarter is the difference.
A documented contract. Which fields, which direction, how often, what the authoritative source is for each field. This is what makes it maintainable by someone else.
The cheap version omits all seven. It works in testing, works for a few months, then fails quietly at the worst moment. When comparing quotes, ask which of these is included — the price difference is usually explained entirely by this list.
Migrating from the hybrid later
A fair objection: if we integrate now and need a full system in five years, have we wasted the money?
Usually not, and here is why.
The integration work is not thrown away. Whatever the eventual architecture, systems still need to talk to each other. The field mappings, the understanding of which system owns what, and the error handling all carry over.
The custom module usually survives. The part you built because no product represented it is the part no product will represent in five years either. It gets reconnected rather than rebuilt.
You arrive at the decision better informed. Five years of running integrated systems tells you exactly where the real friction is. A business commissioning a full ERP after that experience writes a far better specification than one commissioning it from a standing start.
And the data is cleaner. Integration forces consistency — two systems cannot sync if they disagree about what a customer is. That cleanup is the expensive part of any future migration, and you will have done it already.
What you do lose is some duplicated effort at the boundaries, typically 10–15% of the eventual total. Set against spending £110,000 now instead of £44,000, with a materially higher chance of overrun, that is a good trade.
Frequently asked questions
Do I need a full ERP system?
Usually not. Most businesses that think they do need their existing accounting package, two or three integrations, and one custom module for the thing no product covers. A full ERP is justified when systems are genuinely fragmented, something core is unsupported, or you are at a scale where multi-product licensing exceeds a build.
What is the alternative to ERP?
Best-of-breed systems connected by integrations, with a custom module for whatever has no product. Typically £15,000–£60,000 against £60,000–£400,000, delivered in weeks rather than months.
How much do business system integrations cost?
Typically £4,000–£12,000 per integration depending on the systems involved and whether both have modern documented APIs. Legacy systems without APIs cost considerably more.
Is it bad to have lots of separate systems?
Not inherently. It is bad when they disagree, when data is retyped between them, and when nobody can get a view across them. Those are integration problems, not architecture problems.
Can I keep Xero and still fix my operations?
Yes, and usually you should. Xero is good at accounting and HMRC-compliant. Keep it and build the operational layer that sits above it, properly integrated.
When do integrations become the wrong answer?
Past roughly five integrations, when a core system is genuinely inadequate rather than just disconnected, when data models fundamentally conflict, or at a scale where combined licensing exceeds a unified build.
How long does an integration project take?
Six to sixteen weeks for two to four integrations plus a custom module, against five to eighteen months for a full ERP implementation.
Written by Jas Singh, Founder. Last updated 8 October 2026. Costs are indicative and depend heavily on the systems involved and the quality of their APIs.
