A phased modernization roadmap for EU mid-market companies replacing legacy ERP workflows without disrupting core finance and operations.
Most mid-market EU enterprises we meet have been running the same ERP — usually Microsoft Dynamics NAV/AX, SAP Business One, or a country-specific package like SAGE — for 12 to 18 years. The system works, finance trusts it, and replacing it wholesale is politically and operationally suicidal. Yet month-end is taking nine days, approvals route through three inboxes, and the warehouse uses an Excel sheet because the receiving screen has 47 fields.
This post lays out the phased roadmap we used for Bau Nord GmbH, a 180-person construction firm in Hamburg, where DATEV integration and German tax compliance ruled out a clean rebuild. Approval time went from 5.2 days to 1.4 days, cost overruns dropped from 6–9% to 2–4%, and controller overtime was eliminated — all without replacing the system of record on day one.
The strategic constraint
For EU mid-market, the ERP is rarely the bottleneck. The bottleneck is the *process layer* glued on top: paper approvals, email threads, spreadsheet reconciliations, and the one person who knows how to close GR/IR. A roadmap that starts with "migrate to S/4HANA" misses where the real value sits — in the workflows around the ERP, not inside it.
Our objective is to improve process reliability and reporting velocity while keeping finance, procurement, and compliance-critical workflows untouched until the surrounding process layer is proven.
The transformation map
Each arrow is a 6–10 week gate, not a year. The roadmap is designed so that if a phase is cancelled, the previous phase still delivers value — no "big bang" that requires the entire program to succeed before any user benefits.
Phase 0 — Baseline (weeks 1–6)
Before redesigning anything, we inventory:
- Every integration in/out of the ERP (we typically find 30–60% more than IT thought existed, mostly Excel exports and Power Automate flows).
- Every report consumed by management, with frequency and owner.
- Every approval chain, with median and 90th-percentile cycle time measured from real data (not surveyed).
- Every customization in the ERP itself, with the original business reason if we can find it.
This phase produces one artifact: a process risk heatmap that ranks workflows by business impact and replacement effort. The heatmap is what the steering committee uses to choose what gets modernized first.
Phase 1 — Process redesign (weeks 7–14)
We redesign the top three high-friction workflows from the heatmap. For Bau Nord, those were: site material requisition → procurement → DATEV; subcontractor invoice approval; and weekly cost controlling rollup.
Redesign happens *outside* the ERP. We build a modular .NET 8 service that owns the workflow, calls the ERP via its existing API for master data and posting, and presents a focused UI to the user. The ERP stays the system of record. This is the most important architectural decision in the whole roadmap.
Phase 2 — Dual-run and reconciliation (weeks 15–22)
For each redesigned workflow, the old and new paths run in parallel. The new path writes to the ERP; the old path is observed but its outputs are reconciled against the new path nightly. Discrepancies above a tolerance threshold (typically €50 per posting) generate an alert that a controller resolves the next morning.
The dual-run window is non-negotiable. Skipping it always costs more in incident remediation than the eight weeks of operational overhead.
Phase 3 — Cutover with rollback guardrails (weeks 23–32)
Once reconciliation has been clean for three consecutive weeks, we cut over by workflow, not by big bang. Each cutover has:
- A documented rollback decision tree (under 15 minutes to execute).
- A named go/no-go owner from finance and from IT.
- A 48-hour hypercare window with extra controller capacity.
What we don't do
We don't replace the ERP. We don't migrate finance to a new general ledger. We don't change tax calculation logic. Those are 24-month programs, and they should only be undertaken when the process layer is already modern enough that the ERP swap becomes a backend change rather than an operational disruption.
Closing
Mid-market ERP modernization succeeds when you accept that the ERP is the wrong unit of work. Modernize the processes around it first, prove value, and only then consider the system of record itself.
