ERP Selection: What Mid-Market Manufacturers Get Wrong

A manufacturer in the Gulf runs seventeen spreadsheets alongside its decade-old ERP. The system works — technically. Production orders go in, invoices come out, and the warehouse team has learned to live with a three-day lag between physical stock and system stock. Then the board approves a replacement project, a consultant demos four platforms, and twelve months later the go-live is delayed by eight months and the budget has overrun by 40 percent. The ERP is different. The spreadsheets are still there.

This is not a vendor problem. It is a selection process problem — and it starts well before any demo is scheduled.

Why Legacy ERP Replacements Stall Before Go-Live

The pattern is consistent across mid-market manufacturing. A selection committee forms, a request for proposals goes out, vendors submit responses, demos are scheduled, and a shortlist emerges. The shortlist is almost always built on feature coverage: does the system handle discrete manufacturing? Multi-currency? Landed cost calculations?

Feature coverage is a necessary condition, not a sufficient one. What the RFP process rarely captures is implementation complexity — the number of existing systems the new ERP must connect to, the state of master data, the gap between a vendor's standard implementation and what the business actually needs ^[1]. By the time these gaps become visible, the contract is signed.

The result: stalled go-lives, scope renegotiations, and a new system that requires the same manual workarounds as the old one. The ERP changed. The decision layer did not. If you have seen this in action, the dashboards-report-but-don't-decide problem is the same failure mode in a different part of the stack.

The Three Questions a Shortlist Cannot Answer for You

Before a shortlist can be meaningful, three foundational questions need honest answers. Most selection processes never ask them.

1. Who owns the data, and what happens when you leave?

Data ownership is often buried in vendor contracts. Cloud ERP vendors vary significantly on export formats, data residency options, and what happens to historical records if you terminate the agreement. For manufacturers operating under Gulf regulatory frameworks — where audit trails and localisation requirements carry real legal weight — this is not a theoretical concern. Ask the vendor: in what format can we extract seven years of transactional data, and how long does it take? If the answer is vague, the contract negotiation has more work to do ^[2].

2. What is the real integration surface area?

Count every system the new ERP must connect to: legacy MES, warehouse management, customer portals, banking integrations, HR platforms, WhatsApp-based approval chains (yes, these are real and they are load-bearing in many Gulf operations), and any government reporting portals. ERP integration challenges multiply with every additional touchpoint — data format mismatches, authentication conflicts, real-time versus batch sync decisions, and the question of who maintains each connector when the vendor updates their API ^[3].

In our experience, manufacturers who map this surface area honestly find that their longlist of eight vendors collapses to two or three that have genuinely solved the integrations they need. The rest are promising roadmap items.

3. What is the gap between the demo and the real implementation scope?

Vendor demos show the system at its best: clean data, standard workflows, pre-built connectors. They do not show the configuration hours, the data migration effort, or the customisation work required to match actual business processes. Ask every vendor on your shortlist for a breakdown of their last five implementations: contracted timeline versus actual go-live, standard configuration hours versus customisation hours, and post-go-live support incidents in the first ninety days. A vendor with a strong implementation record will share this. One that deflects is giving you an answer ^[1].

Cloud vs. On-Premise vs. Hybrid: What the Vendor Won't Tell You Upfront

The cloud-versus-on-premise debate is often framed as a cost and flexibility question. It is actually an integration and control question.

A cloud ERP with a clean API layer and thirty legacy connections is operationally harder than an on-premise system with five well-maintained integrations. The hosting model is secondary to the integration model. Here is what vendors typically do not volunteer:

1. API rate limits and change policies. Cloud vendors update their APIs on their own schedules. An integration that works today may break after a platform update, and the maintenance burden falls on you or your implementation partner ^[3].
2. Localisation maturity. Gulf-specific requirements — VAT reporting, Zakat calculations, Arabic language support, and eInvoicing formats mandated by ZATCA and the UAE's FTA — vary significantly in how well they are handled natively versus through third-party modules. Third-party localisation modules add a dependency that is rarely discussed in demos ^[2].
3. Multi-entity complexity. Manufacturers with operations across KSA, UAE, and other Gulf markets often discover that multi-entity consolidation in a cloud ERP requires licences, modules, or configuration that was not in the original quote.
4. Upgrade lock-in. SaaS ERP vendors push updates on their timeline. Customisations that work today may need rework after a major release. On-premise systems give more control but require internal resource to maintain. Hybrid arrangements attempt to split the difference — and often split the accountability too.

For more on how one major public-sector migration handled vendor lock-in risk, what Switzerland's Microsoft exit teaches Gulf ERP buyers is worth reading before your next contract review.

How to Stress-Test an ERP Vendor's Real Implementation Record

Reference checks are standard. Useful reference checks are not. Most vendors offer references from their best-case clients — large, well-resourced implementations with dedicated internal project teams. For mid-market manufacturers, these references are close to useless.

Ask for references that match your profile: similar revenue band, similar manufacturing complexity, similar number of integrations, and similar internal IT resource level. Then ask those references specific questions:

• What was the contracted go-live date versus the actual date?
• How many change orders were raised during implementation, and what drove them?
• What percentage of your processes ran on standard configuration versus custom development?
• What did the first ninety days post-go-live look like operationally?
• If you did this again, what would you do differently in the selection process?

A vendor reference who answers these questions in under ten minutes, without hesitation, has been through enough pain to have useful opinions. One who gives you a rehearsed positive summary is probably not the right reference to rely on ^[1].

For a related view on how implementation lessons rarely surface before you start, see ERP implementation lessons nobody tells you before you begin. And if your shortlist includes SAP, the SAP 2027 deadline analysis is directly relevant to the extend-versus-replace decision.

It is also worth pressure-testing how your chosen system handles AI agents and ERP operations — agentic capabilities are moving fast, and integration surface area decisions made today will determine what is possible in two years.

Tarsyn's View: Start With the Integration Map, Not the Demo

The advice we give clients before any ERP selection engagement is the same: do not book demos until you have a complete integration map and an honest data ownership position.

The integration map does not need to be a formal architecture document. It needs to answer: what systems exist today, which ones are genuinely load-bearing, which are workarounds that will disappear with the new system, and what data flows between them. For a Gulf manufacturer, this map almost always reveals WhatsApp approval chains, manual Excel bridges between systems, and at least one integration that nobody has documented because the person who built it left three years ago ^[3].

Once this map exists, vendor evaluation becomes substantially more tractable. You are not asking "does this system support discrete manufacturing?" — every vendor on your longlist will say yes. You are asking "show me how you have handled a three-way integration between your ERP, a legacy WMS, and a government customs portal in a GCC deployment." That question has a much shorter list of honest answers.

The right starting point is not an RFP. It is a structured pre-selection audit that maps integration complexity, clarifies data ownership terms, and defines the realistic implementation scope before any vendor enters the room. This is exactly what our Audit engagement is designed to do — not to recommend a platform, but to give you the map that makes the RFP honest.

Most clients who go through this process find that their initial longlist of eight to ten vendors reduces to two real candidates. Occasionally it reduces to one. Occasionally the audit reveals that the legacy system, properly integrated and maintained, is good enough for another three years — and that is the honest answer we will give, even if it means no further engagement.

Multiply a flawed selection process by a capable implementation partner and you still get a delayed go-live. The sequence matters: map first, demo second, select third. Everything else is optimising the wrong variable.