The death of the 18-month ERP implementation

For thirty years, the honest answer to "how long will an ERP take?" was "longer than we're telling you". Twelve months. Eighteen. Sometimes three years and a lawsuit.

That era is ending — but not for the reason most vendors give. AI did not make ERP projects fast. It removed one specific bottleneck, and left every other one exactly where it was. Understanding which is which is the difference between a project that now takes six weeks and a project that still takes a year while everyone wonders why the AI didn't help.

Where the eighteen months actually went

Break a traditional implementation into its parts and the shape becomes obvious:

• Discovery and blueprinting. Months of workshops to write down how the business works, then translate that into how the software must be configured.
• Configuration and customisation. Consultants bending the vendor's data model toward your reality. The further you are from the vendor's assumptions, the longer this takes and the more it costs.
• Data migration. Extracting fifteen years of records from whatever they live in now, cleaning them, mapping them, loading them, discovering the mapping was wrong, doing it again.
• Integration. Wiring up the bank, the marketplace, the payroll system, the thing the previous IT manager built and did not document.
• Testing and UAT. Finding out what the blueprint got wrong.
• Training and change management. Persuading people to abandon a spreadsheet they trust for a system they do not.
• Go-live and stabilisation. Fixing what testing missed, at volume, in public.

Now the important question: which of those did AI actually touch?

What AI genuinely collapsed

Blueprinting, largely. Not because AI runs better workshops, but because it removed the reason workshops had to be so exhaustive. The blueprint phase was long because changing your mind afterwards was expensive. You had to specify everything up-front, precisely, because a missed requirement meant a change request, a quote and a delay.

When generating a module takes minutes, that pressure evaporates. You do not need to specify the perfect system in a conference room. You build a rough one on Tuesday, let people use it, and fix what is wrong on Thursday. Reacting to something real beats specifying something imaginary — and it is faster.

Configuration and build, almost entirely. This was the biggest single line item on most quotes and the one AI hit hardest. Describing a purchase-approval flow and getting a working one is now a minutes-long operation. It used to be a work package with a day rate attached.

Report and dashboard building. Formerly a queue you joined. Now conversational.

Those three were the bulk of the consulting invoice. They are largely gone. That is a real and significant change, and it is why the eighteen-month project is genuinely dying.

What AI did not touch at all

Here is the part the demos skip.

Data migration is still the timeline killer. Your old data is messy in ways that are specific to your company and invisible until you try to move it. Three customer records for the same company. A "notes" field where someone stored payment terms for a decade. Product codes that changed meaning in 2018. AI helps with some of the mapping. It does not tell you which of the three duplicate customers is the real one — only your team knows, and only by looking.

Integration is still someone else's API. When the marketplace changes its settlement format, generated code does not help. Somebody has to own that relationship, notice the change, and fix it. We are explicit about this on our integration pages because it is the thing most likely to be undersold.

Change management is completely untouched. This has always been the real reason ERP projects fail, and it is a human problem, not a technical one. The finance manager who does not trust the new numbers. The sales team that keeps a shadow spreadsheet. The branch that quietly never migrated. No model fixes this. If anything, faster software makes it worse — you can now out-build your organisation's ability to absorb change.

Deciding what you actually want is still hard. AI removed the cost of building the wrong thing. It did not remove the cost of not knowing what you want. Those are different problems and only one of them got solved.

The uncomfortable pattern in the famous failures

The well-known ERP disasters are instructive precisely because none of them were caused by the part AI fixed.

Hershey's 1999 go-live — widely reported to have left the company unable to ship Halloween orders despite having the stock — was a scheduling, testing and cutover failure. Lidl's SAP programme, reportedly abandoned in 2018 after roughly seven years and a very large write-off, foundered on the collision between the software's model and how the business insisted on working. Neither would have been rescued by faster module generation.

They failed on data, on process disagreement, on organisational reality, and on trying to do everything at once. Every one of those risks is still live today, at full strength, in an AI-native project.

Faster building means you reach the hard parts sooner. It does not mean the hard parts got easier.

So what does a project look like now?

The shape changes more than the duration.

The old model was a capital project: a business case, a steering committee, a big-bang go-live, a party. Its logic was that change was expensive, so you batched it — get everything specified up-front and cut over once.

The new model is closer to a habit. Start with one painful process, not the whole business. Get it live in days. Let one team use it for real. Add the next process when the first one has stuck. Migrate data only when a process actually needs it, not because the plan said Phase 1 was data.

This is not a faster waterfall. It is a different structure. The projects we see stall are the ones that adopted AI-native tooling but kept the old shape — an eighteen-month plan with a faster build phase in the middle, which is just eighteen months with more waiting.

The single highest-leverage decision is scope, and it is not a technology decision at all: do one thing first.

The honest verdict

The eighteen-month implementation is dying. Not because AI made ERP easy, but because the specific bottleneck it removed — configuration and build — was the biggest one, and because removing it made big-bang planning irrational.

What remains is smaller but stubborn: your data is messy, your integrations belong to other people, and your colleagues do not want to change. Those were always the reasons projects failed. They still are.

Anyone promising you a six-week ERP is quoting you the build. Ask them about the migration.

Common questions

Can an ERP really go live in six weeks now?

The build can. AI collapsed blueprinting, configuration and report building — the bulk of the old consulting invoice — so describing a purchase-approval flow and getting a working one is now a minutes-long operation rather than a work package with a day rate attached. What it did not touch is data migration, integration with other people's systems, and change management. Anyone quoting six weeks is quoting the build, so ask them about the migration.

Why is data migration still the slowest part of an ERP project?

Your old data is messy in ways specific to your company and invisible until you try to move it. Three customer records for the same company. A notes field where someone stored payment terms for a decade. Product codes that changed meaning at some point and nobody wrote it down. AI helps with some of the mapping, but it cannot tell you which of the three duplicate customers is the real one. Only your team knows, and only by looking.

What does an ERP project look like now, instead of an 18-month plan?

Closer to a habit than a capital project. Start with one painful process rather than the whole business, get it live in days, let one team use it for real, then add the next process once the first has stuck. Migrate data only when a process actually needs it, not because the plan said Phase 1 was data. The projects that stall are the ones that adopted AI-native tooling but kept the old eighteen-month shape.

Does faster software mean fewer failed ERP projects?

Not on its own. The well-known ERP disasters failed on data, on process disagreement, on organisational reality and on trying to do everything at once — none of them on the part AI fixed. Change management is completely untouched: the finance manager who does not trust the new numbers, the sales team keeping a shadow spreadsheet, the branch that quietly never migrated. Faster building means you reach the hard parts sooner, not that they got easier.

Related: what is an AI-native ERP on the architecture, and Vibe ERP explained on the method. If you are weighing the move, take the fit check.