The ERP Migration Brief

Who this is for. You run a 10-to-500-employee company. Your current ERP — SAP B1, SAP S/4HANA, Microsoft Dynamics 365 Business Central, NetSuite, Sage, Tally, or a homegrown legacy system — has stopped being an asset. Maybe it's licensing pressure. Maybe ZATCA Phase 2 made it obvious. Maybe the team has built a parallel universe of spreadsheets to compensate. Maybe a giga-project supplier conversation forced the question.

This brief gives you what we'd give you in the first call: an honest framework for the migration, a realistic cost and timeline range, the specific risks that derail mid-market migrations, and the criteria for deciding whether to migrate at all.

It is written by the team at Mainline Systems — an EU-incorporated ERP++ systems integrator. The framework reflects what we actually do, not a sales pitch for our services. Where we make a recommendation specific to our approach, we mark it as such.

Executive summary

Most ERP migrations fail because they're managed as IT projects when they're actually operations programmes. Plan for the operations transition, not the software install.

The framework. Six phases — Discovery, Architecture, Build & Configure, Data Migration, UAT & Cut-over, Hypercare. SME (10–30 users) runs 8–14 weeks end-to-end. Mid-market (50–200 users) runs 16–24 weeks. Anything you scope above 24 weeks should be split into v1 + v2 SOWs — single-SOW projects beyond six months fail at materially higher rates.

The cost. SME implementations land USD 21,000–48,000. Mid-market lands USD 67,000–160,000. AMC (annual maintenance) is the long-run line item: USD 800 / 2,130 / 4,800+ per month for Bronze / Silver / Gold tiers. The Year-1 total for a typical mid-market client lands USD 110,000–135,000 across implementation + AMC + minor extensions.

The risk to manage. Data migration takes longer than estimated. Stakeholder availability erodes mid-build. Compliance scope (ZATCA, WPS, GDPR) surfaces obligations no one disclosed up front. Parallel-run validation reveals gaps. We've ranked the top 10 risks below with mitigations.

The decision criteria. Don't migrate if your current system is licensed, supported, and will hold for three years. Do migrate if you're hitting a wall on compliance, scale, multi-entity, or operational visibility. The middle ground — extension over migration — is often the right answer and we describe when it is.

The next step. A paid 3-day Sprint Discovery (USD 1,300) produces a 1-page brief with a go/no-go recommendation on full discovery. Details at the end.

Part 1. Why ERP migrations fail

Industry data is consistent: 50–70% of ERP migrations either fail outright or significantly miss the planned timeline, budget, or scope. That number is high enough that it should be the first slide in every kick-off meeting, not the last lesson in a post-mortem.

Five failure patterns produce most of those outcomes.

Failure 1. Treating it as IT, not operations

What it looks like. A CIO sponsors the project. The implementation team configures modules to mirror "what we did before." End-users get told to attend training in week ten. Go-live is a sprint to install software, not a transition of how the business runs.

Why it happens. ERP looks like software because it is. But the deliverable is an operating model, not a piece of software. Procurement, finance, sales, and operations all behave differently after go-live whether anyone planned for it or not.

How to avoid it. Sponsor the project from the COO or CFO seat, not the CIO seat. The CIO co-leads. Process owners (head of finance, head of supply chain, head of sales ops) are accountable for their function's successful transition — not for the software working.

Failure 2. Trying to replicate the old system

What it looks like. The team scopes the new ERP by listing every report, screen, and workflow from the old system and asking the integrator to "make it look like that." Three months in, scope is 40% larger than estimated, custom-development hours are running 2× quoted, and the new system feels harder to use than the old one.

Why it happens. Legacy ERPs accumulate workarounds. Workarounds become the operating model. Replicating the workaround is replicating the legacy.

How to avoid it. During Discovery, ask of every existing report and workflow: Why does this exist? What decision does it support? Would we build it from scratch today? Half of legacy reports vanish under that questioning. Some need to exist but can be standard-module output, not custom dev. The remainder is the actual customisation list.

Failure 3. Underestimating data migration

What it looks like. The plan says "migrate 24 months of transactional data, 6 weeks." Data extraction reveals 14% of records have missing or invalid foreign keys. Validation finds 3% of historical invoices that never reconciled. The team ends up either spending three extra months cleaning legacy data or accepting partial migration and giving up some historical reporting.

Why it happens. Estimates assume the source data is clean. It almost never is — especially in companies that grew through M&A, or that ran multiple finance systems in parallel, or that had high turnover in the AP/AR teams.

How to avoid it. Run a data quality audit during Discovery, not as the first task of Build. Three days of expert eyes on a representative sample (20% of master records, 12 months of transactions) tells you 80% of what you'll find. Price the migration based on that audit, not on the optimistic case.

Failure 4. No parallel-run validation

What it looks like. Old system is shut down on Friday, new system goes live on Monday. Tuesday morning, finance can't reconcile the prior month. Procurement is keying POs into both systems "to be safe." Six weeks later, no one trusts either system, and morale is gone.

Why it happens. Skipping parallel-run saves three weeks of duplicate-entry pain. It also concentrates all discovery of system errors into go-live week, when the team is least equipped to absorb them.

How to avoid it. Run the new system in parallel with the old for at least one full month-end close. Validate every general-ledger balance, AR ageing, AP ageing, inventory total, payroll register, and tax filing against the old system. Reconcile differences before cut-over, not after.

Failure 5. No senior delivery owner

What it looks like. The integrator's account manager runs status calls. Functional consultants do the configuration. Developers handle custom work. No single person above the consultant level owns the operational outcome. When something goes wrong — and it will — the response is "we'll need to escalate."

Why it happens. Many integrators staff projects from a generalist body-shop pool. Senior delivery talent is expensive and scarce; it's easier (and more profitable, short-term) to use junior consultants with a manager loosely involved.

How to avoid it. Demand a named senior delivery owner contractually committed to your project. Make sure they're at least 50% allocated. If the integrator can't or won't commit a senior owner at that level, choose a different integrator. This is non-negotiable.

Part 2. The migration framework

A proven six-phase structure. Phases overlap — data migration starts during Build, not after — but the discipline of named phases makes commitments and gates explicit.

Phase 1. Discovery (1–2 weeks)

Paid engagement, not free pre-sales. Real scoping requires real work, and free scoping creates wrong incentives (the integrator races to a quote instead of understanding the problem).

Deliverables:

• Current-state process map (the "as-is")
• Data quality audit on representative sample
• Target-state architecture sketch
• Indicative cost range with sensitivity drivers
• Phased implementation roadmap with explicit go/no-go gates

Discovery output is a real artefact you can take to the board. If a Discovery doesn't produce a document a non-technical CFO can read in 20 minutes, the Discovery wasn't done.

Phase 2. Architecture (2–3 weeks)

The technical design. Module selection, integration topology, data model, security model, infrastructure (cloud / hybrid / on-prem), tenancy strategy (multi-entity / multi-currency), and the customisation register.

Architecture sign-off is the gate to Build. Skipping it — "let's just start configuring" — is the most common source of late-stage rework.

Phase 3. Build & Configure (8–14 weeks SME, 12–18 weeks mid-market)

Module configuration against the architecture. Custom development for the items in the customisation register. Initial integrations with adjacent systems (banks, payment gateways, logistics, government portals).

Build runs in parallel sprints across functional areas. Finance, supply chain, sales, HR each have their own sprint cadence and demo their own configurations. The senior delivery owner runs the integration of these streams.

Phase 4. Data migration (4–6 weeks, parallel to Build)

Extract, transform, validate, load. Master data (customers, suppliers, items, employees) first. Transactional history second. Open balances and in-flight transactions last (cut-over week).

The validation cycle matters more than the load cycle. Every loaded batch reconciles to a known total in the source system. Discrepancies are logged, root-caused, and either resolved or formally accepted before sign-off.

Phase 5. UAT and cut-over (2–4 weeks)

User Acceptance Testing in the new system, by client teams (not the integrator). Real scenarios — month-end close, payroll run, year-end inventory count — not happy-path demos.

Parallel-run as described above. Defect register. Cut-over runbook signed by both sides. Go-live happens at month-start, not mid-month.

Phase 6. Hypercare and AMC transition (30 days hypercare, then ongoing)

The integrator's senior team stays on-site or on-call for 30 days post-go-live. Defects are resolved at high priority. Workflow refinements happen in real time. Training reinforcement for end users.

At day 30, the engagement transitions to AMC. AMC is a defined contract — not "we'll be around if you need us." If AMC isn't signed before hypercare ends, hypercare doesn't end.

Part 3. Timeline and cost ranges

These ranges reflect 2026 USD pricing for productized fixed-price scopes — not body-shop hourly rates. Body-shop rates appear cheaper per unit and finish 2–3× over budget.

Timeline ranges

Cost ranges (USD)

What drives price within a range

1. Number and complexity of integrations. Each non-standard integration (a bank that needs custom host-to-host, a niche logistics carrier, a legacy government portal) adds 1–4 weeks and $5,000–$20,000.
2. Data migration complexity. Multi-source, multi-format, or poor source-data quality adds 30–80% to migration cost.
3. Custom-development scope. Every custom module is its own mini-project. Five custom modules in a single SOW is reasonable; fifteen is a different programme.
4. Compliance scope. ZATCA Phase 2, GDPR, sector-specific (healthcare, banking, defence) compliance work is real engineering. Plan for 2–6 weeks of explicit compliance work in the implementation.
5. Multi-entity / multi-currency. Each additional legal entity adds 5–15% to implementation cost and explicit AMC uplift.
6. Training scope. Bilingual (Arabic + English) training, recorded sessions, role-based curriculum, and post-go-live reinforcement is its own line item.

The Year-1 Foundation Bundle

Mainline-specific. Most mid-market clients commit to a 12-month Year-1 SOW that combines Discovery + Implementation + AMC at a 10% bundle discount versus buying components separately:

• SME Foundation Bundle: ~USD 46,000 — Discovery + SME Implementation + Bronze AMC (12 months)
• Mid-Market Foundation Bundle: ~USD 126,000 — Discovery + Mid-market Implementation + Silver AMC (12 months)

Part 4. The risk register

Ten risks ranked by frequency × cost-when-it-happens, with primary mitigations.

Part 5. Decision criteria — migrate, modernise, or stay

Not every migration question deserves a migration answer. We refuse Discovery engagements where the right answer is "stay" — we'd rather lose a $5,000 engagement than land you in a $200,000 mistake.

Stay if all of these are true

• Your current ERP is licensed, supported, and the vendor is not signalling end-of-life
• It supports your current operating model adequately (not perfectly — adequately)
• It will hold up against your three-year growth plan without architectural break
• You have no material compliance gap (ZATCA Phase 2, WPS, GDPR, sector-specific)
• Your finance team can close the books, run payroll, and reconcile inventory without parallel spreadsheets

If you check all five, your problem is not your ERP. Spend the migration budget on something else.

Modernise (extension layer) if you check these

• Your current ERP works for accounting and core finance, but reporting / customer experience / mobile / AI are gaps
• Your team has a viable ERP-vendor support contract
• The pain is at the adjacent layer (integrations, custom apps, BI, AI) rather than the ERP core

This is often the right answer. A $40,000 modernisation programme that adds an integrated stack on top of your existing SAP B1 or NetSuite is a fraction of a full migration. The Mainline ERP++ approach was designed for this case.

Migrate if you check these

• Your current ERP cannot support a known compliance requirement (ZATCA Phase 2, WPS) without disproportionate workaround cost
• It cannot scale to your three-year operating model (multi-entity, multi-currency, manufacturing capability gaps)
• Vendor has signalled end-of-life or licensing structure has become untenable
• It is a homegrown legacy system whose original developers have left and whose documentation is incomplete
• M&A or new business line requires a system architecture incompatible with current ERP

If two or more of these are true, migrate. If only one, the answer depends on the timeline of the trigger.

Part 6. The integrated-stack difference

This part is Mainline-specific. It exists because the brief would be incomplete without explaining why we exist.

Pure ERP partners — whether Odoo, SAP, NetSuite, or Dynamics specialists — configure the platform. They are good at that and you should hire one if all you need is the platform.

The reality of mid-market modernisation today is that the platform is one layer of four. The other three — custom applications, AI / automation, integrations — used to be separate vendor relationships. Coordinating them is its own programme management problem.

Mainline's bet is that one team should own all four layers.

• Layer 1: Modern ERP (Odoo preferred, with senior experience across SAP B1, S/4HANA, Dynamics 365 BC, NetSuite for migrations) — the operational backbone
• Layer 2: Custom applications — customer portals, field-ops mobile apps, marketplaces, internal tools that wrap the ERP for actual users
• Layer 3: AI and automation — AI agents embedded in workflows, document intelligence, predictive analytics, approval-workflow co-pilots
• Layer 4: Integrations and data — bank, payment gateway, logistics carrier, government portal, BI dashboards, data pipelines

When one team owns all four, the integrated-stack benefit compounds: the AI agent operates against clean ERP data because the data model was designed for it; the custom field-ops app posts directly to the ERP because the integration architecture was scoped for it; the BI layer consumes from a single source of truth.

We deliver this with productized fixed-price scopes, not time-and-materials body-shop hours. T&M aligns the integrator's incentive with longer engagements, not better outcomes. Fixed-price aligns it with shipping.

Part 7. Where Mainline delivers

Mainline Systems is an EU-incorporated company headquartered in Estonia (Mainline Systems OÜ). We deliver to clients across:

• Europe — EU-incorporated, GDPR-aligned, multi-language, EU-VAT compliant. Spanish, English, and EU-locale operations.
• GCC — UAE, Qatar, Kuwait, Bahrain. Arabic-ready, GCC-localised financial reporting, regional banking and payment integrations.
• Saudi Arabia — Specialised practice for Vision 2030 mid-market. ZATCA Phase 2 e-invoicing, WPS payroll, GOSI integration, Hijri calendar, Arabic-first UX, Saudi data residency on STC Cloud or Mobily Cloud. Saudi clients see local pricing in SAR.
• Global Remote — English contracts, USD pricing, async-first delivery, North American time-zone overlap available.

Senior delivery is the only delivery model. Junior consultants supervised by junior managers is the body-shop pattern. We don't do that.

Part 8. Three ways to engage

If you've read this far, you have a serious migration question. Here are the three ways to get a senior practitioner to look at your specific situation.

1. Sprint Discovery — USD 1,300, 3 days

The lowest-friction entry point. A senior consultant spends three days on your situation: review your current ERP, interview 3–5 key stakeholders, audit a sample of your data, produce a 1-page brief with a go/no-go recommendation on full discovery.

75% of the Sprint Discovery fee credits toward a full Discovery if engaged within 30 days.

2. Full Discovery — USD 4,000 – 9,300, 1–2 weeks

The real scoping engagement. Full current-state mapping, target-state architecture, data quality audit, customisation register, indicative implementation pricing, phased roadmap. The deliverable is the document you take to the board.

3. Direct discovery call — free, 30 minutes

A free 30-minute call with a senior practitioner. Useful for high-level questions: "is this the right time to migrate?", "should we modernise instead?", "is our timeline realistic?". Not a free scoping session — we'll tell you honestly what would and wouldn't be in scope, and recommend the right next step.

About Mainline Systems

Mainline Systems is an EU-incorporated ERP++ systems integrator headquartered in Estonia (Mainline Systems OÜ). We anchor on modern ERP — Odoo preferred, with senior experience across SAP, Microsoft Dynamics, and NetSuite — and extend it with custom applications, AI agents, integrations, BI, and tiered managed services.

We deliver to clients across Europe, the GCC, and globally, with a specialised practice for Saudi Vision 2030 mid-market work. Senior delivery on every engagement. Productized fixed-price scopes. No T&M body-shop hours.

© 2026 Mainline Systems OÜ. The framework, methodology, and risk register are Mainline IP. The content of this brief is licensed for individual use; redistribution requires permission.