The ERP Implementation Lifecycle
Every ERP project follows roughly the same shape, whatever the vendor calls it. Knowing the phases tells you what’s expected of you, and when.
The vendor methodologies
| Vendor | Methodology | Phases |
|---|---|---|
| SAP | Activate (formerly ASAP) | Discover → Prepare → Explore → Realize → Deploy → Run |
| Oracle | OUM / True Cloud Method | Inception → Elaboration → Construction → Transition → Production |
| Microsoft | Sure Step / Success by Design | Diagnostic → Analysis → Design → Development → Deployment → Operation |
| NetSuite | SuiteSuccess | Assess → Design → Build → Test → Deploy → Optimise |
| Generic | — | Prepare → Design → Build → Test → Deploy → Support |
They’re the same phases with different marketing. Learn the generic shape.
The phases
1. Prepare / Initiate
- Project charter, scope, budget, governance
- Team mobilisation, RACI
- Environments provisioned
- Standards agreed: naming, development, testing, documentation
- Kick-off and stakeholder alignment
Your job: set up development environments, source control, CI, and the development standards document. Do it properly now — retrofitting standards at month 8 doesn’t happen.
2. Explore / Design (Blueprint)
The most important phase, and the one most often rushed.
- Process workshops — walk through each end-to-end process with the business
- Fit-gap analysis — what the standard does vs what they need
- To-be process design — documented, agreed, signed off
- Functional specifications for each gap
- Data migration strategy
- Integration architecture
- Authorisation concept
- RICEFW list with estimates
Output: a Business Blueprint or Solution Design Document, signed off by process owners.
Your job: attend the workshops. Write technical specifications from the functional ones. Challenge requirements that could be configuration. Estimate the RICEFW list. The developers who sit in the workshops become architects; the ones who wait for specs stay juniors.
3. Realize / Build
- Configuration by functional consultants
- Custom development (RICEFW)
- Data migration programs built and test-loaded
- Interfaces built
- Authorisation roles built
- Unit testing throughout
- String testing — a sequence of related steps
- Integration testing — full end-to-end cycles across modules
This is the longest phase, typically 40–50% of the timeline.
Your job: build, unit test, document, and fix. Also: sit with key users while they test your objects. You’ll find more defects in an hour beside a real user than in a week of reading test scripts.
4. Test
Overlapping with build, but with distinct formal stages:
| Test type | Who | Purpose |
|---|---|---|
| Unit test | Developer | Does this object work? |
| String test | Consultant | Does this sequence work? |
| Integration test | Team | Do full cross-module cycles work? |
| UAT | Business users | Can we run our business on this? |
| Performance test | Technical | Will it work at production volume? |
| Security/authorisation test | Security | Can people do only what they should? |
| Regression test | Team | Did the last fix break something else? |
| Cutover rehearsal | Everyone | Can we actually go live in the window? |
| Parallel run | Business | Do old and new produce the same numbers? |
UAT sign-off by process owners is the gate to go-live. Not IT sign-off — business sign-off.
See Testing ERP.
5. Deploy / Cutover
The go-live window, usually a long weekend or a month-end.
- Final data migration
- Configuration and code transported to production
- Opening balances loaded and reconciled
- Interfaces switched on
- Users trained and access granted
- Go/no-go decision against agreed criteria
- Legacy system frozen or made read-only
See Cutover and Go-Live.
6. Hypercare / Run
- 2–8 weeks of intensive support with the project team still present
- Daily issue triage, defect fixing
- First month-end close in the new system — the real test
- Knowledge transfer to the support team
- Formal handover and project closure
- Benefits realisation review
Waterfall vs agile in ERP
The honest position:
Pure waterfall — the traditional approach. Long blueprint, long build, big-bang test. Predictable governance, and it fails badly when requirements were misunderstood, which they always partly are.
Pure agile — doesn’t fit an ERP core well. You cannot deliver “one third of a general ledger”. Financial correctness isn’t incrementally negotiable, and the org structure must be right before anything else can be built.
What actually works — hybrid:
Blueprint the foundation properly (org structure, chart of accounts, master data)
↓
Iterate everything above it (processes, reports, extensions, in sprints
with real user feedback each sprint)
↓
Big-bang or phased cutover (data and cutover are inherently waterfall)
The foundation is expensive to change; the surface is not. Structure your approach accordingly.
Agile ceremonies that genuinely help ERP projects: short sprints for RICEFW delivery, demos to key users every two weeks, a visible backlog with business-set priority, and retrospectives. What doesn’t work: pretending the chart of accounts can be refactored in sprint 14.
Rollout strategies
| Strategy | Description | Risk |
|---|---|---|
| Big bang | Everything, everywhere, at once | Highest risk, shortest total duration, no interim integration |
| Phased by module | Finance first, then supply chain, then manufacturing | Needs temporary interfaces between old and new |
| Phased by site/entity | One plant or country at a time | Longest duration, most learning, dual running |
| Pilot then rollout | Prove it at one site, then template it | The most common enterprise approach |
| Parallel run | Old and new simultaneously | Safest, double the work, exhausting for staff |
Template + rollout is the standard for multinationals: build a global template at a pilot site, then roll it out country by country with local variants for statutory requirements only.
The governance question that decides everything: how much local deviation from the template is allowed? Too little and local legal requirements break; too much and you have 14 different systems with one name. Establish a template governance board with the authority to say no.
Timeline reality
| Scope | Realistic duration |
|---|---|
| SMB, 1 entity, standard processes, cloud ERP | 3–6 months |
| Mid-market, 1–3 entities, some customisation | 9–15 months |
| Large enterprise, multi-country, one wave | 18–30 months |
| Global multinational programme | 3–7 years, multiple waves |
Add 30–50% to any estimate for data migration and testing. They are the two most consistently underestimated activities in the industry.
Why ERP projects fail
The research is consistent, and technology is rarely the cause:
| Cause | Share of failures |
|---|---|
| Poor change management — users resist, revert, work around | Very high |
| Inadequate executive sponsorship | Very high |
| Scope creep | High |
| Poor data quality / late migration | High |
| Insufficient testing, especially UAT | High |
| Over-customisation | High |
| Key users not released from their day jobs | High |
| Unrealistic timeline | High |
| Inadequate training | Medium |
| Technical failure | Low |
That last row matters for your career. Projects almost never fail because the code was bad. They fail for organisational reasons. The developers who understand this — and who help address it by making things usable, by explaining trade-offs clearly, by sitting with users — become the ones who get promoted.
Success factors
- A full-time, empowered project manager with the authority to say no
- Executive sponsor who attends steering meetings and makes decisions
- Key users released from their day jobs — 50%+ allocation, backfilled
- Standard-first bias with a documented, approved exception process
- Data cleansing started in month one, not month twelve
- Testing time protected and never sacrificed to the schedule
- Change management funded — training, communications, floor support
- A realistic timeline with contingency
- Post-go-live support planned and staffed before go-live
- Benefits measured after 6 and 12 months
What good looks like from a developer’s seat
- You attended the workshops and understand why, not just what
- Your technical specs are reviewed by the functional consultant before you build
- You challenged at least three requirements that turned out to be configuration
- Your objects are tested at production volume before UAT
- You sat with a real user testing your work
- Your code is in source control with a peer review
- You wrote the runbook before go-live, not after
- You were in the room for the first month-end close