Migrating from Legacy ERP to SaaS in MENA: What Actually Goes Wrong

Lebanese and Gulf companies that spent a decade building processes around an on-premise ERP system face a specific pressure in 2026: the system is not breaking, but the cost of keeping it alive is rising while the gap between what it can do and what the business needs keeps widening. The decision to migrate is often straightforward. The execution consistently is not.

Why on-premise ERP in Lebanon and the Gulf is expensive to maintain

The direct costs are visible: server hardware, Windows Server licenses, an IT contractor who knows the system, and the internal developer who wrote the custom reports no one else understands. The hidden costs are larger: decisions that cannot be made because the data is stuck in a reporting format from 2016, integrations that broke when a third-party API changed and no one fixed them, and the operational workarounds the accounting team invented to paper over the system's limitations.

Companies across Lebanon, Kuwait, and the UAE that migrated successfully in the last three years share one pattern: the decision to migrate came from the operations side, not the IT side. When the COO decides the system is too slow to support the business, the migration happens. When IT leads it as a technology project, it stalls.

What actually goes wrong during ERP to SaaS migrations

Three failure modes repeat across almost every migration project:

Underestimating data quality. A company that has run an ERP for 10 years has data problems that no one counted. Duplicate vendor records. Customer entries with inconsistent address formats. Products with overlapping SKUs because an import script ran twice in 2019. Journal entries that do not balance because someone corrected a mistake manually in the database. Cleaning this data before migration adds months. Discovering it after migration adds a crisis.

Migrating every record. The right approach is to migrate active, relevant data and archive historical records separately. Invoices from 2015 do not need to live in the new SaaS system. They need to be accessible if auditors ask. An archive with a simple query interface serves this need without polluting the new system with stale data that produces misleading reports.

Skipping parallel operation. Running both systems simultaneously for 60 to 90 days is expensive and operationally inconvenient. It is also the only thing that catches edge cases: the quarterly VAT report that only runs twice a year, the multi-currency transaction process that only the CFO uses, the order type that occurs only when a specific supplier delivers directly. Teams that skip this step to save costs discover these exceptions in production, during an audit, or at month-end close.

SaaS versus custom build for MENA operations

Packaged SaaS ERP (Odoo, Zoho Books, SAP Business One, QuickBooks Online) fits companies where the business can adapt to standardized workflows. This is more common than most companies admit. The custom workflows they believe make them unique often turn out to be workarounds for limitations of the old ERP, not genuine operational requirements.

Custom-built systems make sense when the business has genuinely differentiated operational processes that packaged software cannot accommodate. Complex multi-tier distributor pricing structures common in Lebanese FMCG companies, split billing arrangements for Gulf healthcare providers, or the specific inventory reservation logic used by regional 3PLs. Building for these cases in Go with a clean PostgreSQL schema costs more upfront but avoids the ceiling that packaged SaaS eventually hits.

The decision framework: if you are spending more than 30% of the ERP implementation budget on customizations, you should be evaluating a custom build instead.

The realistic timeline

The timeline that fits most Lebanese and Gulf companies migrating from legacy ERP to a cloud system:

Weeks 1 to 4: audit the current system, document all processes including the informal manual workarounds, identify data quality issues, and define what needs to be migrated versus archived.

Weeks 5 to 12: data cleaning and transformation. Extract the data, run it through validation scripts, fix the quality issues, build the import pipeline.

Weeks 13 to 20: parallel operation. Run both systems. The team uses the new system for new transactions and verifies that outputs match.

Week 20 onward: cutover. The old system goes read-only. The new system is the operational source of truth.

The timeline extends when data quality is worse than expected (almost always), when the team has insufficient capacity to run two systems in parallel, or when the scope grows during the process because previously undocumented functionality surfaces.

Data migration that does not break reporting

The most common technical failure in data migration is moving records that were calculated correctly by the old system's business logic but produce wrong results in the new system because the logic is different. A sales report that was correct under the old ERP becomes wrong in the new system because the discount calculation logic differs.

The approach that prevents this: run identical report queries against both systems during parallel operation and compare outputs. Any discrepancy is either a migration bug or a business logic difference that needs an explicit decision. Build these comparison scripts as part of the parallel operation phase, not as an afterthought.

What Lebanese companies specifically face

Lebanon's tax and compliance environment adds complexity. VAT at 11% applies across most transactions, but the application to specific categories differs. Multi-currency operations are common: USD pricing with LBP equivalents, sometimes at the official rate and sometimes at the market rate. The ERP needs to handle these correctly, and migration validation must verify that historical multi-currency records translated properly.

Power and connectivity constraints in Lebanon also affect system design. A cloud-based SaaS that requires continuous internet connectivity for operations is a risk in a market where scheduled power cuts and internet instability are operational realities. The migration plan should evaluate whether the target system has offline or low-connectivity modes.

Key lessons from production

The migration succeeds when the operations team owns it, the data is cleaned before migration not after, parallel operation is treated as non-negotiable, and historical records are archived rather than migrated. The technical platform matters less than the process discipline around these four points.

Companies that treat the migration as a technology project rather than an operational transformation consistently underestimate the timeline, the data quality work, and the change management required to get the team using the new system effectively.

Ready to plan your migration?

Voxire engineers cloud infrastructure and builds custom operational systems for companies in Lebanon and the MENA region. If your ERP is holding the business back, we can assess what it would take to move.

https://voxire.com/get-a-quote/