The scenario is familiar: a system written years ago, the original developers gone, business logic documented nowhere but the code — and the risk growing every year. We run the replacement as a managed transition: documented assessment, migration concept, controlled parallel run and cut-over. Vendor-neutral, no commission from any vendor. 1,200+ projects since 1992.
First call: your situation, the decision at stake, and a clear next step.
An ERP replacement retires a system your business still depends on — often an individually programmed solution that has grown with the company for fifteen or twenty years. The work is a managed transition: document what the old system does, decide what succeeds it, migrate the data, and run both systems in parallel until the new one has proven itself.
From our experience, the risk is rarely the new software — it is the old one: undocumented business logic, data quality nobody has measured, interfaces nobody dares touch. That is why the replacement starts with a documented assessment, not with a vendor demo. Choosing the successor system itself runs through ERP selection with longlist, shortlist and evaluation matrix. And if your concern is not an ageing system but an implementation already in trouble, that is a different engagement: ERP project rescue.
Would you like an honest read on how much risk your legacy system is carrying?
Meet with us to map the replacement end-to-end →A quick read before you spend a meeting on it. If most of this matches your situation, a replacement is worth scoping — if it doesn't, we will say so.
The undocumented rules reverse-engineered and written down.
The business logic lives only in the code and in a few people’s heads. When they leave, the knowledge leaves — and the system can no longer be safely changed or replaced.
Access to the source code and database schema where available, the reports the business actually uses, and time with the people who still know how the system behaves.
Reverse-engineer the landscape and business rules from several directions at once — schema, code, live reports and structured interviews — and write them down.
A landscape and business-logic document: the undocumented rules, interfaces and dependencies captured in a form the successor project can build on.
It captures the logic that exists only in the code and in people’s heads — so the replacement no longer depends on either.
Every business-critical rule and interface is documented and traceable to its source; no rule remains that only one person can explain.
What the data is worth and how it moves.
Nobody knows what the legacy data is actually worth — how much migrates cleanly, how much needs work, and how much should never be carried over.
Read access to the production tables, the retention rules that apply, and the list of processes the data has to support after cut-over.
Profile the real tables, classify records as migrate, clean or archive, and design a staged migration with test loads and reconciliation counts.
A data-quality report and migration concept, measured on real tables, with the migration path and reconciliation approach set out.
It names what migrates, what gets cleaned and what gets archived — before anyone signs an implementation contract.
Data quality is measured on real tables, not assumed; every table has a documented migrate, clean or archive decision.
Standard ERP, re-platform or stay — board-ready.
The board has to decide whether to replace, re-platform or keep the system — but without criteria the choice comes down to instinct or vendor pressure.
The landscape and data findings from the assessment, the cost trajectory of the current system, and the business's functional priorities.
Weigh knowledge risk, functional fit and cost against defined criteria, and lay out the successor options with their consequences.
A board-ready successor decision path: standard ERP, re-platform or stay — with the system choice handed into ERP Selection.
It ends in a decision the board can defend; the system choice hands off to ERP Selection, not to a vendor shortlist.
The recommendation is traceable to explicit criteria the board can defend; the decision is made against evidence, not instinct.
How the switch happens — with rollback criteria agreed in writing.
The switch to the new system is where replacements fail — and rollback rules improvised during the cut-over weekend are no protection.
The migration concept, the business cycles the successor must prove itself against, and agreement on who signs off go / no-go.
Plan the parallel run and cut-over: which cycles must pass, how long the systems run side by side, and the exit and rollback criteria — fixed in writing.
A cut-over and parallel-run plan with exit and rollback criteria agreed in writing before go-live.
The criteria for turning back are fixed in writing before go-live — not negotiated during the cut-over weekend.
Exit and rollback criteria are agreed in writing before go-live; the successor is proven against complete business cycles, including a full month-end close.
What must stay readable for the auditors (GoBD), what gets switched off.
After go-live the old system lingers — expensive to keep, risky to switch off, and bound by retention rules nobody has mapped.
The statutory retention periods that apply, the tax-relevant data in the legacy system, and sign-off on the read access auditors require.
Define what stays readable, in what form and for how long, and set a switch-off date with the retention and read-access obligations met.
A decommissioning and retention concept: what stays readable for the auditors (GoBD), what gets switched off, and when.
It covers the years after the project: retention periods, read access for auditors, and a switch-off date that actually arrives.
Tax-relevant data stays readable and machine-evaluable for the statutory retention periods (GoBD); every legacy component has a defined switch-off date.
Assess, decide, migrate, cut over — the legacy system stays productive until the successor has proven itself. Each stage produces a document the next one depends on, so the decision is traceable at every point.
The assessment treats the legacy system as a source to be read, not a box to be swapped. We combine what can still be read from the database and the code with what only experienced users know.
The assessment feeds a structured decision: how much knowledge risk the company is carrying, how far daily work has outgrown the system, and what keeping it alive really costs.
Migration is rehearsed, not attempted. Staged test loads move the data into the successor system, reconciliation counts prove that what left the old system arrived intact.
Both systems run side by side until the successor has proven itself against complete business cycles — with exit criteria agreed in writing before the parallel run begins.
The scope of a replacement is set by complexity, not a fixed duration — the number of processes, data objects, interfaces, the level of documentation and how much sits only with key people. Priority goes to the rules, data and interfaces whose loss would directly hit production, billing, compliance or customer service.
Effort and time depend on the number of processes, data objects, interfaces, level of documentation and availability of the people who know the system.
Priority is given to rules, data and interfaces whose loss directly jeopardises production, billing, compliance or customer service.
The inventory may show that modernisation or continued operation is more economical than a complete replacement.
An honest inventory can show that modernising or keeping the current system is more economical than a full replacement. If that is the finding, we say so — even when it means the mandate ends before any software is bought. Either way, you decide from documented facts, not a vendor demo.
The 12 critical points when replacing a custom-built ERP.
Furniture manufacturer
ProblemA custom system grown over years carried the entire order flow of variant manufacturing — the rules lived in the code, nothing was written down. Without that basis, neither a replacement nor a sound investment decision was possible.
EngagementAssessment and evaluation of more than 200 processes across the plant network, distilled into a board-ready basis: what can be standardised, what stays distinctive, and which successor path holds.
200+
processes documented, previously none · calculated in the concept
>20%
cost reduction · calculated in the concept
~25%
effort optimisation · calculated in the concept
The concept was developed jointly with the company — implementation was handled in-house. No implementation mandate, no software commission.
Honest answers about parallel operation, undocumented systems and what happens to the old data — the questions that come up in nearly every first replacement conversation.
Answers by
Dr. Harald Dreher
Founder · Dreher Consulting
Since 1992 he has guided Mittelstand companies through replacing in-house-built ERP systems. He advises vendor-neutrally, taking no commission from any software vendor.
LinkedIn · Last updated: 21 July 2026
Yes — that is what the parallel run is for. The legacy system remains the productive system through assessment, migration and testing; the successor takes over only at a planned cut-over, usually placed in a low-activity window. Until the exit criteria of the parallel run are met, nothing is switched off, and a written rollback plan covers the cut-over itself.
From several directions at once: the database schema and, where accessible, the source code; the reports the business actually uses; and structured interviews with the people who have worked with the system longest. Each business rule found is written down and reconciled against real transactions until the documentation reproduces what the system does. The result is knowledge on paper — no longer knowledge in one person’s head.
Long enough to prove the successor against complete business cycles — typically at least one full month-end close and every process the business depends on, from order to invoice. The honest answer is that the duration follows from agreed exit criteria, not from the calendar: the parallel run ends when the reconciliation counts match, not on a set date.
In most cases yes, in read form. German retention rules (GoBD) require that tax-relevant data remains readable and machine-evaluable for the statutory retention periods — switching the server off does not end that obligation. The decommissioning concept settles how: a read-only instance, an archive extraction, or retention inside the new system, each with a defined end date.
Against criteria, not instinct. The decision path weighs knowledge risk (who can still maintain the system), functional fit (how far daily work has outgrown it), the cost trajectory of keeping it alive, and the dependence on a single person or supplier. Modernising is sometimes the right answer — the deliverable is a board-ready decision either way, not a foregone conclusion.
They are inventoried during the assessment and classified one by one: replaced by the standard system, rebuilt against the new APIs, or retired because nobody still uses the output. Each interface is proven during the parallel run — no connection is switched off until its successor has carried real traffic.
Insight
In Brief: The risk of a wrong ERP decision rarely lies in the software itself — it lies in unclear decision criteria, co…
Insight
Key Points at a Glance The greatest risks associated with an ERP migration are organizational, not technical: underestim…
Insight
The companies that will fail with AI in ERP in the next five years will not fail because of SAP Joule, Microsoft Copilot…
The full first conversation. Includes an initial SCOReX® assessment of your ERP situation.
Book the call →Not ready for the full conversation? A short call to clarify whether we're the right advisors for you.
Book a short call →Send us a short note about where you are — we'll reply with a clear next step, not a sales pitch.
Email us →