ERP Go-Live for a UAE Manufacturer — Delivered on Date After Two Failed Attempts

The first two attempts failed at go-live. The third succeeded. The primary structural difference was a PM whose accountability sat with the client, not the vendor.

The Outcome First

A mid-size UAE manufacturer — approximately 280 staff, three production facilities across RAK and Sharjah — had attempted two ERP go-lives in three years. The first, with a tier-two vendor, collapsed at go-live when data migration failures made inventory records unreadable. The business reverted to its legacy system within 72 hours. The second attempt, with the same vendor under a remediation contract, reached go-live date and was then deferred for six weeks when user acceptance testing failures surfaced issues that should have been caught two months earlier. The board had budgeted for a third attempt, with a new vendor, and required independent PM as a condition of proceeding.

TrustForce was appointed before the new vendor was selected. The third go-live was delivered on the committed date. Data migration was completed with zero reconciliation failures across inventory, accounts payable, and fixed assets. The post-go-live stabilisation period ran for four weeks — two weeks less than the vendor's own estimate — before the client's internal team took full operational ownership.

Why the First Two Attempts Failed

Neither failure was primarily a technology problem. The first go-live collapse was the result of a data migration approach that had been signed off by the vendor's project manager and the client's IT lead jointly — with no independent review. The vendor had a commercial interest in reaching go-live on schedule; the client's IT lead did not have the authority to push back on a vendor sign-off without executive support. The reconciliation failures that caused the reversion were visible in the migration testing outputs three weeks before go-live. No one with the authority and the independence to act on them did.

The second attempt failed for a related reason. User acceptance testing was managed by the vendor's implementation team, who designed the test scripts. The scripts covered the system's standard functionality well. They did not cover the client's non-standard production scheduling process — a legacy workflow that three of the five production supervisors relied on daily — because the vendor's team had not been briefed on it and the client assumed it was in scope. The six-week deferral was the result of discovering, at go-live, that a core operational workflow had not been configured.

The TrustForce view — what vendor-managed PM cannot resolve

Both failures share a structure: the party responsible for programme governance had a commercial interest in the outcome. A vendor PM who reports go-live readiness to their own delivery director, under a contract that ties payment milestones to go-live date, is not in a position to recommend deferral when readiness is marginal. That is not a competence problem. It is a conflict of interest built into the engagement model.

Independent PM separates the readiness assessment from the vendor relationship. On the third attempt, TrustForce held sign-off authority on four programme gates — data migration readiness, UAT completion, cutover plan approval, and go-live authorisation. The vendor could not advance past any gate without TrustForce sign-off. At the data migration gate, TrustForce required two additional reconciliation cycles that the vendor's programme did not include. Those cycles added nine days to the pre-go-live schedule. They also meant that the go-live itself ran without a single inventory discrepancy.

How the Programme Was Structured

The third attempt began with a process audit before the vendor's implementation team was onboarded. TrustForce spent three weeks with the client's operational leads — production, finance, procurement, and warehouse — mapping every workflow that the new system would need to support, including the non-standard ones. That map became the UAT script foundation. The vendor received it as a briefing document on day one of implementation.

Four workstreams ran in parallel: system configuration, data migration, integration testing with the client's existing MES platform, and end-user training. Each had a named owner on both the client side and the vendor side, and each fed into a weekly programme board chaired by TrustForce. Escalation from workstream level to programme board was defined: any item that could not be resolved within five working days at workstream level came to the board. Eleven items escalated over the course of the programme. Nine were resolved at board level within two sessions. Two required vendor contract variations — both were documented, priced, and agreed before the work was done.

Practical Takeaway — Five Structural Controls for an ERP Go-Live

These are the controls TrustForce applies on every ERP implementation engagement. They are not vendor-specific and do not depend on the size of the programme:

Independent gate sign-off: data migration readiness, UAT completion, cutover plan, and go-live authorisation must each be held by a party without a commercial interest in the go-live date
Process audit before vendor onboarding: every workflow the system must support — including non-standard and legacy processes — documented before configuration begins, not discovered during UAT
UAT scripts owned by the client: test scripts written against the client's actual operational workflows, not the vendor's standard functionality checklist
Named escalation path with defined timers: any unresolved issue older than five working days escalates automatically — not at the discretion of the workstream lead
Stabilisation period with a defined handover gate: post-go-live support from the vendor is structured around a confirmed handover date, not an open-ended stabilisation arrangement that shifts cost and timeline risk back to the client

What to Do Next

If you are planning an ERP implementation in the UAE — or reviewing the lessons of a previous attempt that did not reach stable operation — the structural question is whether your current programme governance separates readiness assessment from vendor interest. TrustForce provides independent PM for ERP and technology deployments across the UAE, with engagement models that begin at vendor selection and run through to confirmed operational handover. If you are currently in the vendor selection phase, that is the right time to structure the governance before any contract is signed.

FAQ

Should an independent PM be appointed before or after the ERP vendor is selected?

Before, if the budget allows. Vendor selection is itself a governed process — scope definition, RFP design, evaluation criteria, and contract negotiation all benefit from an independent PM who is not commercially aligned with any vendor on the shortlist. On the programme described here, TrustForce's pre-selection involvement meant the implementation contract included the four gate sign-off clauses as standard — not as a post-award negotiation. Retrofitting governance controls into an existing vendor contract is possible but harder, and vendors have less incentive to accept constraints they were not expecting.

What happens if the independent PM recommends deferring a go-live the business is committed to?

The PM's role is to provide the board with an accurate readiness assessment and a clear statement of the risk if go-live proceeds on the current date. The decision to proceed or defer remains with the client. On this programme, TrustForce's recommendation at the data migration gate was to add nine days. The client accepted it. Had they not, TrustForce would have documented the decision, the risks accepted, and the contingency plan required — and continued managing the programme. An independent PM who overstates readiness to avoid an uncomfortable conversation provides no value. One who presents the assessment clearly and lets the client decide does.

How does independent PM work alongside a vendor's own project manager?

The two roles are complementary, not competing. The vendor PM manages the vendor's delivery team, tracks the vendor's internal workstream progress, and is accountable to the vendor's delivery director. The independent PM manages the overall programme, holds gate sign-off authority, chairs the programme board, and is accountable to the client. Where they interact — at programme board, at gate reviews, and at escalation — the independent PM's authority over gate progression is defined in the contract. There is no ambiguity about who has the final sign-off on readiness.