3 Dubai ERP Projects Stalled on the Same Hire — the 7 Steps I Use Now to Hire an SAP Developer

Enterprise systems hiring in Dubai fails differently from the rest of engineering recruitment. A bad React hire is visible in three weeks. A bad ERP hire is visible in seven months, usually at the point where a finance close does not reconcile and the only person who understands the custom object that caused it has rolled off to another client. Below is the method we now run, step by step, and the reasoning behind each step, because the reasoning is the part that transfers to your situation.

Why the Job Description Is Almost Always the Problem

When a Dubai company tells me an ERP hire did not work out, I ask to see the job description before I ask anything about the candidate. In the large majority of cases the answer is in the document. The role asked for someone who could configure the finance module, write ABAP extensions, manage the system landscape and build integrations to three external systems. Those are four separate professions. A person who genuinely does all four exists, costs roughly what three people cost, and is not applying to your advert.

What actually happens is that you hire someone strong in one of the four who is willing to attempt the others. They perform well in their own discipline and slowly, invisibly, accumulate a backlog in the other three. By the time this is visible the project is behind and the natural conclusion is that the hire was weak. The hire was not weak. The job was incoherent.

Step 1 — Decide Which of the Four Roles You Are Actually Hiring

Take the diagram above and pick one. If you genuinely need two, open two roles or accept explicitly that you are hiring a strong person in one discipline who will be adequate in the second — and write the job description to say so, because the honest version attracts better candidates than the fantasy version.

A quick diagnostic that works: describe the problem that made you decide to hire, in one sentence, without using a product name. “Our month-end close takes eleven days” points to functional. “We have four hundred custom objects and nobody knows which are still used” points to technical. “Our test system has not matched production since March” points to basis. “The warehouse and the ledger disagree every Tuesday” points to integration.

Step 2 — Write the Scope, Not the Technology List

A job description consisting of acronyms tells a candidate nothing they can price themselves against. Replace it with four concrete facts: which modules are in play, which version you are on, what state your migration is in, and roughly how many custom objects exist. Add your industry and your entity structure.

This feels like exposing weakness. It is actually the strongest filter available to you. Experienced ERP people read a precise scope and immediately know whether they can help; they read a vague one and assume, usually correctly, that the project has no clear owner. The best candidates in this market are the most aggressive self-selectors, which means a vague advert filters out your best applicants rather than your worst ones.

Step 3 — Filter on Migration State, Not Years of Experience

This is the step that changes shortlists most. Twelve years of ERP experience tells you very little on its own. What matters is whether those years were spent on greenfield implementations — building on a clean system, where the constraint is knowing the product well — or on brownfield conversions, where the constraint is archaeology: reading twenty years of undocumented custom code written by people who left, and working out what is load-bearing.

Those skills barely overlap. A brilliant greenfield consultant dropped into a brownfield conversion is slow and frustrated, because the job is not the job they are good at. The reverse is also true: a conversion specialist on a clean build will over-engineer for problems you do not have.

The screening question I use: “Tell me about a piece of custom code you decided to delete. How did you establish it was safe?” Greenfield people describe a process. Conversion people describe a specific, slightly traumatic story. You want the answer that matches your situation.

Step 4 — Run a Configuration and Debugging Exercise, Not a Quiz

ERP competence is diagnostic. The daily work is narrowing down why a document did not post, why a price was calculated differently from expectation, why a batch job ran for six hours. Multiple-choice knowledge tests measure none of this and reliably favour candidates who have recently revised for a certification over candidates who have recently fixed a production problem.

Give a sandbox with a realistic, broken scenario. Ninety minutes, screen shared, thinking aloud. You are watching for the order of operations: do they check configuration before assuming a code defect, do they look at the change log, do they form a hypothesis and test it or do they change three things at once. Whether they solve it is secondary to how they narrow it. We apply the same principle to every technical assessment we design; the general version is in our technical interview scorecard guide.

Step 5 — Verify the UAE Localisation Experience That Actually Matters

“Regional experience” on a CV is close to meaningless. Test for the four specifics that generate real work in the UAE:

• VAT treatment and reporting. Not whether they know VAT exists, but whether they have configured it, including the cases that are genuinely awkward: partial exemption, reverse charge, intra-group transactions.
• E-invoicing readiness. Whether they have worked on structured invoice output and the validation and archiving obligations that accompany it, rather than simply printing a PDF.
• WPS-compatible payroll output. If payroll is in scope at all, this is non-negotiable and is a frequent source of late-stage surprises.
• Multi-entity and free-zone structures. Companies operating both mainland and free-zone entities have consolidation and intercompany requirements that a single-entity background does not prepare anyone for.

One caution in the other direction: if the role has no finance or payroll surface — a warehouse extension, a reporting layer, an integration to a logistics provider — then insisting on UAE-specific experience shrinks your shortlist for no benefit. Apply this filter where it earns its cost and drop it where it does not. The surrounding employment paperwork is a separate matter, covered in our employer-of-record and WPS payroll guide.

Step 6 — Test the Handover Behaviour Before You Hire

Knowledge concentration is the defining long-term risk of ERP staffing, and it is almost never assessed during hiring. The failure mode is specific: one capable person accumulates exclusive understanding of why the system behaves as it does, and the organisation becomes unable to change anything without them. In Dubai this risk is amplified because a meaningful share of ERP work is done by consultants who roll off, and because relocation rates are high.

So test for it. After the step four exercise, ask the candidate to spend twenty minutes writing up what they found for a successor who has never seen the system. You will see the difference immediately. Some people produce something a colleague could act on. Others produce notes that are only legible to themselves — and that second group, however technically strong, will concentrate knowledge by default rather than by intent.

Step 7 — Structure the Engagement So the Knowledge Stays

Put the obligations in the contract. Not as culture, not as an expectation mentioned at onboarding, but as deliverables: a documented decision log for every custom object created or modified, a named internal counterpart who pairs on a defined share of the work, and a handover artefact due at fixed milestones rather than at the end.

Then choose the engagement model against the shape of the work rather than the convenience of the budget line. An implementation or migration is a burst followed by a long tail. The pattern that works is a dedicated team through the burst and one permanent engineer who holds the knowledge afterwards. The pattern that fails — contractors for the burst and nobody permanent — is the one that produces a system nobody in the building can explain a year later. If you are weighing the models, our comparison of fixed-price versus time-and-materials contracts applies directly, and teams running the same decision under Singapore employment rules have documented their version in hiring a developer as an independent contractor in Singapore.

Three Mistakes That Cost the Most

Hiring the certification instead of the practitioner. Certifications demonstrate exposure to a curriculum. They are weak evidence of diagnostic ability and, in this market, are disproportionately held by people whose recent experience is training rather than delivery. Use them as a tiebreaker, never as a filter.

Treating the integration work as an afterthought. In nearly every UAE ERP project we have staffed, the interfaces to banks, logistics providers and customer portals consumed more engineering time than the ERP configuration itself — and were scoped last. If you have more than two external systems, the integration engineer is not optional and should not be the final role you open.

Letting the go-live date set the hiring bar. Under deadline pressure the bar falls exactly when it should not, because an ERP mis-hire is discovered late and is expensive to unwind. If you are behind, the correct move is a contractor to hold the line and a proper search in parallel, not a permanent hire made quickly.

FAQ — Hiring SAP and ERP Developers in Dubai