The software is rarely what sets the pace. Almost a quarter of organisations in Panorama's survey ran over schedule, and the most common reason was organisational: decisions, people and process changes. This guide explains each phase, what you need to provide, a 16-week plan for a distributor, what causes delays, and how to pick a go-live date in the UAE and Saudi Arabia.
What are the phases of an ERP implementation?
Seven phases, several of which overlap: discovery and design, configuration, data migration, testing, training, go-live and hypercare. Data migration runs longest, because it starts early with trial loads and ends with the final balances at cut-off.
The timeline below is an illustrative example for a mid-sized distributor with one company, three warehouses and around 40 users, not a standard plan. The worked example later in this guide walks through it week by week.
What happens in each phase, and what do you need to provide?
Each phase has a clear output, and each needs something from your side. Most delays happen when the customer's part of a phase isn't ready, not the vendor's.
| Phase | What happens | Output | What your team provides |
|---|---|---|---|
| Discovery and design | Workshops on each process: sales, purchasing, stock, finance, approvals | Signed design document | Process owners in the workshops; sample documents and reports |
| Configuration | The system is set up to the design: companies, chart of accounts, tax codes, workflows, layouts | A configured test system | Quick answers on design questions |
| Data migration | Masters cleaned and loaded in trial runs; final balances at cut-off | Clean data that ties back to the old books | Data owners for customers, suppliers, items and balances |
| Testing | Users run real scenarios end to end and log issues | Signed user acceptance | Testers with time set aside, and real test cases |
| Training | Key users trained first, then everyone on their own tasks | Trained users and short guides | Attendance |
| Go-live | Cut-off, final balances, first live transactions | The live system | Stock count; decision to go |
| Hypercare | Close support for the first weeks and the first month-end | Stable operations and a closed first month | Issues reported quickly, in one list |
The design document is the most important output of the whole project. Everything after it, including the price of change requests, is measured against it, so read it properly before signing.
How long does an ERP implementation take?
It depends on the company's needs and size. For a simple, small company it can start from 1–2 weeks. The figures below are illustrative examples of how scope stretches a project, from kickoff to go-live, not standard plans; hypercare adds about four weeks.
| Scope | Illustrative duration |
|---|---|
| Simple, small company; core finance and inventory; standard processes | From 1–2 weeks |
| One company; finance, inventory, sales, purchasing and e-invoicing, with a POS or e-commerce integration | Around 16 weeks, as in the worked example below |
| Several companies or countries; consolidation; several integrations | 6–12 months |
| Manufacturing, projects or heavy customisation | 9–12 months or more |
For comparison, Panorama Consulting's 2026 ERP Report, which surveyed 170 organisations of all sizes worldwide, found a median project timeline of nine months.
Three things move a project from one row to the next: the number of legal entities, the number of systems to integrate, and how much the processes depart from standard features. Each new company or integration adds design, testing and training, not just set-up.
What does a 16-week plan look like? A worked example
A food distributor in Riyadh has one company, three warehouses, 40 users and a fleet of van salesmen. It is implementing finance, inventory, sales, purchasing and ZATCA Phase 2 e-invoicing, and wants to go live at the start of a quarter.
| Weeks | Milestone | Who signs off |
|---|---|---|
| 1–4 | Design workshops for sales, van sales, purchasing, warehouses and finance; design document signed | Finance manager and operations manager |
| 3–9 | System configured; Arabic and English invoice layouts approved | Finance manager |
| 5–6 | First trial load of customers, suppliers and 3,000 items | Data owners |
| 9–10 | Second trial load, including open invoices and a test trial balance | Chief accountant |
| 10–13 | User acceptance testing: 60 scenarios, from quotation to cash and from purchase order to payment | Key users |
| 11–12 | Each van and warehouse device onboarded with ZATCA in the test environment | IT lead |
| 12–15 | Training: key users first, then salesmen and storekeepers | Department heads |
| 16 | Stock count, final balances, go-live on the first day of the quarter | General manager |
| 17–20 | Hypercare and first month-end close | Finance manager |
Three things keep this plan to 16 weeks: one company rather than several, standard processes rather than custom development, and named people on the customer side with time set aside. Remove any of the three and the plan stretches.
What delays ERP implementations?
Decisions and data, more often than software. In the projects HYP runs across the UAE and Saudi Arabia, the causes of delay are remarkably consistent.
| Cause | How it shows up | How to avoid it |
|---|---|---|
| No one with authority to decide | Design questions wait weeks for an answer | A project owner who can decide for the business |
| Key users fully booked on their day jobs | Testing slips, then training | Backfill or reduce their workload for the project weeks |
| Data cleaned too late | Trial loads fail; go-live moves | Start cleaning master data in week one |
| Scope added during the project | New reports and processes push testing back | A change log; non-essential items moved to phase two |
| Customisation to match old habits | Development and retesting add weeks | Adapt the process to standard features where you can |
| Integrations left to the end | POS, bank or e-commerce links fail in testing | Build and test integrations alongside configuration |
| Go-live date set before the plan | A rushed cut-over in a busy period | Fix the date only after design is signed |
The first two causes account for most delays we see, which matches Panorama's finding that organisational issues are the most common reason projects run late. Our data migration checklist covers the third.
When is the best time to go live in the UAE or Saudi Arabia?
At the start of a VAT return period, ideally a quarter or financial year, and outside your peak trading season. That keeps each tax return in one system and gives the team room to settle in.
| Consideration | Why it matters | What to do |
|---|---|---|
| Start of a VAT return period | A return split across two systems is harder to prepare and check | Go live on the first day of a monthly or quarterly return period |
| Financial year-end | Opening balances are clearest, and year-on-year reports start cleanly | Prefer 1 January, or your own year start, if the plan allows |
| Ramadan and Eid | Retail and F&B peaks; shorter working hours elsewhere | Avoid going live in the weeks before Eid |
| Summer leave | Key users often travel in July and August | Check leave plans before fixing the date |
| UAE e-invoicing | Business invoices must be e-invoices from 1 January 2027 for revenue of AED 50 million or more, and 1 July 2027 for most others | Go live early enough to set up e-invoicing once, in the new system |
| ZATCA Phase 2 | Each device or system that signs invoices must be onboarded | Onboard in the test environment during testing, and in production before go-live |
Pick the date after the design is signed, not before. A date chosen first tends to be defended long after the plan has shown it won't work.