ERP Implementation Guide: 8 Steps from Kickoff to Go-Live

Three out of four ERP implementations are perceived as failing by the organisations that ran them. The number comes from Panorama Consulting (2024) and has barely shifted in years. Budget overrun. Schedule slipped. Employees who never adopted the new system. Or worse: an organisation still working around the ERP in Excel spreadsheets, months after go-live.

Honestly, it doesn’t have to be that way.

Most ERP projects don’t fail because of bad software. They fail because of a flawed approach. Wrong expectations. Too little attention to the people who will actually work with the system. And yes, sometimes consultants who care more about billable hours than about results.

An ERP implementation is the full journey from selection through go-live, in which an organisation configures, tests and adopts a new ERP system. It covers project initiation, blueprinting, configuration, data migration, testing, training and go-live. It typically takes 6 to 18 months, depending on complexity and scope.

In this article we walk you through the complete ERP implementation guide. From the very first kickoff to the days after go-live. With the lessons we’ve learned in our daily practice. Including the mistakes we’ve seen made, and the approach that actually works.

The phases of an ERP implementation

An ERP implementation moves through eight recognisable phases. These phases are not a rigid waterfall to be followed blindly; they are a framework that always needs adjustment in practice. But the sequence is real, and skipping a phase is almost always a recipe for trouble.

A well-structured ERP implementation programme begins with a clear project initiation and only truly ends after a stable post-go-live period. Skipping a phase materially increases the risk of budget overrun and user resistance.

Phase 1: project initiation

Project initiation is the phase most organisations underestimate. This is where you lay the foundation for everything that follows. Who sits in the project team? What is the scope? What budget is available? And perhaps most importantly: what does success look like?

In our practice we see organisations trying to wrap up this phase in two weeks. That is too short. Plan for four to six weeks. In that time you draft the project charter, appoint the steering committee and project manager, and make sure the whole organisation knows what is about to happen. Not as a side note, but as a priority.

A concrete example: at a Dutch manufacturer with 180 employees we spent six weeks on project initiation. It felt long to management. But because we had clear agreements on scope, roles and decision rights up front, the rest of the project ran without major conflict. The full implementation finished within 14 months, two months ahead of the original deadline.

Phase 2: blueprinting and design

In the blueprint phase you translate your business processes into the ERP system. How will the order flow work? How will financial administration look? Where are the exceptions you currently solve with workarounds?

This is the phase where you need your key users most intensively. Not the IT department, but the people who work with the processes every day. The buyer who knows that supplier X always invoices in Danish kroner. The planner who knows production line 3 always stops for maintenance on Tuesdays. That kind of knowledge isn’t captured in any process handbook.

A common mistake is treating the blueprint as a formality. “We’ll fill in the implementation partner’s templates and move on.” That doesn’t work. The blueprint is the moment when you decide how your organisation will work from then on. That deserves serious attention.

Phase 3: configuration and build

Now the system gets set up. Based on the blueprint, the technical team configures the ERP package. Master data is structured, workflows are configured, reports are built. This is also the point at which the discussion about customisation versus configuration hits the table. More on that further down.

Configuration typically takes eight to twelve weeks for most mid-sized implementations. During that period it is critical that key users review and give feedback regularly. Not just at the end, but every two weeks. That way you catch deviations early and prevent the team from working for weeks based on a wrong assumption.

Phase 4: data migration

Data migration is the silent risk of every ERP project. Your customer records, item master, open orders, financial history: it all has to move into the new system. And that data is almost never clean.

In our experience, data migration is responsible for an average of 30% of total project delay. This is because organisations structurally overestimate the quality of their source data and underestimate the complexity of data transformations.

We recommend treating data migration as a separate sub-project, with its own plan and dedicated owner. Begin with thorough data cleansing before you start migrating. It saves enormous amounts of time in the test phase. For a deeper dive into preparation specifically, see our guide on ERP data migration preparation.

A real example: at a distributor with 45,000 SKUs, 22% of the item master proved incomplete or out of date. By investing three extra weeks in data cleansing before migration, the test phase ran four weeks faster than planned. That investment paid for itself several times over.

Phase 5: testing

The importance of testing in ERP implementations is systematically underestimated. Testing isn’t “let’s quickly click to see if it works”. It is a structured process with multiple rounds.

You start with unit tests: does each individual function work correctly? Then integration tests: do the processes work end to end? Next user acceptance tests (UAT): can the key users perform their daily work in the new system? And finally a stress or performance test for larger implementations.

Plan a minimum of four weeks for the test phase at a mid-sized implementation. And don’t schedule those weeks at the very end, when the deadline is already in sight and nobody has time anymore. Testing isn’t a luxury, it is a necessity.

Phase 6: training

Training isn’t just about which buttons employees should press. It is about understanding why processes are changing. Why they now have to raise a purchase order in the system instead of calling the supplier. Why they have to log hours in the system rather than on a slip of paper.

We see two training models that work well. The first is “train-the-trainer”: you train key users who then train their colleagues. The advantage: the trainer knows daily practice. The second is process-based training: not “this is how module X works”, but “this is how you process a return from start to finish.”

Whichever model you choose: don’t start training too late. The first sessions should be running at least four weeks before go-live. Otherwise the knowledge has already faded by the time the system goes live. For a deeper view on how to bring your people along, see our guide on ERP change management.

Phase 7: go-live

Go-live is the moment the new system goes into production. It is intense, for everyone. And it almost never goes perfectly. There are always issues that only surface after go-live, processes that work just a little differently than in the test environment, employees who get stuck on something unexpected.

That is normal. The difference between a successful and a failed go-live is not in the number of issues, but in how fast you resolve them. Set up a “war room” in the first days after go-live: a physical or virtual space where key users, consultants and IT sit together to resolve problems immediately.

The choice between big bang and phased we’ll cover further down. That choice is not made on the day of go-live, but months earlier in the blueprint phase.

Phase 8: hypercare and optimisation

The real work begins after go-live. The first six to twelve weeks after go-live are at least as important as go-live itself. In this period the “forgotten” requirements surface: reports that don’t quite add up, processes that need to change after all, integrations that fail under load.

Plan budget and capacity for this. We see too often that organisations scale down external consultants right after go-live and leave the internal team to fend for themselves. That is a risk. Plan for at least eight weeks of hypercare with sufficient expertise available.

Where it goes wrong, and how to prevent it

In the many ERP projects we’ve supported, we see the same patterns coming back. Not as incidents, but as structural pitfalls. Below the five most common ones.

Scope creep

Scope creep is the biggest budget killer in ERP projects. It starts innocently: “Could we quickly include the CRM integration too?” And: “While we’re at it, let’s add the webshop integration as well.”

Each scope expansion looks logical on its own. But added together, the schedule slips by months and the budget swells significantly. Scope creep doesn’t arise from poor planning, but from the absence of a clear change request process.

In our experience, scope creep causes ERP projects to overrun budget by 25 to 40% on average. This is because expansions are not handled as formal change requests and quietly slip into the project.

Our advice: set up a change control board at the start. Every change to scope goes through that board, with an impact analysis on budget, schedule and risk. Not to block flexibility. To make conscious choices.

Insufficient change management

A new ERP system changes how people work. Every day. For every user. And people don’t like change. Not because they are stupid or unwilling, but because change brings uncertainty.

According to Prosci research (2023), poor change management is the number one cause of failed ERP implementations. Not the technology. Not the budget. Just the fact that nobody brought employees along on the why.

What works: start communicating early. Not with directives from the boardroom, but with sessions on the work floor. Show key users what is going to change and why. Make room for resistance. And involve the works council early, not as a formality but as a serious counterpart.

Data migration underestimated

We mentioned it in the phases section, but it bears repeating: data migration is the part that most often produces surprises. The data in your current system is almost never clean. There are duplicate customer records, items without category, open orders from three years ago that nobody recognises anymore.

Start cleaning up your data at least three months before go-live. Not as an IT project, but as a business project. The department that uses the data must clean the data. Only they know which records are relevant and which aren’t.

Insufficient testing

We see ERP projects where the test phase is cut from four weeks to one week “because we’re behind schedule.” That is like skipping the safety inspection on a bridge because the deadline is approaching.

Insufficient testing leads to problems at go-live that are far more expensive to fix than the extra test time would have cost. Plan a ratio of one to five. One unit saved on testing costs you five units in damage control after go-live.

Wrong go-live strategy

Big bang or phased? The question sounds simple, but the answer depends on your specific situation. With a big bang go-live, you switch from the old to the new system over a single weekend. With a phased approach you roll out per location, per department or per module.

We see that manufacturers with tight supply chains are often better off with big bang, because parallel systems are confusing on the shop floor. Services organisations with multiple locations more often choose phased, because each location can move at its own pace. Read more about the trade-offs in our article on waterfall versus agile ERP implementation.

The role of the project team

An ERP implementation is only as good as the team that runs it. And we don’t mean the consultants, we mean your own people.

In our experience, the success of an ERP project depends for 60 to 70% on the internal organisation. This is because external consultants know the system, while only internal employees understand the business processes, the exceptions and the culture.

The steering committee

The steering committee is made up of the board members sponsoring the project. Their role is not to be involved daily, but to take decisions when they are needed. Release budget. Approve or reject scope changes. And signal to the organisation that this project has priority.

We advise a steering committee of no more than five people. Anything more becomes unmanageable. At a minimum the CEO or COO, the CFO and the IT director. The steering committee meets every two to four weeks, depending on the phase.

The project manager

The project manager is the linchpin of the programme. Internal or external, that depends on your situation. But one thing is non-negotiable: the project manager must have enough mandate to make decisions. A project manager who has to escalate every decision to the steering committee slows the project down.

For larger ERP projects (more than 100 users) we recommend a duo: an internal project manager who knows the organisation and an external one who masters the ERP implementation methodology. That sounds expensive, but it prevents far bigger costs further down.

Key users

Key users are the bridge between the project team and the work floor. They know the processes, they test the system, they train their colleagues and they are the first point of contact after go-live. Don’t choose key users based on availability, but based on knowledge and influence.

A good key user is someone who knows the current process inside out, dares to be critical, and is respected by colleagues. These are often your best people. Yes, that means they are temporarily less available for their regular work. But that investment repays itself many times over.

IT

IT plays a supporting but essential role. They take care of the technical infrastructure, the integrations with existing systems and security. With cloud ERP, their role shifts from “keeping the system running” to “monitoring the integrations and data flows.”

A common mistake: handing IT full responsibility for the ERP project. An ERP implementation is a business project, not an IT project. IT is an important part of the team, but the business must steer.

Why internal involvement matters more than external consultants

We say this as a firm that itself provides external consultants, so take it seriously: your internal team matters more than we do. Consultants bring expertise on the ERP system and implementation methodology. But it is your own people who know how the business works, what customers expect, and where the exceptions sit.

The organisations where ERP implementations run best are those where management frees up internal capacity. Where, in our experience, key users can dedicate at least 50% of their time to the project. And where the board is visibly involved, not just in steering committee meetings but on the work floor as well. If you are weighing whether to handle implementation in-house or outsource your ERP implementation, this internal-capacity question is the most important one.

ERP implementation cost and timeline

Let’s be honest about cost. Most articles online give you a margin so wide it becomes useless. We prefer to make it concrete by thinking in ratios, rather than in absolute amounts that differ for every organisation.

The total investment in an ERP implementation breaks down, in our project experience, roughly into two parts: about 30% goes to software licences and around 70% to implementation, guidance, training and hypercare. That ratio holds remarkably steady across different kinds of organisations.

Cost item	Share of total budget (in our experience)
Software licences or SaaS subscription	25 to 35%
Implementation and configuration	30 to 40%
Data migration	5 to 15%
Training and change management	10 to 15%
Hypercare and optimisation	5 to 10%
Contingency (buffer)	10 to 15%

On timeline: plan for 6 to 18 months for a full implementation. Organisations with simple processes sit at the shorter end. Organisations with multiple locations, complex production processes or international operations sit at the longer end.

A tip we always give: in our experience, plan a contingency buffer of at least 15% on both budget and schedule. Not because you expect things to go wrong. Because ERP projects by definition contain unpredictable elements. For more on cost ratios per platform, see our complete ERP selection guide.

Customisation versus configuration

This is one of the most loaded debates in any ERP project. Your current process doesn’t fit the standard system. What do you do? Adapt the process to the software, or adapt the software to the process?

Our position is clear: always choose configuration over customisation, unless the process delivers a demonstrable competitive advantage. Customisation is more expensive to maintain, harder to upgrade and increases dependency on specific consultants.

That doesn’t mean customisation is always wrong. There are situations where it is unavoidable. A production process that is your point of differentiation. An industry-specific workflow that no standard package supports. An integration with a legacy system you still need for the next five years.

But be critical. In our experience, 60 to 70% of the customisation that organisations request is not necessary. The existing process is “just how it grew”, and the standard process in the ERP package is objectively better. The resistance comes not from a business consideration, but from habit.

Read more about this trade-off in our extensive article on customisation versus configuration in ERP systems.

The 10 requirements for a successful ERP implementation

Based on our project experience, we have identified ten conditions that determine whether an ERP implementation succeeds. From board involvement to data ownership, from realistic planning to a clear go-live strategy. Each of those requirements is built on hundreds of lessons from practice.

Want to test your own project against these requirements? Read the full article. It gives you a concrete framework you can take into your steering committee meeting.

What if it still goes wrong?

Sometimes things go wrong, despite all the preparation. Go-live stalls. The data doesn’t add up. The project team falls out with the implementation partner. These are scenarios nobody wants, but they happen more often than you’d think.

In that case, the important thing is to act quickly. Not by pushing harder on the same approach. By stepping back and looking at the situation objectively. Sometimes that means restarting the test phase. Sometimes a scope reduction. And sometimes bringing in independent expertise for a second opinion.

We have experience with this. Read more about our approach to damage control on ERP implementations.

Frequently asked questions

How long does an ERP implementation take?

An ERP implementation typically takes 6 to 18 months for mid-sized organisations, in our experience. The duration depends on the number of users, the complexity of your processes and the chosen implementation strategy. A simple Dynamics 365 Business Central implementation for 30 users can be done in 6 months. A multi-site SAP S/4HANA implementation easily takes 12 to 18 months. Always plan a 15% buffer on your original schedule.

What does an ERP implementation cost?

ERP implementation costs vary widely per organisation, but the proportions remain remarkably constant. As a rule, roughly 30% goes to software licences and 70% to implementation, guidance, training and hypercare. In our experience, licence cost makes up 25 to 35% of total budget. Implementation and guidance is the largest share at 30 to 40%. Don’t forget the hidden cost: data cleansing, change management and internal time of key users. These are structurally underestimated.

Why do ERP implementations fail?

According to Panorama Consulting (2024), ERP implementations fail in 75% of cases due to organisational causes, not technical ones. The three biggest causes are: poor change management where employees are not brought along, scope creep where the project grows uncontrolled, and insufficient internal involvement which turns the project into an IT matter instead of a business one. Lack of board involvement is the most predictive factor of failure.

What is the difference between big bang and phased implementation?

With a big bang implementation, the entire organisation switches to the new system at once. With a phased implementation, you roll out per location, department or module. Big bang is faster and avoids the complexity of parallel systems, but carries more risk at go-live. Phased is safer and gives room to learn, but takes longer and can be confusing when two systems run side by side. Manufacturers more often choose big bang; services organisations more often choose phased.

How do you choose a reliable ERP implementation partner?

A good ERP implementation partner has industry experience, a methodical approach and the mandate to make decisions. Don’t choose on the lowest rate alone. Look at the combination of craftsmanship and cultural fit with your organisation. Test who actually ends up on your team during selection, not just the account manager. A partner that says yes too easily to every wish rarely delivers durable solutions. Our ERP selection guide covers the full set of criteria we apply.

Your ERP implementation starts with the right conversation

A good ERP implementation doesn’t start with software. It starts with understanding what your organisation actually needs. And that understanding emerges in conversation, not in a proposal.

We are ERP Company. Independent, no vendor ties, no hidden agendas. With 265+ specialists who share one thing: they have done this before. Not for the first time, but for the tenth, the twentieth, sometimes the fiftieth.

Are you at the beginning of an ERP journey? Or in the middle of a project that is going off the rails? Get in touch for a no-strings conversation. Not a sales pitch. An honest conversation about what your project actually needs.

See our implementation services for more on how we guide organisations from kickoff to go-live, and beyond.

Further reading: For a vendor-neutral view, see our independent ERP advice guide.