Most of the businesses we talk to don't have a software problem. They have five small software problems: a CRM here, an invoicing tool there, a spreadsheet that has quietly become the inventory system, an HR app, and an accounting package that learns the truth last. Each tool was a reasonable choice on the day it was bought. Together they form something nobody chose — a stack held together by exports, imports, and one person who knows which numbers to trust.
The word doing all the damage in that sentence is 'almost'. The tools almost talk to each other. The connector almost covers every field. The nightly sync almost always runs. Almost is expensive, because a human has to stand in every gap — and people re-keying data at the end of invoice day are where the real cost lives.
We spend much of our time replacing these stacks with a single Odoo system, so we're not neutral. But we've also told prospects to keep what they have. Here is how we think about both sides.
The integration tax nobody puts on a quote
When you buy five tools, you see five subscription prices. What you don't see is the tax you'll pay to make them behave like one system:
- Re-keying. The same customer, product, or timesheet entered twice — two chances to typo it and no process that catches the difference.
- Silent sync failures. Connectors break quietly on an API change, a renamed field, an expired token. You find out weeks later, often from a customer.
- No single truth. Sales reports one revenue figure, accounting reports another, and closing the month becomes an investigation instead of a report.
- Orphaned access. Five tools means five user lists, five offboarding checklists, and five places a former employee might still have access.
- Un-upgradable glue. The custom script bridging two tools was written by someone who left, lives on a server nobody dares restart, and quietly vetoes every upgrade decision.
None of these appear on any invoice, which is exactly why they persist. The stack looks cheap because its most expensive component — the people reconciling it by hand — is filed under salaries, not software.
The consolidation math
The naive version of the math compares license fees, and a consolidated suite often wins that comparison anyway. But the license line is the least interesting one.
One system means one database, so a customer, a product, and an invoice are the same record everywhere — there is nothing to sync because there is nothing separate. It means one upgrade path to test instead of five products on five vendors' schedules, each release a fresh chance to break a connector; we test upgrades before they touch production data, practical only with one system to test. It means one backup to take and, more importantly, one restore to actually rehearse instead of five recovery stories on the worst day of your year. It means one permission model, one audit trail, and one interface to learn, which is why we train by role rather than by module: an accountant learns the accountant's path, once.
It also changes how customization behaves. In a glued-together stack, custom work lives in the glue — scripts and middleware with no owner. In our practice, custom work is module-grade: versioned in Git, reviewed, and carried through upgrade testing like any other code. And because we look at OCA and Community modules first, a good share of the 'custom' requirements turn out to already exist as maintained open-source modules. The cheapest integration is the one a community already wrote and keeps maintaining.
That discipline is also why we can quote a fixed price after a scoping phase: a single system has a knowable surface. A five-tool stack with hand-rolled glue does not — which is why such projects so often drift into time-and-materials forever.
When consolidating is the wrong move
An honesty section, because we owe you one: consolidation is not always the answer.
If a specialized tool is genuinely deep — a payroll engine built around local labor-law edge cases, CAD software, a regulator-certified system — then an ERP module that covers most of it is a downgrade, not a simplification. Keep the tool, and build one well-owned integration instead of ten bad ones.
Timing matters too. Migrating mid-fiscal-year or during your peak season converts a strategic project into an emergency. And a migration is only responsible when it is run like one: we don't cut anyone over without reconciliation reports comparing old and new data line by line, at least one full dry-run, and a written rollback plan. If a vendor proposes a big-bang switch without those three things, staying on the five-tool stack is genuinely the safer choice.
Finally, if your current stack actually works — the syncs are monitored, someone owns the glue, month-end closes cleanly — then the integration tax may already be paid down. Consolidation is a cure for pain, not a virtue in itself.
The pattern we keep seeing: consolidate the record-keeping core — sales, purchases, stock, invoicing, accounting — where a single source of truth pays off every day, and integrate deliberately at the edges where specialists earn their keep. If you're trying to work out which side of that line your own stack sits on, our implementation approach page explains how we scope that question before committing to a fixed price.