Why ERP Implementations Fail in Australia: The Six Patterns Behind Most Troubled Projects

Fewer than one in three Australian businesses that buy new software successfully adopt it, according to Capterra’s research on Australian software buying, based on a survey of 281 Australian decision-makers. ERP sits at the hard end of that statistic. An ERP project touches every team, every process and the finance function’s ability to close the books, so when it goes wrong it drags more of the business down with it than any other software purchase.

We implement Odoo and MYOB Acumatica, and we also get called in when projects run by others have stalled. That second kind of work teaches you things the first kind doesn’t. This post covers the six patterns we see behind most failed ERP implementations in Australia, what failure costs, the warning signs worth acting on early, and what to do if your project is already in trouble.

What a failed ERP implementation actually looks like

The failures that make the news are the spectacular ones. The federal government’s GovERP program spent $340.6 million between 2019 and 2023 building a shared corporate services platform for the public service. The independent technical assessment found that of the 30 capabilities developed, none progressed past functional testing into production, and the program was retired in favour of a new approach that lets agencies choose their own systems.

Private-sector failures rarely look like that. The version we see in Australian mid-market businesses is quieter. The system is technically live, but the warehouse still runs on the old spreadsheets because nobody trusts the stock numbers. The go-live date has slipped three times and the original budget is a distant memory. Phase one wrapped up eighteen months ago and the modules that justified the investment are still switched off.

A failed implementation is rarely a system that doesn’t work. It’s a system the business doesn’t use.

Why ERP implementations fail: the six patterns

Every troubled project we’ve assessed traces back to at least one of these patterns, and usually two or three working together.

1. The software was chosen before the processes were understood

45% of Australian decision-makers say disconnected systems are limiting their growth, so ERP purchases often happen under pressure. A demo looks convincing, a quote fits the budget, and the contract is signed before anyone has mapped how orders, stock, jobs and invoices actually move through the business. The gap between how the demo assumed you work and how you actually work becomes the project’s real scope, discovered one change request at a time.

2. Data migration was treated as a copy and paste job

Customer records with three duplicates each, stock items nobody has sold since 2019, opening balances that don’t tie back to the old system. Migration is where implementations quietly lose their schedules, because cleaning data is unglamorous work that every party assumed someone else would do. We published a data migration checklist partly because this one workstream decides more go-live dates than any other.

3. Too much customisation, too early

Custom code written before the team has used the standard system locks early misunderstandings into software. Every customisation adds testing effort now and upgrade cost later, and the worst projects we rescue involve custom modules with no documentation and no author still reachable. The discipline that works is boring: run standard first, customise what proves necessary, and document everything as if the next consultant will need it, because they will.

4. Training got whatever budget was left

Training is the easiest line to cut when a project runs over, and cutting it is how systems end up technically live and practically unused. The people processing orders, picking stock and paying suppliers decide whether an ERP succeeds, and they decide it in the first few weeks after go-live. If their introduction to the system was one rushed session and a PDF, they’ll retreat to the spreadsheets they trust, and the business case retreats with them.

5. Nobody inside the business owned the project

An implementation partner can configure the system, but they can’t decide which of your two conflicting pricing processes is the real one. Projects need an internal owner with the authority to make those calls and the time to make them quickly. Where the project is everyone’s second job and no one’s first, decisions queue up, the partner idles between answers, and the schedule slips without anyone doing anything visibly wrong.

6. The partner relationship broke down

Sometimes the fit was wrong from the start: a team configuring GST, BAS and payroll settings for the first time, or a generalist reseller out of their depth in manufacturing. Sometimes the partner disappears mid-project. Sometimes the relationship sours over a scope dispute and both sides stop talking. Whatever the cause, a project cannot survive long without a functioning relationship at its centre, which is why partner selection deserves more diligence than most businesses give it.

What ERP failure costs Australian businesses

36% of Australian mid-sized businesses are looking to upgrade their ERP, and 48% name operational efficiency as the main driver. Some portion of those upgrades are really second attempts: a business paying for a system it never fully adopted, going back to market to try again.

The direct costs are easy to list. Licence fees on modules nobody uses. Consultant invoices for work that got parked. The double handling of running old and new systems side by side for months longer than planned. The larger costs are quieter: decisions made on numbers nobody trusts, staff hours spent re-keying data between systems that were supposed to be connected, and the organisational scar tissue that makes the next technology project twice as hard to get approved.

The warning signs a project is drifting

Most failures announce themselves months in advance. These are the signals we’d act on:

• The go-live date has moved more than once. One slip is normal. Two slips with no change in approach means the plan is the problem, not the calendar.
• Parallel spreadsheets are multiplying. Every new “temporary” spreadsheet is a vote of no confidence in the system.
• Change requests outnumber completed milestones. The project is redesigning itself faster than it is being delivered.
• Your team has stopped turning up. When internal staff quietly drop out of project meetings, adoption is failing before go-live has even arrived.
• The answers are getting vaguer. If “when will this be done” no longer gets a date, the partner may not know either.

Any two of these together justify a pause and an independent look. The earlier the intervention, the more of the original investment survives.

What to do if the implementation is already in trouble

Start with a diagnosis rather than a bigger contract. In the ERP rescue work we run, the engagement begins with a fixed-fee assessment of the configuration, the custom code, the data quality and the gap between what was built and how the business operates. It ends in three costed paths: stabilise what exists so the business can run while decisions get made, rebuild in place on the same platform, or replatform as the last resort. Most rescues end in the middle path, because the licence investment and parts of the build are usually worth keeping.

In most rescues we run, the platform was never the problem. The configuration didn’t match how the business actually works, and the people who use the system every day were never asked. Fix those two things and the same software the client wanted to throw out usually earns its keep.

Bill Alvarez, Practice Manager, Auboros

If the assessment does point to replatforming, treat it as a structured ERP migration rather than a fresh leap of faith. The second implementation has to be run better than the first, not just aimed at different software.

Setting up an implementation that won’t need rescuing

The prevention list mirrors the failure list, which is the point:

• Map your processes before you sign anything. A partner who wants to understand your workflows before quoting is showing you how they’ll run the project.
• Start the data work in week one. Cleaning customer, supplier and stock records can begin before the system is even configured, and it shortens everything downstream.
• Run standard before you customise. Live with the out-of-the-box process for a cycle where you can. Half the “essential” customisations stop being essential once the team has used the real thing.
• Name an internal owner with real authority. Someone who can make process decisions without convening a committee, and whose other duties have visibly been reduced.
• Make training a protected line item. Budget it per role, schedule it before go-live, and repeat it after the first month of live running when the real questions have surfaced.
• Check references from businesses like yours. Same industry, similar size, same compliance needs. Australian GST, BAS and payroll requirements are unforgiving of partners learning on your project.

For a sense of what a well-run project looks like phase by phase, our Odoo implementation guide and our MYOB Acumatica implementation timeline both walk through the stages in detail, including where the schedule risk usually hides.

Worried your ERP project is heading the wrong way?

We implement and rescue Odoo and MYOB Acumatica systems for businesses across Brisbane, Queensland and the rest of Australia, and a second opinion early is far cheaper than a rescue later. If your project is drifting, book a free consultation. Bring the war stories, we’ve heard most of them.