An ERP implementation in Saudi Arabia follows the same core phases as anywhere else: discovery and fit-gap, design, build and configuration, data migration, testing, training, cutover and hypercare. What makes it succeed is less the software than the people and decisions around it: a sponsor who resolves conflicts, process owners who make design calls, key users who have real time for the project, and Saudi requirements such as ZATCA e-invoicing, VAT, Arabic documents and payroll obligations built into the design from the start.
Go-live dates usually slip for predictable reasons. This guide explains each phase, who is responsible for what, which local requirements to plan for, what typically causes delay, and how to judge whether you are genuinely ready to go live. It is written for executives, finance and operations leaders, and IT heads who are about to start an implementation or are worried about one already underway. If you are still choosing a system, start with our guide on how to choose an ERP in Saudi Arabia.
The eight phases of an ERP implementation
Methodologies use different names, and agile approaches repeat some phases in cycles, but every implementation has to get through the same work. Treat each phase as having a clear exit: a document or decision that is reviewed and signed off before the next phase depends on it.
- Discovery and fit-gap. Confirm scope, document current processes and compare requirements against what the chosen ERP does as standard. Each requirement is classified as standard fit, configuration, extension or process change. Our ERP fit-gap analysis guide covers this phase in detail. Exit: an agreed fit-gap register and a scope baseline.
- Design. Define how each to-be process will run in the new system: organization structure, chart of accounts, cost centers, approval workflows, document numbering, tax setup, reports and integrations. Exit: signed solution design documents and an integration design.
- Build and configure. Configure the system to the design and develop only the extensions, reports, forms and integrations the fit-gap approved. Work in iterations and show results to key users regularly rather than revealing everything at the end. Exit: a configured system ready for testing.
- Data migration. Decide what moves (master data, open transactions, opening balances, limited history), cleanse it at the source, map it to the new structures, and run several trial loads with reconciliation. Exit: a successful rehearsal load that finance and operations have reconciled.
- Testing. Unit and system testing by the build team, integration testing across connected systems, then user acceptance testing (UAT), where key users run real business scenarios end to end with migrated data. Exit: UAT sign-off with no open critical defects.
- Training. Train key users first, then end users by role, using the actual configured system and your own data. Short role-based guides work better than generic manuals. Exit: trained users who can complete their daily tasks unaided.
- Cutover. Freeze legacy transactions, load final data, reconcile balances, switch integrations and open the new system for business. A cutover plan lists every task, owner and checkpoint, along with a rollback decision point. Exit: go-live approval from the sponsor.
- Hypercare. A period of intensive support after go-live, with the project team on hand to fix issues quickly, monitor first period-end processes and confirm that integrations, e-invoicing and reports work in production. Exit: a planned handover to steady-state support.
Phase gates and deliverables
| Phase | Main deliverable | Signed off by |
|---|---|---|
| Discovery and fit-gap | Fit-gap register, scope baseline | Sponsor and process owners |
| Design | Solution and integration design | Process owners and IT |
| Build and configure | Configured system, approved extensions | Project manager and key users |
| Data migration | Reconciled rehearsal load | Finance and data owners |
| Testing | UAT results, defect log | Process owners |
| Training | Trained users, role guides | Department heads |
| Cutover | Cutover plan and go-live checklist | Executive sponsor |
| Hypercare | Issue log, handover to support | Sponsor and IT |
Who does what: roles and responsibilities
An ERP is a business project that uses technology, not an IT project that the business attends. The roles below need named people before design starts.
| Role | Responsibility | Typical source |
|---|---|---|
| Executive sponsor | Owns the business case, resolves cross-department conflicts, approves scope changes and the go-live decision | Senior leadership |
| Project manager | Plans, tracks risks and issues, controls scope, coordinates internal teams and the partner | Internal, often paired with the partner’s project manager |
| Process owners | Make design decisions for their area (finance, procurement, sales, warehouse, production, HR) and sign off UAT | Department heads |
| Key users | Explain current work, test the system, train colleagues and support them after go-live | Experienced staff from each department |
| IT | Infrastructure, security, access, integrations with other systems, and long-term support | Internal IT team |
| Implementation partner | Configuration, development, migration tooling, methodology and product expertise | External consultancy |
Two points matter more than the chart itself. First, the sponsor must be senior enough to settle disagreements between departments; otherwise design decisions stall in committee. Second, key users need protected time. If they are expected to run the project on top of a full workload, testing becomes shallow and training is rushed. Backfilling their roles during the busiest phases is a sound investment.
Saudi-specific requirements to plan for
Several requirements are specific to operating in the Kingdom. Each should appear in the fit-gap register, the design documents and the UAT scripts, not on a list of things to sort out after go-live.
ZATCA e-invoicing integration
The Zakat, Tax and Customs Authority (ZATCA) e-invoicing program has two phases: Phase 1 (generation) and Phase 2 (integration). Under Phase 2, the ERP or a connected solution must integrate with ZATCA’s FATOORA platform so that standard tax invoices are cleared and simplified tax invoices are reported, with the required XML format, QR codes and cryptographic stamps. Plan the integration route (native, add-on or middleware), test it in ZATCA’s test environments, and include credit and debit notes, error handling and retries in UAT. Our ZATCA Phase 2 integration guide explains the technical requirements. Specifications change over time, so check current requirements at zatca.gov.sa.
VAT configuration
Tax codes, standard-rated, zero-rated and exempt supplies, reverse charge on imported services, VAT on advance payments and the figures needed for the VAT return all need to be designed and tested with your finance and tax advisers. Migrated open documents must carry the correct tax treatment.
Arabic, bilingual documents and right-to-left interfaces
Customer-facing documents such as tax invoices, delivery notes and statements often need Arabic or bilingual layouts. Test printed output and PDFs with real Arabic customer and item names, mixed Arabic and English text, and right-to-left screens if users will work in Arabic.
Hijri and Gregorian dates
Not every company needs Hijri dates, but some contracts, government correspondence and HR records use them. If you do, define where Hijri dates must display or print alongside Gregorian dates, and test conversion on documents and reports.
Payroll, GOSI and wage protection
If HR and payroll are in scope, design for local obligations from the start. Employers register employees and their contributory wages with the General Organization for Social Insurance (GOSI), so payroll data and GOSI records must stay consistent. Under the Ministry of Human Resources and Social Development’s Wage Protection Program (often called WPS), establishments submit employee wage files through the Mudad platform. Confirm how the ERP produces the payroll outputs you need, how salary changes flow to those records, and who checks them each month. Rules and file requirements change, so confirm current obligations with GOSI, the Ministry of Human Resources and Social Development and your payroll advisers.
What delays go-live: common mistakes
Go-live dates rarely slip because of one dramatic failure. They slip because of familiar problems that were visible early and not acted on.
- Unclear scope. If the contract and fit-gap do not state exactly which processes, entities, sites and integrations are in scope, every workshop reopens the boundary. Agree a scope baseline and a change-request process before design starts.
- Dirty data. Duplicate customers, inconsistent item codes, missing units of measure and unreconciled balances surface during trial loads. Cleansing takes business judgment, not just IT effort, so start it during discovery.
- Under-resourced key users. When key users cannot attend design sessions or test properly, decisions wait and defects are found late, often in UAT or after go-live.
- Customization creep. Each request to make the new system behave like the old one adds build, testing and upgrade effort. Challenge every gap: change the process unless regulation or real differentiation requires the extension.
- Late integration testing. Integrations with ZATCA, banks, e-commerce, warehouse or production systems are often tested last, and with dummy data. Test them early, end to end, with realistic volumes and documents.
- Training as an afterthought. Users trained on a generic demo system, weeks before go-live, will work around the ERP. Train on the configured system and repeat for anyone who missed it.
- No cutover rehearsal. A cutover that has never been rehearsed tends to overrun. Run at least one full rehearsal, including data loads and reconciliation, and time it.
- Weak decision-making. Open design questions that nobody owns can stall a whole workstream. Keep a decision log with owners and deadlines, and escalate to the sponsor quickly.
Go-live readiness checklist
Go live because the criteria are met, not because the date has arrived. Agree these criteria at the start of the project, review them at a formal go/no-go meeting, and record who signed off.
| Area | Ready when |
|---|---|
| Scope and design | All in-scope processes are configured as designed; deferred items are documented and accepted |
| Testing | UAT is signed off by process owners; no open critical or high-priority defects; workarounds for remaining issues are agreed |
| Data | Final migration rehearsal is reconciled for balances, open items and master data; data owners have signed off |
| ZATCA and VAT | E-invoices, credit and debit notes are produced and submitted correctly in testing; VAT setup is approved by finance |
| Documents | Arabic and bilingual invoices, delivery notes and statements print correctly |
| Integrations | Every integration is tested end to end, with monitoring and error alerts in place |
| Payroll | Parallel payroll run reconciles with the legacy system, where payroll is in scope |
| Users and access | Users are trained, role-based access is set up and reviewed, and segregation of duties is checked |
| Cutover | Cutover plan is rehearsed, legacy freeze is communicated, and a rollback decision point is defined |
| Support | Hypercare team, issue log, escalation path and steady-state support handover are agreed |
If an item is not ready, the go/no-go meeting should decide openly whether to proceed with a documented workaround, reduce scope for the first release, or move the date. Each of those can be a sound decision; drifting into go-live without one is not.
Frequently asked questions
How long does an ERP implementation take in Saudi Arabia?
It depends on scope, number of entities and sites, the amount of customization and integration, data quality and how much time your own people can give the project. Rather than starting from a target date, build the plan from the phases and phase gates above, then test whether the internal resources exist to meet it.
What is the difference between UAT and system testing?
System and integration testing check that the configured solution works technically and that connected systems exchange data correctly. User acceptance testing is run by key users, who execute real business scenarios with migrated data to confirm the system supports how the business will work. UAT sign-off belongs to the process owners, not the implementation partner.
Should we go live in one big bang or in phases?
A single go-live shortens the period of running two systems but concentrates risk. A phased rollout by module, entity or site reduces risk per release but needs temporary integrations between old and new systems. The right choice depends on how tightly your processes are connected, your appetite for risk and your period-end calendar.
What does hypercare include?
Hypercare is intensive support immediately after go-live. The project team stays close to users, resolves issues quickly, watches the first transactions, e-invoice submissions and period-end close, and fine-tunes configuration. It ends with a planned handover to steady-state support.
Can ZATCA e-invoicing be added after the ERP goes live?
It can be technically, but it is risky. Invoicing is central to order-to-cash, and changing it after go-live means retesting a live process. Design and test e-invoicing as part of the implementation so that compliant invoices are issued from day one.
Planning your implementation
AIMLTS runs ERP rollouts end to end, including configuration, data migration, integration, training, change management and hypercare, against a scope and milestones you sign off before we build. We work with Dynamics 365, Odoo, SAP, Oracle and custom ERP. Learn more about our ERP Implementation, ERP Solutions and ZATCA & E-Invoicing services, or book a discovery call to talk through your plan.