An ERP project cannot be improvised. Whether you are replacing an aging system or deploying an ERP for the first time, success depends on a methodical breakdown into clearly defined phases. Each phase has its objectives, deliverables, and pitfalls. Ignoring them exposes you to budget overruns, cascading delays, and, in the worst case, outright project abandonment.
In this article, we detail the 5 essential phases of an ERP project, from the opportunity assessment through to post-go-live stabilization. For each stage, you will find the expected deliverables, key stakeholders, typical risks, and an indicative timeline. This article is part of our complete ERP implementation guide and complements the change management section.
Overview: The 5 Phases at a Glance
Before diving into the details, here is a summary table of the five phases. It provides a quick view of project progression and associated responsibilities.
| Phase | Indicative Duration | Main Objective | Key Deliverables |
|---|---|---|---|
| 1. Scoping & Opportunity Assessment | 2-4 weeks | Validate project relevance | Business case, scoping document, high-level plan |
| 2. Functional Design | 4-8 weeks | Define target operations | Design document, process maps |
| 3. Build & Configuration | 8-16 weeks | Construct the solution | Configured environment, custom developments |
| 4. Testing & Acceptance | 4-8 weeks | Verify compliance | Acceptance report, test results, migration plan |
| 5. Deployment & Stabilization | 2-6 weeks | Go live and secure operations | Go-live, deployment review, handover to support |
The total duration of an ERP project typically ranges from 6 to 18 months depending on company size, the number of modules deployed, and the level of customization required.
Phase 1: Scoping and Opportunity Assessment (2-4 weeks)
Objective
Scoping lays the project’s foundations. The goal is to answer a simple but decisive question: does this ERP project make sense for the business? This phase defines the functional scope, strategic objectives, preliminary budget, and major milestones.
Key Deliverables
- Business case: economic justification for the project (expected ROI, avoided costs, productivity gains).
- Scoping document: functional scope, modules involved, impacted sites, explicit exclusions.
- High-level plan: major milestones and target go-live date.
- Preliminary RACI matrix: who decides, who does, who is consulted, who is informed.
Key Stakeholders
- Executive management: strategic and budget validation.
- IT department: technical feasibility and infrastructure constraints.
- Business unit leaders: expression of priority needs.
- Project manager (internal or integrator): coordination and deliverable drafting.
Typical Risks
- Vague scope: imprecise scoping leads to constant change requests during the project. The more ambiguous the scope at this stage, the greater the overruns later on.
- Budget underestimation: forgetting training costs, data migration, or change management is a frequent mistake. The initial budget should include a contingency provision of 15 to 20%.
- No executive sponsor: without a committed senior leader, the project loses priority at the first sign of difficulty.
Phase 2: Functional Design (4-8 weeks)
Objective
Functional design translates business needs into specifications that the technical team can act on. This is the phase where current processes (as-is) and target processes (to-be) are mapped, identifying gaps with the chosen ERP’s standard functionality.
Key Deliverables
- General design document (GDD): description of target processes by functional domain (procurement, sales, manufacturing, finance, HR…).
- Process maps: flow diagrams for each major process.
- Gap analysis: features absent from the standard that require custom development or workarounds.
- Configuration workbook: retained configuration choices (chart of accounts, management units, approval workflows, etc.).
Key Stakeholders
- Key users (subject matter experts): business experts who validate target processes.
- Functional consultants (integrator): workshop facilitation and design documentation.
- Project manager: gap arbitration and scope management.
- Technical architect: validation of the feasibility of functional choices.
Typical Risks
- “We’ve always done it this way” syndrome: users replicate existing processes instead of leveraging the ERP standard. Result: costly custom developments that are difficult to maintain.
- Unavailable key users: if subject matter experts are not freed up sufficiently, the design will be incomplete or disconnected from operational reality.
- Late validation: each target process must be formally validated before moving to the build phase. Postponing validations creates a snowball effect.
Phase 3: Build and Configuration (8-16 weeks)
Objective
This is the construction phase. The technical team configures the ERP according to the design document, develops the identified customizations, prepares interfaces with third-party systems, and sets up data migration rules.
Key Deliverables
- Configured ERP environment: complete module configuration per the configuration workbook.
- Custom developments: custom reports, bespoke workflows, connectors with other applications.
- Interfaces and connectors: data flows with peripheral systems (CRM, e-commerce, BI tools, etc.).
- Migration scripts: extraction, transformation, and loading (ETL) programs for historical data.
- Technical documentation: description of configurations and developments completed.
Key Stakeholders
- Technical consultants (integrator): configuration and development.
- Developers: building custom components and interfaces.
- DBA / system administrator: setting up environments (development, testing, pre-production).
- Key users: ongoing unit testing and feedback on early prototypes.
Typical Risks
- Proliferation of custom developments: each customization increases technical debt and complicates future upgrades. The golden rule: stay as close to standard as possible.
- Poor data quality: data migration is often the neglected stepchild of the project. Inconsistent or duplicate data in the source system will cause cascading errors. Start data cleansing as early as possible.
- Interface delays: data flows with third-party systems depend on the availability of the teams responsible for those systems. Anticipating API delivery timelines is essential.
Phase 4: Testing and Acceptance (4-8 weeks)
Objective
Testing and acceptance verify that the built solution meets the requirements defined during design. End-to-end processes, data migration, performance, and security are all tested. This is the last line of defense before going live.
Key Deliverables
- Test plan: test scenarios covering all target processes, standard cases, and edge cases.
- Integration test workbook: verification of cross-module flows and interfaces with external systems.
- Dry-run migration report: results of loading real data into a pre-production environment.
- Acceptance report: formal document validating (or not) the move to production, signed by key users and project leadership.
- Cutover plan: precise sequencing of go-live actions (shutting down the old system, final migration, new ERP startup).
Key Stakeholders
- Key users: executing test scenarios and functional validation.
- Quality / business owner team: tracking defects and steering corrections.
- Consultants (integrator): fixing blocking and major defects.
- Project leadership: go/no-go decision.
Typical Risks
- Insufficient testing: testing only the “happy path” without covering error cases is a major source of post-go-live issues. Plan stress scenarios and edge cases (cancellations, credit notes, returns, fiscal year closings).
- Forced go-live despite blocking defects: schedule pressure sometimes pushes teams to deploy with unresolved critical bugs. This guarantees a chaotic launch. It is better to postpone by two weeks than to manage a production crisis.
- Unvalidated data migration: migration must be tested at least twice under real conditions before go-live. Discrepancies must be documented and corrected.
Phase 5: Deployment and Stabilization (2-6 weeks)
Objective
Deployment is the moment of truth: the ERP goes into production. Users switch to the new system. The stabilization period that follows (hypercare) is used to quickly fix residual defects, support users, and fine-tune initial settings.
Key Deliverables
- Successful go-live: completed cutover to the new ERP.
- Enhanced support (hypercare): dedicated support team with consultants and key users on-site or on call.
- Deployment review: summary of post-go-live incidents, applied fixes, and areas requiring attention.
- Handover to ongoing support: relay from the project team to the maintenance team (managed services or internal support).
- Continuous improvement plan: prioritized list of enhancements and optimizations to schedule after stabilization.
Key Stakeholders
- Full project team: maximum mobilization during the first days.
- Level 1 support (key users): first-line resolution for end users.
- Level 2 support (consultants): resolution of technical defects.
- Executive management: internal communication and visible project support.
Typical Risks
- Resistance to change: users facing a new system temporarily lose productivity. Without adequate support, frustration can escalate into rejection. This is where change management proves its worth.
- Undersized support: the first weeks after go-live generate a high volume of tickets. Planning a reinforced support team for 4 to 6 weeks is essential.
- Data loss during cutover: if the cutover plan is not followed rigorously, in-flight transactions in the old system can be lost. Plan a data entry freeze period and post-migration consistency checks.
Waterfall vs. Agile: How Does the Approach Affect the Phases?
The five-phase breakdown described above corresponds to a waterfall approach, sequential and linear. This is the most common model in ERP projects, particularly for large enterprises and ERPs like SAP or Oracle.
However, more and more projects are adopting an agile or hybrid approach, especially with ERPs like Odoo or ERPNext, which are more modular and faster to configure.
Key Differences
| Criterion | Waterfall Approach | Agile / Hybrid Approach |
|---|---|---|
| Breakdown | Strict sequential phases | Short iterations (2-4 week sprints) |
| Design | Exhaustive upfront | Progressive, by functional lot |
| Deliveries | Big bang or single batch | Incremental (module by module) |
| Change management | Formal change requests | Continuous backlog adaptation |
| Testing | Dedicated phase at end of project | Testing integrated into each sprint |
| Primary risk | Tunnel effect, late problem discovery | Lack of overall vision, technical debt |
| Best suited for | Large scope, heavy regulation | Evolving scope, SMBs, cloud ERP |
Practical Recommendation
For most ERP projects at SMBs and mid-market companies, a hybrid approach works well: maintain structured scoping and design (phases 1 and 2 in waterfall), then adopt an iterative approach for build, testing, and deployment (phases 3 to 5 in sprints). This preserves a clear view of scope while benefiting from agile flexibility.
Cross-Cutting Success Factors
Beyond following the five phases, certain factors determine project success.
Project governance. A regular steering committee with leadership and sponsors unblocks situations and maintains strategic alignment.
Risk management. Each phase should be accompanied by an updated risk register. Identifying a risk early means being able to address it before it becomes a problem.
Change management. It does not start at go-live. From scoping onward, you must communicate, involve users in design, train them before testing, and support them after deployment. For more detail, see our article on ERP change management.
Data quality. Migration is a project within the project. Starting data cleansing and normalization during phase 2 avoids unpleasant surprises in phase 4.
Summary
The five phases of an ERP project form a proven framework. Scoping ensures the project makes sense. Design translates needs into a solution. Build constructs that solution. Testing verifies it works. Deployment puts it in users’ hands.
Each phase prepares the next. Skipping steps means building on shaky foundations. Whether you choose a waterfall, agile, or hybrid approach, these five phases remain the pillars of any structured ERP project.
For further reading, see our complete ERP implementation guide.
