ERP implementation is the sequence of work that takes a business from "we need a new system" to people running daily operations in it with trusted data. It usually runs in seven phases: discovery, design, build or configuration, data migration, testing, training and go-live, then post-go-live support. Each phase should end with a signed deliverable, not just a date.
The phases are the same whether you implement a packaged suite or a custom-built ERP. What changes is the middle: with a package you configure and extend, with a custom system you build. This guide sets out what each phase is for, what it must produce, who has to be involved, and what really drives the timeline. If you want a partner to run the whole programme with you, our ERP implementation services page explains how we work; if the right answer may be a system built around your processes, see custom ERP software.
What are the main phases of an ERP implementation?
Seven phases cover almost every ERP project. Small projects compress them; large or multi-entity projects repeat some of them per site or per company.
| Phase | Purpose | Deliverable that closes it | Main sign-off |
|---|---|---|---|
| 1. Discovery | Understand current processes, pain points and constraints | Current-state process maps, requirements list, scope statement | Sponsor |
| 2. Design | Decide how each process will run in the new system | Solution design, data model or configuration design, integration list, report list | Product owner and process owners |
| 3. Build or configure | Make the system do what the design says | Working modules in a test environment, demonstrated in short cycles | Product owner |
| 4. Data migration | Move master data, balances and open items | Mapping document, two or more trial loads, reconciliations | Data owners |
| 5. Testing | Prove end-to-end processes work with real data | Test scripts, defect log, user acceptance sign-off | Key users and process owners |
| 6. Training and go-live | Prepare people and switch over | Trained users, cut-over run book, go or no-go decision | Sponsor |
| 7. Post-go-live support | Stabilise and hand over | Hypercare issue log, first month-end close completed, support handover | Sponsor and finance lead |
Phases overlap in practice. Data migration starts during design, and training material is written while testing runs. What matters is that no phase is declared finished until its deliverable exists and the right person has signed it.
Phase 1: Discovery — what do you need to know before anything is designed?
Discovery answers three questions: how the business works today, what has to change, and what is out of scope. It is the cheapest phase in which to change your mind.
Typical activities:
- Workshops with each department, walking through real documents: a sales order, a goods receipt, a supplier invoice, a month-end pack
- A list of the systems the ERP must replace or connect to
- A list of the reports and controls finance and management depend on
- Volumes: number of users by role, transactions per day, entities, currencies, warehouses
- Constraints: deadlines tied to a financial year end, a lease ending on an old server, a regulatory change
The output is a requirements list and a scope statement. If you are still choosing a system, this is also where an RFP comes from; our ERP RFP template shows how to structure it.
Phase 2: Design — how will each process run in the new system?
Design turns requirements into decisions. For each process, someone writes down how it will work in the new ERP, which fields and approvals it uses, and what happens at the edges: returns, partial deliveries, credit holds, cancelled orders.
Design deliverables usually include:
- Future-state process flows for each in-scope process
- A data model or configuration design: chart of accounts, item structure, customer and supplier categories, cost centres
- An approval and permissions matrix by role
- An integration list: each connected system, what flows in which direction, and how often
- A report and dashboard list with owners
This is also when you decide the module order. Our guide to which ERP modules to implement first covers how to sequence finance, inventory, sales, purchasing and the rest.
Phase 3: Build or configure — how do you keep it on track?
Build in short cycles and show working software at the end of each one. Whether the team is configuring a package or writing code, the product owner should see each process running with realistic data every few weeks, not once at the end.
Practical rules for this phase:
- Keep a single backlog of requirements, ordered by business priority
- Demonstrate finished processes, not finished screens
- Log every change request against the agreed scope, with its effect on cost and timeline, before work starts
- Keep configuration and code in version control, with separate development, test and production environments
Phase 4: Data migration — when should it start?
Start migration work during design, not after build. Data cleansing and mapping take longer than most teams expect, and two trial loads need calendar time. Our step-by-step ERP data migration plan covers profiling, cleansing, mapping, trial loads and reconciliation in detail.
Phase 5: Testing — what has to be proven before go-live?
Testing proves that complete business processes work, with migrated data, by the people who will use them. It usually has three layers: unit or configuration testing by the delivery team, integration testing across modules and connected systems, and user acceptance testing (UAT) by key users following written scripts. Our ERP UAT testing plan gives a script format and exit criteria.
Phase 6: Training and go-live — how do you switch over safely?
Train by role, on the test system, using the team's own data and documents. Then cut over using a written run book that has been rehearsed. Our ERP go-live checklist lists the readiness checks for the go or no-go meeting.
Phase 7: Post-go-live support — when is the project actually finished?
The project is finished when the first month-end close in the new system is complete and reviewed, the issue log is under control, and support has been handed over to whoever runs the system from then on. Plan a hypercare period with daily check-ins until at least that first close.
Who needs to be on the ERP implementation team?
An ERP project needs named people in the business, not just a supplier. These roles are the minimum, though one person may hold more than one in a smaller company.
| Role | Responsibility | Typical person |
|---|---|---|
| Executive sponsor | Owns the business case, settles disputes between departments, makes the go or no-go call | Managing director, CFO or COO |
| Product owner | Prioritises requirements, accepts or rejects delivered work, available every week | Senior operations or finance manager with time freed up |
| Process owners | Decide how their process will run and sign off its design | Head of each department in scope |
| Key users | Test, give feedback, train colleagues | Experienced staff from each team |
| Data owners | Decide what correct data is and sign off migration tie-outs | Finance controller, credit control, inventory lead |
| Project manager | Plan, risks, issues, status reporting | Supplier side, client side, or both |
| Solution architect or lead consultant | Design integrity, integrations, technical decisions | Supplier side |
The role most often missing is a product owner with real time to give. If that person only attends a monthly steering meeting, decisions queue up and the build team starts guessing.
How long does an ERP implementation take?
There is no honest single answer; duration depends on scope and readiness more than on software. Treat any timeline quoted before discovery as a guess. These are the factors that move it most:
- Number of modules and entities. Finance only for one company is a different project from finance, inventory, manufacturing and payroll across five companies in three countries.
- Data quality. Clean, consistent source data shortens migration; duplicates and missing fields lengthen it.
- Integrations. Each connected system (e-commerce, banking, payroll, CRM, logistics) adds design, build and testing.
- Decision speed. Projects stall when design questions wait weeks for an answer.
- Customisation level. The further the system moves from standard behaviour, the more build and testing it needs.
- Fixed dates. A go-live tied to a financial year start can force a phased plan.
A phased approach, putting finance and one core operational module live first, usually reduces risk compared with switching everything on at once.
Illustrative example: a phased plan for a distributor
This example is illustrative, not a client case. A distributor with two companies, one warehouse each, and a web shop wants to replace spreadsheets and an old accounting package.
- Discovery and design cover all areas, but the plan splits go-live into two releases.
- Release 1: finance, purchasing, inventory and sales for the larger company, with the web shop integration. Two trial migrations; UAT by four key users; go-live at a month start.
- Hypercare until the first close is complete.
- Release 2: the second company, intercompany transactions and consolidated reporting, reusing the tested configuration.
The second release is faster and safer because the processes, data rules and training material already exist.
ERP implementation checklist
Use this to check that each phase is really closed.
- Sponsor and product owner named, with time allocated
- Scope statement signed, including what is out of scope
- Future-state process flows signed by each process owner
- Integration list and report list agreed
- Change request process agreed before build starts
- Working modules demonstrated in short cycles
- Mapping document complete; two trial loads reconciled
- UAT scripts passed and signed by key users
- Users trained by role on the test system
- Cut-over run book rehearsed; go or no-go recorded
- First month-end close completed in the new system
- Support handover and documentation complete
When is a full phased implementation not the right approach?
A seven-phase programme is too heavy for some situations. If you only need one gap filled, for example job costing alongside accounting software you are happy with, a focused module or an integration may be enough. If the business is still changing its model month to month, design decisions will not hold, and a smaller tool may serve better until processes settle. And if your requirements are close to what a standard package does out of the box, a short configuration project with the vendor's partner can beat a long programme.
How to start your ERP implementation
Before you talk to any supplier, prepare four things: a one-page summary of why you are doing this and what success looks like, a list of in-scope processes and entities, a list of current systems and reports, and the names of your sponsor and product owner. Our software requirements brief template gives a format you can fill in.
Then discuss the project with us. Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, so your team can test working software against your own processes before committing to the whole implementation.