ERP Migration: When Cloud — and When to Stay On-Prem

  • QData

TL;DR

  • ERP moves fail on integration and downtime, not on VM sizing — map every interface before choosing cloud or on-prem.
  • Stay on-prem when latency, OT coupling, or licensing forbids lift-and-shift; move when elasticity, DR, or SaaS replacement path is clear.
  • Hybrid often means ERP core on-prem + analytics or portal in cloud — not two half-finished migrations.
  • Require a named rollback owner and tested restore before any production cutover window.

The operations director’s ERP was fifteen years old, heavily customised, and still profitable. A systems integrator proposed “cloud-first ERP modernisation” in eighteen months. A hoster proposed lifting the existing VM into managed cloud in six weeks. Both slides showed upward arrows. Neither explained what happens to the barcode scanners on the shop floor when the warehouse module moves, or who rolls back if month-end close fails on a Sunday night.

ERP decisions for companies with fifty to two hundred employees are rarely pure cloud or pure on-prem. They are risk decisions about downtime, integrations, and who owns the truth when something breaks. This guide offers a four-axis scorecard — not a vendor roadmap — to use before the board approves budget.

Four axes that matter more than “cloud yes/no”

Score each axis from 1 (keep on-prem) to 5 (cloud-friendly):

  1. Downtime tolerance — Can you survive a weekend cutover? Do you need near-zero downtime with active/active?
  2. Integration coupling — PLCs, label printers, WMS, EDI, custom DLLs, flat L2 networks?
  3. Licensing and compliance — Per-core cloud rules, data residency, sector regulator (finance, health)?
  4. Operational maturity — Do you have owners for ERP, DB, and network — or one generalist?

Low scores on integration and downtime push toward staged hybrid or on-prem refresh. High scores on maturity and compliance clarity favour managed cloud or SaaS replacement — if a real SaaS product exists for your processes.

When staying on-prem is rational

Manufacturing and logistics often keep ERP and historians close to the line. Medical or regulated workloads may require on-prem or sovereign cloud with explicit data flow documentation. Legacy ERP with decades of custom code may cost more to refactor than to stabilise on modern hardware with good backup and monitoring.

On-prem is not “no cloud”. It means fixing AD, MFA, patch cadence, offline backup, and monitoring first — then connecting cloud portals or analytics with documented interfaces.

When cloud or managed hosting wins

Elastic test environments for upgrades without buying hardware every year. Disaster recovery when your current server room has no generator and no tested off-site copy. Replacing end-of-life hardware while the vendor still supports the ERP version in a managed VM. Moving adjacent workloads (reporting DB, customer portal, file shares) while ERP stays temporarily on-prem — a pattern we see succeed more often than big-bang ERP lift.

Hybrid done right vs “two problems”

Good hybrid: ERP on-prem, nightly anonymised extracts to cloud for BI, SSO from Entra ID, one incident runbook per tier. Bad hybrid: production ERP in cloud, “temporary” PostgreSQL on a NAS, VPN hairpins for every batch job, two teams blaming each other at month-end.

If you choose hybrid, document data flow direction, encryption, and which team owns incidents that cross the boundary — the same discipline as in our BaseCloud hybrid article, applied specifically to ERP.

Rollback and month-end — non-negotiable

Before any cutover:

  • Named rollback decision-maker (not “the committee”).
  • Restore test of ERP DB within the last 30 days with timing note.
  • Month-end or peak-season blackout window agreed with finance.
  • Integration partners on standby with escalation numbers — not only email.

If the integrator cannot describe rollback in one page, postpone the migration date — not the testing.

Interface inventory: ninety minutes that save a quarter

Before anyone sizes a VM, lock a room with operations, finance and the person who actually posts invoices. Write every system that reads or writes ERP data — official APIs last, unofficial first. In Polish and German mid-market we keep finding the same ghosts: a CSV drop to a freight forwarder that runs from a scheduled task on a warehouse PC; a barcode printer mapped as LPT1 through a terminal server; an Excel “integration” that a controller built in 2017 and still emails to the bank; a shop-floor terminal that talks raw SQL to the ERP because the vendor licence for the proper connector expired.

Each interface gets four fields: direction, owner, what breaks if it is late by four hours, and whether it survives a hostname or IP change. If you cannot fill the last field, you do not have a migration plan — you have a cutover prayer. We have postponed more ERP cloud moves for missing printer and EDI paths than for insufficient vCPU.

Stacks we actually meet (and what they imply)

  • Comarch Optima / XL — often on a single SQL Server, heavy custom printouts, e-commerce and WMS add-ons. Cloud-friendly if you treat SQL + application + print spooler as one unit. Hostile if someone proposes “just the database in Azure” and leaves terminals on-prem with a chatty VPN.
  • Enova365 — more service-oriented, still dies on print and fiscal device assumptions. Ask who owns the local fiscal printer path before you celebrate SaaS.
  • SAP Business One — licensing and partner politics matter as much as latency. A lift of the VM can be rational; a rewrite “while we are at it” is a second project hiding in the first.
  • Custom / Fox / Access leftovers — if month-end still depends on a desktop MDB, fix that on-prem or accept that cloud will wait. Pretending otherwise is how cutovers slip to Sunday 23:00 with finance on the phone.

SaaS ERP is a good answer when your processes fit the product. It is a trap when the integrator sells “configuration” that is really a rewrite of your warehouse logic with no rollback to the old vendor.

Cutover weekend: an honest timeline

A typical 80–150 person firm with one warehouse and one accounting entity, if interfaces are mapped and restore was tested in the last 30 days:

  1. Thursday 16:00 — freeze non-critical writes; last backup; confirm restore target is empty and reachable.
  2. Friday 18:00 — final users off; final backup; start cutover; integration partners on a conference number, not email.
  3. Saturday morning — smoke: post a test invoice, print a label, send a dummy EDI, open a known sales order. Finance signs “we can close if we stay” or “rollback”.
  4. Sunday 12:00 latest — go / no-go. If no-go, rollback owner (one name) executes the restore runbook. Not a committee.
  5. Monday 07:00 — hypercare list: printers, EDI, bank files, the three reports the board actually opens.

If the integrator cannot put this on one page with names and phone numbers, move the date — not the testing. Related: restore proof before any production window; hybrid when the line must stay local.

What to do next

List every system that reads or writes ERP data — not only official interfaces. Score the four axes in a room with finance, operations, and IT. Pick one adjacent workload to cloud first (reporting, portal, files) before moving ERP core. For architecture review, landing zone design, or managed hosting around an on-prem ERP, start with our Cloud Services practice; for shop integrations and e-commerce connectors, see App/Ecommerce.

Want to discuss a project?

Contact us

More from this topic

Cloud RFP: How to Compare Three Vendors Without the Deck

Newsletter abonnieren

Erhalten Sie Neuigkeiten, Updates und Sonderangebote direkt per E-Mail.
Nein, danke