Nobody chooses spreadsheets as their operating system. They accumulate. One tracks stock because the accounting package could not, another tracks orders because the stock one got complicated, and a third reconciles the first two because they stopped agreeing.
By the time someone suggests an ERP, the spreadsheets are load-bearing and the person who built them has usually left.
The signals that actually mean something
Plenty of companies run happily on spreadsheets for years. These are the signs you have crossed a line:
Reconciliation has become a job. Somebody spends real hours each month making two systems agree. That work produces nothing — it exists only because the same fact lives in two places.
Numbers depend on who you ask. Sales and finance quote different revenue for the same month, both correctly, from different sheets with different cut-offs. When leadership stops trusting the figures, decisions slow down in ways nobody attributes to tooling.
The month-end close keeps stretching. Closing has crept from three days to eight, and the extra time is chasing, not analysing.
One person is the system. There is a file only one person understands, with formulas nobody dares touch, and their holiday is a business risk.
You cannot answer basic questions quickly. How much of product X did we sell to customer Y last quarter, and what did it cost us? If that takes a day of assembly, you have data but no information.
Errors reach customers. Wrong stock levels, duplicate invoices, orders shipped that were already cancelled. Manual re-entry has a floor on error rate, and volume eventually pushes you into it.
One of these is normal. Three or more, consistently, and the spreadsheets are now costing more than they save.
Fig. — The cost is not the spreadsheets. It is the reconciliation between them.
What an ERP actually changes
Strip away the vendor language and the idea is simple: one record, shared. An order recorded once updates stock, the ledger, and reporting simultaneously, because they are views of the same data rather than copies of it.
That single change eliminates the reconciliation work, the version disagreements, and most of the re-entry errors — not by being clever, but by removing the duplication that caused them.
What it does not do is fix a broken process. An ERP enforces process, which means a process nobody agreed on becomes a system nobody agrees with. Companies that implement without deciding how they actually want to work end up with expensive software they route around, and a fresh crop of spreadsheets doing the routing.
The honest costs
The licence is the smallest number in the project.
Implementation — configuring the system to your business — typically costs a multiple of the annual licence. Anyone quoting otherwise is describing a demo.
Data migration is where projects slip. Your existing data is inconsistent in ways you will only discover during migration: duplicate customers, products with three spellings, historical entries that never balanced. Cleaning it is unavoidable and always larger than estimated.
Process redesign is the part most often skipped and most predictive of success. Someone has to decide how each workflow should run, get agreement, and document it. That is organisational work, not software work.
Training and the productivity dip. For a period after go-live, everything is slower. Plan for it, staff for it, and do not schedule go-live in your busiest quarter — a surprising number of companies do exactly that.
The middle option nobody offers you
Between spreadsheets and a full ERP there is a tier that vendors rarely mention because nobody sells it: specialised tools that talk to each other.
A proper inventory system, a proper accounting package, and a proper order management tool — each excellent at one thing, connected by integrations — solves the reconciliation problem without a twelve-month implementation. For many businesses this is the correct answer for several more years, and it is considerably cheaper to reverse if you get it wrong.
The limit is complexity. Every integration is a dependency, and past a certain number of connected systems you are maintaining a small distributed architecture with no team to run it. When one integration breaking silently produces the same disagreeing numbers you started with, you have arrived at the ERP conversation legitimately.
The useful question: is the pain caused by data living in separate places, or by the processes themselves being tangled? Separate systems with good integrations fix the first. Only a single system with enforced process fixes the second.
Choosing without being sold to
Start from your processes, not from feature lists. Write down the ten workflows that matter most and ask each vendor to demonstrate those specifically, with your data. A demo of their standard flow tells you nothing about your business.
Be suspicious of customisation. Every deviation from standard behaviour is something to re-test at every upgrade and something the next consultant has to understand. Configure heavily, customise sparingly, and treat a request to customise as a prompt to ask whether the process is genuinely special or merely habitual.
Check the fit to your size honestly. Enterprise systems aimed at large multinationals will drown a fifty-person company in process. Small-business tools will hit a wall as you grow. The middle tier is crowded and unglamorous and usually correct.
And ask about integration early. Your ERP will not be your only system — you will keep a CRM, a payroll provider, maybe an e-commerce platform. If it cannot exchange data cleanly with those, you have bought a bigger spreadsheet.
Cloud or on-premise, briefly
For most companies in this position the answer is cloud, and it is worth knowing why rather than assuming.
A hosted ERP removes the infrastructure, the patching, the backup regime, and the upgrade project — which for a business without a dedicated IT team is most of the ongoing cost. Upgrades arrive continuously rather than as a project every few years, which is easier to absorb but does mean less control over timing.
On-premise still makes sense in narrow cases: genuine data residency requirements that no vendor region satisfies, unreliable connectivity at the sites that need it, or heavy existing investment in infrastructure and the people to run it. Those cases are fewer each year.
The question that decides it in practice is not technical. It is whether you have someone whose job is keeping servers healthy. If the honest answer is that it would fall to whoever is least busy, choose cloud.
Sequencing it so it survives
Phase it. Finance and inventory first, because they carry the reconciliation pain that motivated the project. Add modules once people trust the core. A big-bang go-live across every function is where the horror stories come from.
Clean the data before migrating, not during. A dedicated data phase feels like a delay and prevents the failure mode where you spend go-live week discovering your customer list has four thousand duplicates.
Name an internal owner with authority. Not a committee, and not the consultant. Someone inside the business who can settle a disagreement between departments about how a process should run, because that disagreement will arrive and the project stops until it is resolved.
Expect some spreadsheets to survive, and let them. Analysts will always want to pull data out and model something the system does not do. That is fine and healthy. The failure is when a spreadsheet becomes the place a fact is recorded rather than analysed — that is the pattern you are trying to end.
And keep the spreadsheets running in parallel for one cycle. Belt and braces, and the comparison is how you find out what the new system is getting wrong before it matters.
Getting the sequencing and the integrations right on a move like this is the sort of work we do at CODT.
