Ship your ERP one module at a time

There is a particular kind of project meeting that happens about fourteen months into a big-bang ERP implementation. Everyone agrees the go-live date has to move. Nobody can say exactly which piece is behind, because every piece is behind by a little and no piece has ever run against real data. The budget conversation happens the following week.

We have avoided that meeting on the ERP we have kept in production since 2020 for a US autobody parts distributor, and the reason is not that we are unusually good at estimating. It is that we never put ourselves in a position where a single date carried the entire project.

Why big-bang ERP launches fail

The standard explanation is that ERP projects fail because of scope creep or poor change management. That is true but shallow. The structural problem is that a big-bang cutover defers all learning to the end.

Consider what you genuinely do not know at the start of an ERP build:

• How the client's data is actually shaped, as opposed to how the client describes it
• Which of the stated requirements are real constraints and which are habits
• Where the process has undocumented exceptions that everyone works around
• How the system behaves under the real transaction volume

Every one of these is answerable only by running real work through real software. In a big-bang project, that happens once — at the end, when the cost of being wrong is at its maximum. You spend twelve months accumulating unvalidated assumptions and then discover all of them in the same fortnight.

What incremental actually means here

"Incremental" gets used loosely. Shipping a demo every two weeks to a staging environment nobody uses is not incremental delivery — it is a big-bang project with a nicer reporting cadence.

The test is simple: is real work being done in the new system by real staff, and is the business relying on the output? If the answer is no, you have not started yet.

For the autobody ERP the sequence ran roughly like this:

1. Inventory and the item master. Nothing else can be correct if the catalogue is wrong.
2. Purchasing. Stock has to come from somewhere, and this is where supplier data proves itself.
3. Sales and quoting. Now the pricing rules meet reality, including the awkward ones.
4. Invoicing and reporting. Last, because it depends on everything above being trustworthy.

Each of those went live and was used in anger before the next one started.

How to sequence the modules

The sequencing question has a reliable answer: start with the module that owns the data everything else reads.

In distribution, that is nearly always inventory and the item master. In a services business it is usually the client and project records. In manufacturing it is the bill of materials. The principle is the same — find the entity that other modules reference, and get it right first, in production, with the real data.

Two things follow from that choice, and both matter more than they sound.

First, your data migration problem gets solved early, when there is still time. Data migration is the single most underestimated part of every ERP project we have worked on. Legacy data is always dirtier than the client believes, because the client sees the reports rather than the tables. Discovering that in month two is a manageable problem. Discovering it two weeks before cutover is a crisis.

Second, you get a genuine feedback loop with the people who will use the thing. After the first module goes live, requirements conversations change character completely. You stop debating hypotheticals and start discussing observed behaviour. Users who could not articulate what they wanted in a workshop become extremely articulate once they have used something for a fortnight.

What this does to the commercial conversation

There is a commercial argument for incremental delivery that rarely gets made, and it is the one most finance directors actually respond to.

In a big-bang project, the client spends the entire budget before receiving anything of value. The return begins at go-live, which is also the moment of maximum risk. The cash-flow shape is terrible and the risk profile is worse.

With module-by-module delivery, the first module starts returning value while later modules are still being built. Spend and return overlap. And critically, the client retains a genuine decision point after every module: continue, pause, change direction, or stop. That optionality has real value.

It also changes the vendor relationship in a way that is uncomfortable but healthy. If a supplier has to earn the next module by delivering the current one, incentives align. We have been on the receiving end of that discipline for years now, and it has made the work better.

When big-bang is actually right

Not every situation supports incremental delivery, and pretending otherwise would be dishonest.

A hard external deadline — a licence expiring, a parent company mandating a platform, a regulatory change with a fixed date — can force a single cutover. So can a legacy system so tightly coupled that no module can be extracted without extracting all of them. Very small implementations, where the whole build is three months, do not benefit much from slicing either.

The point is that big-bang should be a decision you make deliberately, with the risk understood and priced, rather than the default that happens because nobody considered the alternative.

What to ask a prospective ERP vendor

If you are evaluating vendors, three questions will tell you a great deal about how a project will actually run:

"Which module would you deliver first, and why that one?" A good answer names a specific module and explains the data dependency. A vague answer about "phases" means they intend a big-bang project with milestones.

"When will real users be doing real work in the new system?" If the answer is anywhere near the end of the timeline, the risk is concentrated.

"What happens to our data migration if the legacy data is worse than expected?" The honest answer involves discovering this early. Anyone who says it will be fine has not looked at your tables.

The system we have supported since 2020 is not remarkable software. What is somewhat remarkable is that it is still running, still being extended, and still owned by a business that trusts it. That outcome came from sequencing, not brilliance.