Decommissioning SAP ECC: what history to keep
Decommissioning SAP ECC means switching the legacy system off after go-live on the new ERP without losing the history that audit, tax, legal retention and reporting still require. The practical approach is retain → report → decommission: extract and validate only the records that must be kept (financial documents, master data, the audit trail) into a structured archive, keep that archive queryable for on-demand historical reports, then shut ECC down and stop paying for licences, infrastructure and maintenance.
Updated · Visehub
The half of the decision nobody plans
Going live on S/4HANA or Business Central is half of leaving ECC. The other half is what happens to the old system. Historical data is still needed — for audits, tax inspections, legal retention and the reports finance runs against prior years — and the easy answer is to keep ECC alive read-only. It is also the expensive answer: licences, infrastructure, maintenance and patching, every year, for a system nobody transacts in.
Retain → report → decommission
01 · Retain — carve out what matters. Apply the migration discipline to history: extract and validate only the records that must be kept — financial documents and their items, the master data they reference, change documents, the migration cross-reference tables — scoped by retention rules per country and document type. Not the entire legacy database. The result is a profiled, validated, structured archive with a reconciliation report that says what was kept and why.
02 · Report — keep reporting online. The retained data stays queryable, so finance and business teams pull historical reports on demand without logging into the old system. Decommissioning fails when the archive is a set of files nobody can open; it succeeds when it answers questions.
03 · Decommission — switch ECC off with confidence. With history preserved, accessible and reconciled, the legacy system can go — and its licence, infrastructure and maintenance costs with it.
What this needs from the migration
Two things, both cheap if planned and expensive if not: retention periods defined per object before the carve-out, and the migration’s cross-reference tables (old document and partner numbers → new) kept with the archive, so an auditor can follow a transaction across the system change.
Where it fits
ECC exit is usually planned together with the migration data track — the same extraction and validation discipline, applied twice. The full context is in SAP ECC → Business Central: the data track.
Frequently asked
- Why not just keep ECC running read-only?
- Because it costs licences, infrastructure, maintenance and security patching every year, for a system nobody transacts in. Most organisations that plan to keep it 'for a while' are still paying three years later.
- What has to be retained?
- What audit, tax and legal retention rules in your countries require — typically financial documents and their line items, the master data they reference, change documents and the migration cross-reference tables — plus whatever reporting still looks back at. Not the entire database.
- How long?
- Retention periods differ by country and document type (commonly 5–10 years for financial records). Define them per object before the carve-out, so the archive can expire data the same way the live system would have.
- Who does the carve-out?
- The same discipline as the migration data track — extraction, scoping, validation, reconciliation — applied to history instead of to the records moving to the new system. Visehub runs it with vise DMW as part of an ECC exit.