Many mid-market businesses reach a common inflection point. The business is growing, but the systems aren't enabling the business to scale efficiently. Finance is reconciling manually, Operations can't see what's in the warehouse, or processes feel inefficient and rely on spreadsheets. Someone, usually a CFO or a new COO, wonders if they need a new ERP.
They may well be right, but they may well also be about to have a very hard time.
What an ERP actually is
ERP stands for Enterprise Resource Planning, which tells you almost nothing useful. Think of it as the operating system for your business: one integrated platform that connects finance, procurement, inventory, manufacturing, HR, and reporting into a single source of truth. Instead of several systems that don't talk to each other and multiple spreadsheets 'integrated' via your email platform, you have a single system to run your business.
In theory, this is transformative. In practice, it is one of the most disruptive, expensive, and frequently bungled technology investments a company can make.
Why they're so tricky
What looks like a technology implementation is actually a business transformation. You are changing how people work, how decisions get made, how money flows, and how the company reports on itself. The software is, of course, integral. But it is a complete renegotiation of your business processes.
The second misunderstanding is scope. ERPs touch everything. Finance, operations, procurement, HR: none of the functions work in isolation, and neither does the ERP. A decision made in the warehousing module creates consequences in accounts payable. A configuration choice in manufacturing propagates into financial reporting. The interdependencies are deep and not always obvious until something breaks.
Third: time and money. Projects routinely run over, because organisations consistently underestimate the complexity of the work and the people, process, and data readiness effort to complete the project, let alone to do it well.
Upgrades are not really easier. They are differently hard.
A common misconception is that upgrading an existing ERP is a smaller, safer project than implementing a new one. You already have an ERP. You know how it works. How bad can it be?
Quite bad, as it turns out.
The core problem with upgrades is what has accumulated during the years in between. Every customisation that was built to avoid a difficult conversation about process change. Every workaround that has become standard practice, handed down like lore. I've seen this, where a workaround was established, but it becomes the process and quite hard to change. Every integration bolted on without documentation or robust support processes.
Businesses tend to delay or defer upgrades until it just has to be done. By the time an upgrade is due, most organisations are sitting on years of technical debt that they've stopped noticing, because it has simply become part of how things work.
When the vendor moves the ERP forward, that debt comes due. Customisations break or need to be rebuilt. Integrations might need to be rebuilt, and they definitely need to be retested. And the business faces the same choice it avoided the first time: adopt the standard and retire the custom code or carry it forward and pay again.
There is also a psychological trap unique to upgrades. Because the system is familiar, the project feels manageable: governance is lighter, the business is less engaged, testing might be compressed. Then something breaks in production that nobody caught because the test coverage was light and the sign-off process was rushed.
Major ERP upgrades require the same rigour, if not the same effort, as new implementations.
Swapping ERPs: the hardest version of the problem
If a new ERP implementation is hard, and an upgrade is differently hard, replacing one ERP with another is somehow both at once.
The trigger is usually legitimate. The current system is end-of-life, the business has outgrown their current system, the new owner has a group-standard platform, or perhaps the existing ERP has been so heavily customised that it has become unmaintainable. These are real problems, and moving platforms is sometimes the right decision.
A trap is to assume that because you already run an ERP, you understand what you're getting into. You probably don't; you instead understand what you've been doing in your current system, which is something entirely different.
Every ERP has its own data model, its own process logic, and its own vocabulary. What your business calls a "job" the new system calls a "work order." What you've been treating as one process the new system models as three. The mapping exercise, taking what you do today and working out how it lives in the new platform, is detailed, iterative, and takes far longer than budgeted.
The data problem is at its most acute here. You are not just cleaning data; rather you are transforming it. Records that made perfect sense in the old ERP's structure need to be reshaped to fit the new one. Relationships between entities get redrawn. Historical data (which the business often insists on bringing across in full) creates enormous migration complexity for questionable operational benefit. The best approach, almost always, is to archive the history and start the new system with current, clean data.
Then there is the parallel running question. Do you run both systems simultaneously during cutover, or do you cut over hard on a single date? Parallel running sounds safer and more comforting, but it is also extraordinarily resource-intensive, and the longer it runs the harder it becomes to commit to the new system. Big-bang cutover concentrates the risk but forces readiness and commitment. Asking yourself how much bumpiness you're willing to accept as a business is a great question. Indeed, in my experience that's one of the most important and powerful discussions to have, because if you're willing to accept some bumps after cutover, it helps prevent overworking the project or fostering a project schedule that is too conservative.
And underneath all of it sits the same process adoption question. Switching platforms is the most expensive and disruptive route to recreating your existing processes in a different system. If that is what you do decide to do (and many do) because change is hard and the project timeline is already under pressure, you have spent a great deal of money to end up in roughly the same place.
The organisations that get the most from a platform swap treat it as a deliberate reset. They audit what they actually need from an ERP before they choose one, adopting standard processes, fighting hard to avoid customisation, and focusing on change management and data.
The data problem
If your current systems hold duplicate customer records, inconsistent product codes, incomplete supplier data, and years of unreconciled inventory, none of that magically cleans itself up on go-live day. It comes with you, now embedded in your expensive new system.
Data migration is not a technical task assigned to someone on the project team. It is a business-critical programme of work that requires ownership, people, and time. Every record needs to be assessed: what stays, what gets cleaned, what gets archived, and what gets thrown away. This is unglamorous, but crucial work.
For upgrades, the problem compounds. Data that was migrated imperfectly the first time has often had years to further degrade. Field mappings that made sense in the old version don't survive the move to the new one.
It's a case of garbage in, garbage out (not a new rule, but words to live by).
Don't customise. Adopt.
Modern ERP systems (SAP, Oracle, Microsoft Dynamics) encode decades of best-practice business process. The standard ways of doing things work. They work because thousands of companies before you have run them at scale, have found the edge cases, and fed that learning back into the product.
The temptation, which is almost universal, is to customise. To bend the system to match how you currently do things, because that's how you've always done them, and because asking people to work differently requires change leadership and change management. Every customisation has a cost: implementation time, testing complexity, and in the future an upgrade risk. A customised system becomes increasingly expensive to maintain and increasingly difficult to upgrade as the vendor moves forward without you.
The better question is not 'how do we make the system fit our processes?'; it is 'are our processes actually better than what the system is designed to do?' More often than not, the answer is no. The business has simply never been forced to examine them and to challenge themselves.
Adopting standard processes is harder in the short term. It requires a conversation or two. And it requires leadership to hold the line when functional heads push back. While it requires an investment in change management, it produces a system that is maintainable, upgradeable, and fit for purpose, rather than an expensive replica of what you already had.
An upgrade, or a platform swap, is also the best opportunity you will ever get to reengineer your processes. The businesses that treat this as a chance to retire customisations, clean the data, and retool their processes come out the other side in better shape. Those that treat it as a purely technical exercise tend to reproduce the same problems at higher cost.
ERP projects, whether they be new, upgrade, or replacement, go wrong in predictable ways. They go wrong when leadership treats them as IT projects. When the data work gets left too late. When customisation is used as a substitute for change management. And when the business doesn't stay close enough to the decisions being made on its behalf.
The good news is that none of this is inevitable, but avoiding them requires knowing where the traps are before you step in them.
That's what an independent perspective is for.