You have selected your new ERP, completed the go-live, and teams are entering data in the new system. The project is finished, you think. Except the old ERP is still running. Licences keep billing, servers keep consuming power, and an administrator maintains the system “just in case.” Six months pass, then a year, then two.
This scenario is common — and costly. According to ERP Today, organisations should allocate 15–20% of their total ERP implementation budget specifically to decommissioning the legacy system. Those that don’t end up with a “ghost ERP” that drains resources while producing no value.
This guide offers a structured eight-step plan for shutting down an old ERP cleanly. Not an article on “why to migrate” — that subject is covered in our ERP audit guide — but an operational plan for “how to switch it off” without losing data, compliance, or sleep.
Why Decommissioning Is a Project in Its Own Right
The Risks of “We’ll Switch It Off Later”
The temptation is strong to delay decommissioning the old system. Users want to “check in the old one” for a few months. The project team is exhausted after go-live. The budget is spent.
The problem is that “later” never comes. Without a formalised deadline, the old ERP stays in service by inertia. Access rights are not revoked, security updates stop being applied, and the system becomes a growing cybersecurity risk. ERP Today reports that large organisations keeping an unsecured legacy system face potential costs of $4.2–$7.3 million per year, including ransomware exposure and efficiency losses (ERP Today, 2025).
Decommissioning must therefore be planned from the start of the migration project, with a dedicated budget, a named owner, and a binding timeline.
Hidden Costs of Maintaining a Ghost ERP
A legacy ERP kept artificially alive generates costs across four categories:
- Licences: vendor contracts keep running as long as the system is in production. Even in “read-only” mode, most vendors charge for named users.
- Infrastructure: servers, storage, backups, monitoring. For on-premises hosting, the annual cost of a legacy ERP environment for a mid-market company often runs between €50,000 and €150,000.
- Skills: maintaining an ageing system requires rare profiles (COBOL, RPG, legacy ABAP). These skills are expensive and becoming scarcer.
- Regulatory risk: an unmaintained system no longer receives security patches or fiscal/tax updates. Non-compliance risk increases every month.
According to TJC Group, some sectors such as banking and insurance dedicate up to 75% of their IT budget to preserving legacy systems (TJC Group). Even without reaching those proportions, an industrial mid-market company can easily waste €100,000–€200,000 per year on a ghost ERP.
The 8-Step Decommissioning Plan
Step 1: Dependency Inventory
Before unplugging anything, map everything that touches the old system:
- Inbound and outbound interfaces: EDI with suppliers, bank feeds, CRM connectors, e-commerce synchronisation, BI exports.
- Reports and outputs: identify reports still generated from the old system. Some users bypass the new system by pulling “their” report from the old one.
- Batch jobs and scheduled tasks: overnight processes, automated purges, pricing calculations, stock revaluations.
- Direct database access: ad-hoc SQL queries, connected Excel macros, third-party reporting tools.
Expected deliverable: a dependency matrix listing each data flow with its status (migrated to new system, to be migrated, to be removed) and the business owner responsible.
Step 2: Legal Archiving Requirements Mapping
Data archiving is not optional. Retention periods vary by country, and ignoring them exposes the organisation to penalties during a tax audit.
| Country | Accounting Retention Period | Legal Basis |
|---|---|---|
| UK | 6 years (companies), up to 20 years (VAT records) | Companies Act 2006 / HMRC guidance |
| Germany | 8–10 years (8 for accounting records from Jan 2025, 10 for balance sheets and ledgers) | HGB §257 / GoBD |
| France | 10 years | Art. L123-22 Code de commerce |
| Belgium | 7 years (standard tax), 10 years for records that form the accounting basis | Code de droit économique |
Practical consequence: you cannot simply “delete the database.” You must extract data, archive it in a durable format, and guarantee read access for the full legal retention period.
For organisations subject to GDPR, the DPO must also validate the personal data purge strategy (Article 17 GDPR, right to erasure). Personal data not covered by a legal retention obligation must be deleted or anonymised.
Step 3: Historical Data Extraction and Archiving
The extraction must cover three scopes:
- Transactional data: accounting entries, invoices, orders, stock movements. These are the records subject to legal retention obligations.
- Reference data: chart of accounts, item master, customer/vendor records. These are needed to make archived transactions meaningful.
- Configuration and documentation: business rules, workflows, access rights. Useful in the event of an audit or dispute to prove the system operated according to applicable rules.
Preferred durable archiving formats:
- PDF/A-3: for documents (invoices, reports) with embedded attachments.
- Structured XML (SAF-T, audit file formats): for accounting data, readable by tax control tools across Europe and beyond.
- SQL export or structured CSV: for high-volume transactional data, accompanied by a data dictionary.
Critical point: the archive must be validated before shutting down the source system. Run consistency checks (control totals, transaction counts, accounting balances) between the old system and the archive. An incomplete archive discovered after shutdown is a serious problem.
Step 4: Coexistence Plan and Parallel Run Period
The parallel run — the period during which both systems operate simultaneously — is unavoidable, but must be time-boxed. Beyond three to six months, users stop entering data rigorously in the new system because they know the old one is still there as a “safety net.”
The coexistence plan must define:
- Start date: typically the go-live date of the new system.
- Hard end date: communicated to all users from day one. This date must be endorsed by executive management to carry sufficient weight.
- Data entry rules: during the parallel run, only the new system is the system of record. The old one is in “read-only” mode — no new entries.
- Exit criteria: which indicators must be green before moving to the next step (for example, zero reconciliation discrepancy between the two systems on the last closed month).
Step 5: Progressive Interface Disconnection
Interface disconnection is the most technical step. Work in reverse criticality order: start with the least critical flows to build confidence.
Recommended sequence:
- Reporting and BI: redirect data sources to the new system. Verify that dashboards produce identical results.
- Secondary flows: CRM synchronisation, supplier portals, connected HR tools.
- Financial flows: accounting exports, bank interfaces, tax declarations. These are the last flows to switch because they are the most sensitive.
- Partner EDI: notify your trading partners of any format or channel change. An EDI cut without notice can halt a supply chain.
Each disconnection must be documented (date, owner, non-regression test) and reversible within 48 hours in case of issues.
Step 6: User Access Deactivation and Licence Revocation
Proceed in two stages:
- Switch to read-only: disable all write transactions. Users can still consult records, but can no longer create or modify them.
- Full revocation: after the consultation period (typically one to two months in read-only), close all access.
Document revoked access in a register (who had access to what, revocation date). This register is useful during a compliance audit.
On the vendor side, formally notify the end of use and negotiate contract termination. Some vendors require six to twelve months’ notice — review your contractual clauses at the start of the decommissioning project.
Step 7: Completeness Audit Before Final Shutdown
Before pressing the “off” button, review this checklist:
- All data subject to legal retention requirements has been archived and validated
- Archives are readable independently of the source system (open test on a clean machine)
- No active interface is still pointing to the old system
- All user access has been revoked
- Vendor licences are terminated or in the process of termination
- The DPO has validated GDPR compliance of the purge strategy
- A closure report has been written and archived (scope, dates, decisions, residual anomalies)
- Executive management has formally approved the shutdown
This audit should be performed by someone other than the person who led the decommissioning. A second pair of eyes eliminates blind spots.
Step 8: Infrastructure Shutdown and Vendor Contract Closure
The technical shutdown covers:
- Stopping application services: application server, database server, middleware.
- Final backup: one last complete backup of the environment, stored off-site and retained in accordance with the retention policy defined in Step 2.
- Infrastructure teardown: return of physical servers, termination of virtual machines, deletion of cloud environments.
- Contractual closure: written confirmation of contract end with the vendor, recovery of a data destruction certificate where applicable.
Keep technical documentation (architecture diagrams, operating procedures) for at least five years. In the event of a dispute or audit, it demonstrates the system was operated and shut down in accordance with applicable rules.
Common Mistakes and How to Avoid Them
Keeping the Old ERP “Just in Case” for Three Years
This is the most widespread mistake. The justification is always the same: “you never know, we might need to check something.” In practice, after six months, lookups in the old system become anecdotal. After a year, they are near zero.
The solution: archive the data (Step 3), provide read access to the archive, and shut down the system. The archive serves the consultation function without the cost of keeping a full environment alive.
Forgetting SAF-T and Audit File Obligations on Archived Data
Tax authorities across Europe can request standardised audit files covering multiple prior fiscal years. If your data is archived in a proprietary format that is unreadable without the old system, you are non-compliant.
The remedy: export each fiscal year in the applicable standardised format (SAF-T for most European countries, iXBRL for the UK, FEC for France) before shutting down the system. The principle is the same regardless of jurisdiction: human-readable, machine-processable, independent of proprietary software.
Summary Checklist
Below are the key milestones of the decommissioning plan, to be integrated into your project schedule from the start of the migration:
| Phase | Milestone | Indicative Timing |
|---|---|---|
| Scoping | Dependency inventory complete | M-6 before shutdown |
| Scoping | Archiving obligations mapped | M-6 |
| Extraction | Historical data extracted and validated | M-3 |
| Coexistence | End of parallel run | M-2 |
| Disconnection | All interfaces switched | M-1 |
| Closure | Access revoked, completeness audit passed | M-0 |
| Closure | Infrastructure shut down, vendor contract closed | M+1 |
The typical timeline spans six to nine months after go-live of the new system. Compressing it below four months is risky. Letting it exceed twelve months means accepting payment for a system that no longer serves a purpose.
To go further on the technical aspects of data migration, see our methodological guide on ERP data migration. If you are in the process of evaluating your current system, our 7-dimension ERP audit methodology will help you build an objective diagnosis. And if vendor dependency is a concern, our guide on ERP vendor lock-in offers an analysis framework and a structured exit strategy.
