ERP implementation (2026): Phases and why projects fail

Short answer: an ERP implementation is the project that takes a company from its old systems to a working ERP: planning, process design, configuration, data migration, integrations, testing, training, go-live and post-go-live support. A small business with standard processes can be live in a few months; a mid-market company with inventory, manufacturing or several entities usually needs six months to a year; multi-country enterprise programmes run longer and are phased. Most failures come from the same few causes (unclear scope, weak executive ownership, poor data, too much customisation and too little training), and all of them can be managed if you plan for them from day one.

This guide walks through the phases of an ERP implementation, realistic timeline ranges, the roles you need, how to handle data migration and change management, and the hurdles that derail projects. It is written for the finance, operations and IT leaders who will own the project.

What is ERP implementation?

ERP implementation is the process of installing, configuring and rolling out enterprise resource planning software so that the business runs its day-to-day transactions in it. It is not only a software installation. It changes how orders, purchases, stock, production and accounting flow through the company, so it is as much a business change project as an IT project. If you are new to the topic, start with what ERP is and what it does.

What are the phases of ERP implementation?

Vendors and partners use different names for them, and many run the build in agile sprints, but almost every successful project goes through the same six phases.

Phase	Main activities	Key outputs
1. Discovery and planning	Confirm objectives, scope, budget, team and governance; document current processes and pain points	Project charter, scope document, plan, RACI, risk log
2. Design	Fit-gap workshops by process area; decide what to configure, what to change in the business and what (if anything) to customise	System design document, integration and data migration designs
3. Build and configure	Set up the chart of accounts, entities, items, workflows, roles and reports; build integrations and any extensions; run trial data loads	Configured system in a test environment, integration builds
4. Testing	Unit tests, end-to-end process tests, integration tests, user acceptance testing (UAT), performance checks, mock cut-overs	Signed-off UAT, defect log, cut-over plan
5. Training and deployment	Role-based training, final data migration, cut-over weekend, go/no-go decision, go-live	Trained users, live system, opening balances reconciled
6. Hypercare and optimisation	Intensive support for the first weeks, first month-end close in the new system, fixes, phase-two backlog	Stable operations, handover to business-as-usual support

1. Discovery and planning

Write down why you are doing this and how you will measure success: days to close, inventory accuracy, order cycle time, number of manual spreadsheets. Fix the scope (entities, sites, modules, integrations) and name the executive sponsor and the full-time project lead. A clear scope is the single best protection against budget overruns.

2. Design

Run workshops by process (record to report, procure to pay, order to cash, plan to produce, and so on). For each gap between your current process and the standard product, choose one of three answers: change the process, configure the system, or build an extension. Default to the first two. Every customisation adds testing and upgrade effort for the life of the system.

3. Build and configure

The partner configures the system while your team prepares data and writes test scripts. This is also when integrations are built: ecommerce, CRM, payroll, banks, tax engines, EDI and warehouse or shipping systems. Hold regular demos of the configured system so users see progress early and spot misunderstandings while they are cheap to fix.

4. Testing

Test full business scenarios, not single screens: a customer order from quote to cash receipt, a purchase from requisition to supplier payment, a production order from material issue to finished goods. User acceptance testing should be done by the people who will use the system, with real (migrated) data. Run at least one mock cut-over to rehearse the go-live sequence and time it.

5. Training and go-live

Train by role, in the configured system, close to go-live. Pick a cut-over date away from peak season and month-end. Most companies choose a big bang go-live (everyone switches at once) for a single entity, or a phased go-live (by entity, site or module) for larger groups. Make the go/no-go decision against written criteria: UAT signed off, critical defects closed, data reconciled, users trained, support ready.

6. Hypercare and optimisation

Plan several weeks of intensive support after go-live, with the partner and internal super users on hand. The first month-end close is the real test. After the system stabilises, work through the phase-two list: reports, automations, deferred modules and the improvements users suggest once they know the system.

How long does an ERP implementation take?

Timelines depend far more on scope and on your team’s availability than on the software. As general guidance only:

Project profile	Typical duration	What stretches it
Small business, financials plus basic inventory, one entity	A few weeks to a few months	Messy data from old accounting files, owner availability
Mid-market, several modules and integrations, one to a few entities	Roughly six months to a year	Manufacturing or warehouse scope, EDI and ecommerce integrations, customisation
Enterprise, multi-country, global template	Often a year or more, delivered in waves	Localisations, legacy system retirement, organisational change across regions

Treat any timeline that is much shorter than these ranges with caution unless the scope is genuinely small and the partner is using a pre-configured package.

Who should be on the ERP implementation team?

• Executive sponsor: a senior leader (often the CFO or COO) who owns the business case, resolves cross-department conflicts and protects the budget and people.
• Project manager (internal): runs the plan day to day, owns the risk log and holds the partner to account. On mid-market projects this is close to a full-time role.
• Process owners: one decision-maker per process area (finance, purchasing, sales, warehouse, production) who signs off the design.
• Key users or super users: experienced staff who test, help train colleagues and become the first line of support after go-live.
• IT and data lead: integrations, security, access roles and data migration.
• Implementation partner: functional and technical consultants, a partner project manager and, for larger projects, a solution architect.

The most common staffing mistake is expecting key users to do the project on top of a full-time job. Budget for backfill; it is one of the hidden costs of ERP.

How do you choose an ERP implementation partner?

For most mid-market ERPs you choose the software and the partner together, and the partner often matters more to the outcome. Look for:

• Recent projects in your industry and at your size, with references you can call
• The named consultants who will work on your project, not just the sales team
• A clear method, including how they handle change requests and testing
• Honest fit-gap answers during the sales process (a partner who says yes to everything is a risk)
• Post-go-live support capacity and pricing

Our step-by-step guide on how to choose an ERP system includes partner selection questions and a scoring matrix.

How should you handle ERP data migration?

Data migration is where many projects lose weeks. Plan it as a workstream of its own:

1. Decide what to bring. Master data (customers, suppliers, items, chart of accounts, BOMs) always; open transactions (open orders, open AR and AP, stock on hand) always; history is a choice. Many companies bring summary balances for prior years and keep the old system read-only for detail.
2. Clean before you move. Remove duplicates and obsolete records, standardise units of measure, addresses and naming, and fix item costs.
3. Map fields from each source to the new structure, including any new dimensions or segments.
4. Run trial loads early and repeatedly, and reconcile each one against the source: record counts, balances, stock values.
5. Final cut-over load: freeze the old system, load open balances and transactions, reconcile, and sign off before users start transacting.

Why do ERP implementations fail?

“Failure” rarely means the software never goes live. More often the project runs well over budget or time, or the system goes live but people keep their old spreadsheets and the benefits never arrive. These are the hurdles we see most often, and how to avoid each one.

Hurdle	What it looks like	How to avoid it
Poor software fit or unclear requirements	Big gaps discovered during build; growing list of customisations	Scripted demos of your real scenarios before you buy; written requirements with priorities
Weak executive sponsorship	Decisions stall; departments negotiate separately with the partner	Named sponsor with authority; steering group that meets on a fixed rhythm
Insufficient team resources	Key users miss workshops and testing; deadlines slip	Backfill key roles; protect project time in calendars
Scope creep	“While we are at it” requests added mid-project	Change control with cost and timeline impact; phase-two backlog
Over-customisation	Old processes rebuilt in code; slow, expensive upgrades	Default to standard; require a business case for every customisation
Poor data quality	Failed trial loads; wrong stock and balances at go-live	Start cleansing in the planning phase; reconcile every trial load
Inadequate testing	Surprises in the first week live; month-end problems	End-to-end scenario tests with real data; at least one mock cut-over
Too little training and change management	Workarounds, parallel spreadsheets, low adoption	Role-based training, super users, clear communication of why things are changing
Unrealistic timeline or budget	Testing and training cut to hit a date	Plan with contingency; agree go/no-go criteria in advance

How do you manage change during an ERP rollout?

People resist ERP when it feels like extra work for no personal benefit. A few practices make a large difference:

• Explain the why in terms each team cares about: fewer re-keyed orders for customer service, faster close for finance, reliable stock for the warehouse.
• Involve users early in design and testing so the system reflects how work is actually done.
• Build a super user network in every department, trained first and given time to help colleagues.
• Train on real scenarios in the configured system, not generic vendor demos.
• Retire the old systems on a published date so parallel spreadsheets do not survive go-live.
• Measure adoption after go-live: transactions entered in the system, open exceptions, support tickets by area.

ERP implementation checklist

• Business case and measurable objectives signed off by the sponsor
• Scope document covering entities, sites, modules, integrations and users by role
• Internal project manager and process owners named, with backfill agreed
• Partner contract with defined deliverables, method and change control
• System design and fit-gap decisions documented
• Data migration plan with cleansing owners and trial load dates
• Integration list with owners and test cases
• Test plan covering end-to-end scenarios and UAT sign-off
• Training plan by role and super user network
• Cut-over plan, go/no-go criteria and rollback plan
• Hypercare support model and phase-two backlog

Can you implement an ERP without professional help?

Small businesses with simple processes sometimes self-implement cloud ERP using vendor onboarding packages, especially for financials and basic inventory. Once you add manufacturing, warehousing, several entities or many integrations, an experienced partner usually saves more than it costs, because they have made the configuration decisions many times before. A middle path is to buy a limited number of partner hours for design and data migration and do the rest in-house.

If you have not chosen a system yet, see our guide to the best ERP software and our ERP software category.

Frequently asked questions