Before you replace your ERP: the questions you need to answer first

Replacing an ERP is one of the largest, riskiest and most expensive things a business can do to itself. It touches finance, operations, stock, customers — the core of how the business runs. And it goes wrong often, not because the new system is bad, but because the decision to replace was made before the right questions were answered. The most valuable work happens before you choose anything.

Here are the questions to answer first, because answering them changes the project — and sometimes removes the need for it.

Why are we really replacing it?

Start with the honest reason. “It’s old” is not a reason. “It’s slow,” “the reports are wrong,” “it doesn’t do what we need” are symptoms, and each may have a cause that a new ERP will not fix. If the reports are wrong because the data is a mess, a new system inherits the mess. If the process is undefined, no ERP can enforce it. Naming the real problem first determines whether replacement is even the right answer, or whether you would simply leave the next platform for the same reasons you left this one.

Free · 4 minutes

When two of your systems disagree, do you know which one to believe?

Fourteen questions on ownership, lineage, and quality — the difference between a number on a dashboard and a number you could defend. Banded finding on screen, full sheet by email.

What does the business actually use?

Most businesses use a fraction of their ERP’s capability, and have configured it heavily over years in ways nobody fully remembers. Before replacing it, you need an honest map of what is genuinely used, what is load-bearing, and what is there only because it always has been. Without that map, you do one of two expensive things: replicate everything, including what you do not need, or discover mid-project that something critical was missed.

What state is our data in?

The ERP is, at its heart, your business’s data. Migrating it is the hard part of any ERP project, and the quality of the data you carry across determines the quality of what you get. If the data is inconsistent and untrusted today — the root of reports that show different numbers — then migrating it as-is reproduces the distrust in the new system. The data has to be understood, and usually cleaned, before it moves. This is where ERP projects most often overrun, and where planning earns its keep.

What does our process need to be?

An ERP encodes how the business operates. A replacement is a rare chance to decide how the business should operate, rather than rebuilding how it happens to operate now. But that is a decision to make deliberately, before configuration, not something to discover during it. Businesses that skip this either bend the new ERP to fit old habits, losing the benefit, or let the software dictate the process by default.

Who owns this, and who keeps us honest?

An ERP project needs a single owner on the business side with the authority to make decisions quickly, and it needs an independent technical voice — because the implementation partner sells the project and has every reason for it to be large. Someone whose interest is your outcome, not the size of the engagement, is what keeps the scope honest and the data discipline enforced. The full anatomy of getting a migration like this right is covered in what an enterprise software migration actually requires.

ERP decisions made without an architecture and data view tend to recreate the same problems on more expensive software. Answering these questions first is what prevents that. We will work through them before you commit to anything.

Start a Conversation

Build and rescue work

Hands-on delivery of this kind is handled by Sixteen Pillars Studio.

Looking at an acquisition, supplier, or major project?

The greatest risks are rarely visible in the executive summary. The Sixteen Pillars framework surfaces the technology risks that diligence usually misses.