ERP implementation: phases, approach and checklist

An ERP implementation runs in five phases: preparation, selection, implementation, data migration and go-live with stabilisation. Success is not decided by the software but by what is settled before the start: a governance that can decide, a cleansed data foundation and a scope that is genuinely agreed. The duration is measured by the complexity of the business, not by a sales promise. This page walks through the phases, names the decisions that carry each phase and ends with the checklist of the twelve points that must be settled before kickoff.

The five phases of an ERP implementation

The order is the same in almost every project, the weighting is not. Knowing the phases lets you see early where your own project stands and which decision comes next.

1. Preparation. Describe the core processes, take honest stock of the data, name the owners. This is where the basis for every later decision is created, and where it is cheapest to make.
2. Selection. Assess system and partner against your own requirements, not against demos. Prioritised requirements beat a thick requirements document.
3. Implementation. Map the processes in the system, standard before customisation. Every extension needs a reason that lies in the business, not in habit.
4. Data migration. Bring master data over cleansed, with at least two complete test runs. The migration belongs in the project plan, not at the end.
5. Go-live and stabilisation. Start against measurable criteria, not against the calendar. After that the system belongs in a rhythm that carries change as routine.

What must be settled before the project starts

The most expensive problems of an ERP implementation arise before kickoff, and that is also where they are cheapest to solve. Three things belong settled before a partner writes the first hour: who steers the project and decides scope questions bindingly, what state the master data is in and what part of it gets cleansed before the migration , and which processes really carry the business. The full list is in What must be settled before the project starts.

The most common mistake is not the wrong software but starting without the ability to decide: a project without a named decision-maker renegotiates every deviation, and decisions take calendar time, not consulting days. That is exactly where implementations most often run long.

How long does an ERP implementation take?

For simple setups with one legal entity, processes close to the standard and a clean data foundation, a few months are realistic. For complex transformations with legacy replacement, several entities or deep manufacturing this does not hold, and a tight deadline that snaps costs more than an honest range that holds. What really drives the duration and when a fast timeline is defensible is covered in How long does a Business Central implementation really take?

If a running implementation is already dragging, the cause is rarely the partner’s pace and almost always open decisions. The diagnosis for it: Why is our ERP implementation taking so long?

What does an ERP implementation cost?

The costs consist of licences, implementation and the internal effort, and the third block is the one most often underestimated: people who describe processes, check data and make decisions. How the blocks add up and how to spot an offer that is calculated too tightly is covered in What does a Business Central implementation cost?

If the budget is already running away, speed alone will not help. The orderly way back is described in ERP project over budget: what now?

Why implementations fail and how you counter it

ERP implementations rarely fail on technology. They fail on structures: a governance that cannot decide, a scope that was never agreed, reports showing green while the system is red. These patterns are recognisable early, the overview is in Why ERP projects fail.

The most effective countermeasure is a defined moment of truth before the start: measurable criteria that decide whether the project may go live. Which ones they are is covered in When is a Business Central project ready for go-live?

The pre-kickoff checklist

Twelve points that must be answered before the project starts. An open point is not an obstacle, but it belongs named before it gets expensive inside the project.

1. The core processes are described, at least order-to-cash and purchase-to-pay.
2. A decision-maker with time and mandate is named, deputisation settled.
3. The scope is agreed in writing, including what explicitly does not belong to it.
4. The state of the data is measured: duplicates, empty fields, inactive records per data object.
5. It is decided which legacy data comes along and which stays in the archive.
6. The deviations from the standard are listed, each with a business reason.
7. The interfaces to surrounding systems are named, each with an owner.
8. The key users are named and released for the project, not just nominated.
9. A realistic timeline with disclosed assumptions is on the table, not a wishful number.
10. The budget covers all three blocks: licences, implementation, internal effort.
11. The go-live criteria are defined upfront, measurable and agreed.
12. Operations after go-live are planned: owners, release rhythm, change routine.

Answer these twelve points honestly before kickoff and you have defused the most common project risks before the start. If you cannot answer individual points, that is exactly the starting position for a conversation, not for signing a contract. Steering stays on your side, with Business Central as home.

Source: Microsoft Learn: update cycles for Business Central