Decommissioning SAP ECC after S/4HANA migration: archive or shut down?

Cutover weekend ended successfully eight months ago. The business is on S/4HANA. The old ECC system is still running.

Nobody is using it. Nobody can quite explain why it is still running. The basis team keeps it patched because SAP support says so. The infrastructure team keeps the nodes provisioned because the basis team has not signed off on shutdown. The CFO keeps paying the license, the hosting, the support, and the disaster-recovery line for a system that no longer does any operational work.

Someone finally asks the question in a steering meeting: what are we waiting for? The answer, after a pause, is uncomfortable: we never figured out how to satisfy retention without keeping it running.

This is the most expensive moment in the post-migration calendar — the period in which the program has finished the cutover, declared victory, and quietly begun paying for two SAP systems instead of one because the retirement of the old one was never planned.

Step One — The Wrong Assumption

We'll keep ECC running in read-only for retention.

"It's already there. We'll just leave it on, lock the writes, and use it as the system of record for audits."

— Standard post-cutover position, year one

The assumption sounds operationally simple. It is also the most expensive form of retention an enterprise can engineer. Running a parallel SAP system carries the license, the basis support, the infrastructure, the disaster-recovery posture, the security patching, and the audit perimeter of an active production system — for a workload that consists of occasional read access. Per query served, the cost is several orders of magnitude above what governed application retirement would carry.

Step Two — The Partial Signal

The CFO sees the line item, and the conversation finally starts.

The partial signal is usually budget. The annual SAP cost line shows up post-migration with two SAP systems instead of one, and the difference does not match the project plan, which assumed the second one would be retired. The CFO asks the obvious question. The platform team explains that retention requirements have to be satisfied somehow, and the cheapest mechanism the team knows is to keep ECC running.

That is the moment to find out whether the team has actually evaluated the alternative — governed application retirement — or whether the parallel-system position is a default that nobody has stress-tested.

Step Three — The Failed Fix

Running ECC indefinitely as a retention archive.

The failed fix is the indefinite parallel system. The fix is failed because it treats the source system as the retention layer, which it was never designed to be. The cost is paid on the operational tier; the workload is read-only. The infrastructure carries failover and DR designed for production; the actual access is occasional. The license entitlement covers full functionality; the use case is a query interface. Every dimension of the system is over-provisioned for the actual workload, and the over-provisioning is recurring forever.

The fix also produces a soft failure mode that compounds over time: the team that knows how to operate ECC retires from the project, the support contracts get harder to renew, and the system the program was depending on for audit defensibility quietly degrades.

Fig. 1 — Application retirement is not loss of access — it is access at the cost level the workload actually justifies.

Step Four — The Real Failure

The actual failure is conflating shut-down with loss of access.

The real failure is a conceptual one: treating shut-down of the source system as equivalent to loss of access to its data. They are not the same. Application retirement, done with the right target, moves the data and the business context (the table relationships, the document semantics, the retention metadata, the legal-hold posture) into a governed retirement store that supports audit-defensible read access without running the source application.[1] ECC goes off. The data, the retention rule, and the audit response stay on.

Programs that have done this find that the post-migration SAP cost line drops to the new S/4 footprint plus a fraction for retention, rather than to two production SAP systems running in parallel.

Step Five — The Definition

Now the definition lands.

Application retirement is the structured migration of a decommissioned application's data and business context into a governed retention store that supports audit-defensible read access, retention enforcement, and legal hold — without keeping the source application running.

The discipline does three things at once: it preserves the data, it preserves the meaning of the data (table relationships, document semantics), and it preserves the audit response. The source application gets to shut down because the retention layer is the one carrying the obligation that previously required it to stay on.

What Solix Enforces

ECC retirement into a governed retention store with full SAP context preserved.

What Solix runs here is the SAP-specific application-retirement path: ECC data and business context migrated into the Solix governed retention store, with audit-defensible read access, retention rules carried forward from SAP ILM, and legal-hold posture preserved. ECC goes off. The records-management obligation continues to be met. The post-migration SAP cost line reflects the operational system the business actually runs on, not the historical system it does not.

Three things to do this week

• Price your current ECC run-rate as the retention bill. Pull the annual cost of running ECC post-cutover — license, hosting, basis, DR — and label it as your retention bill. That is the number application retirement is competing against.
• Audit-test your S/4 read path against an ECC-era document. Pick a document type that has retention obligations (a tax-relevant FI posting, a supplier invoice under a contract retention rule), and check whether the S/4 system can produce it under audit. The answer is usually no, which is why ECC is still running.
• Scope application retirement for the top three source systems, not just ECC. Most SAP shops decommissioning ECC also have one or two satellites (BW, CRM, SRM) on the same timeline. Scope them as a single retirement program rather than a sequence; the unit economics improve substantially when they share the retention target.

References

• SAP Help Portal — SAP Information Lifecycle Management (ILM) — Overview. ILM is the governance framework whose retention rules carry forward into the retirement store.
• SAP press release — SAP Extends Mainstream Maintenance for SAP S/4HANA and Updates Its Maintenance Strategy. SAP's maintenance timeline frames the calendar pressure to retire ECC and stop paying parallel support.
• U.S. SEC — Rule 17a-4: Records to Be Preserved by Certain Exchange Members, Brokers and Dealers. Recordkeeping rule that establishes audit-defensible read access as the retention requirement in financial services.
• EUR-Lex (official EU law) — GDPR Article 5(1)(e) — Storage limitation. Storage-limitation principle that constrains how long ECC-era personal data can be retained, even in an archive.
• IDC press — IDC Worldwide Global DataSphere Forecast. IDC's analysis of legacy-system retention spending establishes the broader pattern of parallel-system cost.