Your ERP licence is signed and the demo looked flawless. Now comes the part that decides everything: choosing a cloud ERP implementation partner who will still answer the phone in month thirteen. In the Gulf, that choice sinks more projects than any feature comparison I have sat through.
The story I hear most often from finance directors in Dubai and Riyadh runs the same way. The reseller was charming, the licences arrived, then migration started and the bench turned out to be two juniors and a spreadsheet.
What does a cloud ERP implementation partner actually do?
A cloud ERP implementation partner turns your business into system configuration: chart of accounts, approval hierarchies, tax treatment, warehouse rules, migration from legacy systems, user acceptance testing, training and post-launch support. The software vendor supplies the platform and keeps it running. The partner supplies the judgement about how your company should use it, and carries the blame when it does not fit.
In my experience, that matters because ERP projects rarely fail on features. They fail in the unglamorous middle: customer records with three spellings of one company name, a stock valuation nobody can explain, an approval matrix that lives in the CFO's head. Software solves none of that. People with method do.
Judge a proposal by what the firm is contractually obliged to deliver, not by what it is enthusiastic about. Enthusiasm is free.
Partner, vendor and reseller carry different accountability
A vendor owns the product roadmap, the hosting and the uptime. A reseller owns the licence transaction and earns a margin on it. An implementer owns the outcome: that your finance team can close a month inside the new system. Plenty of Gulf firms sell all three under one brand, and the contract rarely states which one you actually bought.
Read the agreement with one question in mind: if the system is live but the numbers are wrong, whose problem is it? A resale agreement points you at the vendor's support desk, which points at configuration, which is yours. A real implementation contract names deliverables, acceptance criteria and a remedy period. It says who writes the migration scripts. It says who signs off testing and what happens if sign-off fails twice. It names your consultants. Its absence tells you what you are buying.
My take: when a proposal is mostly licence lines with one lump sum labelled "implementation services", you are looking at a resale with a services garnish. That can be the right purchase — just price it as one and staff the project yourself.
The vetting questions that expose a thin bench
Three questions separate a real implementer from a reseller: who personally performs the data migration, who owns user acceptance testing when it fails, and what support looks like in month thirteen once the launch team has moved on. Ask them in a room, out loud. A vague answer to any one of them is itself the answer.
So what does a good answer sound like? Specific. A named consultant, a written migration approach with dry runs, defined acceptance criteria, and response times that exist on paper.
Who writes the migration scripts?
If the answer is "you extract, we load", you have been handed the hardest job on the project.
Who owns UAT?
Someone must design test scripts, chase users and triage defects. Unnamed in the contract, that job defaults to your controller at month-end.
What happens in month 13?
Launch teams rotate off after hypercare. Ask who inherits your configuration and what a change request costs once the project budget closes.
Who is really on the bench?
Ask for CVs of the consultants who will sit in your office, not the partner presenting the pitch.
The substitution test
I ask one question at the end of every vendor meeting: which of the people in this room will be on site in week six? Silence, or a promise to "assign the right resource", predicts a thin bench better than any reference check. Firms with depth answer immediately, because their consultants are already scheduled.
In-house team, local partner or offshore partner?
Three delivery models exist for a cloud ERP implementation, and each fails differently. An in-house team knows your business but rarely knows the ERP itself. A GCC-based partner brings regional tax and Arabic experience at a higher day rate. An offshore partner costs less but is weaker on Gulf statutory detail.
| Factor | In-house team | Local GCC partner | Offshore partner |
|---|---|---|---|
| Upfront cost | Recruitment, ramp-up, then salary | Highest day rate | Lowest day rate, travel extra |
| Speed to start | Slow: you are recruiting a scarce, certified skill set | Fast, if the bench is free | Fast, slower to learn your business |
| Domain knowledge | Deep on your business, shallow on the product | Strong on regional tax, Arabic, audit | Strong on the product, variable on GCC detail |
| Post-go-live risk | Key-person risk if your expert leaves | Depends on the retainer you negotiate | Time zones and turnover stretch response |
| Best when | Repeat rollouts across entities | Statutory or Arabic complexity dominates | Customisation and integration dominate |
Honestly, the strongest structure I see in the UAE and Saudi Arabia is a hybrid: a regional lead accountable for statutory fit, an offshore build team for configuration and integrations, and one internal product owner with authority to decide without convening a committee. That third role is the one companies skip, and the one that keeps timelines honest. Our ERP implementation service is built around that split.
Regional realities that break a generic ERP plan
Gulf deployments carry requirements that a template project plan ignores. Arabic and English interfaces with right-to-left layout, per-country tax registration and electronic invoicing rules, multi-currency consolidation across entities, Hijri alongside Gregorian dates in HR and contracts, and weekend patterns that differ by market. Each one touches configuration, reporting and testing.
- Bilingual output, not just a bilingual UI. Invoices and statements may need Arabic entity names and correct right-to-left rendering in printed and emailed documents.
- Country-specific tax and e-invoicing. Each authority sets its own rules, so verify tax registration at source with Saudi Arabia's Zakat, Tax and Customs Authority and electronic invoicing with the UAE Ministry of Finance, not from a pitch deck.
- Multi-entity, multi-currency consolidation. Group reporting across Gulf entities shapes your chart of accounts on day one.
- Dual calendars. Leave accrual, contract expiry and government submissions may follow Hijri dates while your ledger runs Gregorian.
- Working weeks. Approval routing, SLA clocks and payroll cut-offs assume a working week, and that differs between your markets.
None of it is hard once someone has done it before. All of it is expensive to discover during testing. For country detail, see our notes on ERP systems in Saudi Arabia and on ERP implementation in Kuwait.
Phasing that survives contact with reality
Sensible ERP phasing puts finance live first, then the operational modules that feed it, then analytics and automation. Big-bang launches across every entity and module in one weekend look decisive in a steering committee and generate the ugliest recoveries. Phase by business capability, not by software module list, and give each phase its own acceptance criteria.
Discovery and design
Walkthroughs with the people who do the work, a documented chart of accounts, and a gap list with a decision on each: configure, customise or change how you work.
Build and migrate
Configuration in a controlled environment, integrations to banking and e-invoicing, and migration dry runs that reconcile to the legacy trial balance.
User acceptance testing
Business users run scripted scenarios end to end, defects are severity-rated, and a named person decides whether the phase passes.
Go-live and hypercare
Cutover in a defined window, daily triage while the first close runs, and a written exit into normal support.
A statement of work worth signing lists deliverables with acceptance criteria, named roles, migration dry runs, environments provided, change control with rates, the assumptions that would move the price, and remedies if either party is late. If a firm cannot draft that in a week, it will not draft one later.
When I would tell you not to hire a partner
If you run one legal entity, no inventory, simple invoicing and a handful of finance users, a partner is overkill. Take the vendor's guided onboarding, pay a consultant for two days of chart-of-accounts review, and spend the rest on training. Partners earn their fee on complexity, so do not manufacture any.
Pay against milestones, not against licences
Payment terms are the cheapest control you have. Tie fees to accepted deliverables: design sign-off, a successful migration dry run, UAT acceptance, go-live, and exit from hypercare. Hold a meaningful final tranche until the first month-end closes cleanly in the new system. Licences are a separate line, paid on their own schedule.
Resist any structure that invoices most of the value at kick-off. It hands over your leverage before the work is proven. A partner confident in delivery accepts milestone billing, and the conversation itself is a test.
Fixed price, time and materials, or capped time and materials all work. What does not work is unpriced scope on an open hourly rate. To sanity-check costs first, our transparent package pricing gives you a reference point.
So here is the decision to make this week, before another demo lands in the calendar: write down the three vetting questions, email them to every shortlisted firm, and require written answers. The replies will sort your list faster than any scoring matrix, because thin benches cannot fake specificity in writing.
Then pick the firm whose contract you would be comfortable enforcing. Sign that one.