Structured retirement of S/4HANA after Oracle Fusion go-live. Archive every BKPF/BSEG/ACDOCA row, catalogue every ABAP customisation, disconnect every IDoc/BAPI/OData integration, release every HANA licence — with full German HGB/SOX/BaFin compliance.
The savings are huge, the work is structured, and yet most organisations leave S/4HANA running for years after Fusion go-live — because no one owns the decommissioning plan.
The migration team's mandate ends at Fusion go-live. The cost-savings business case that justified the migration assumed S/4HANA would be shut down within 6–12 months. But once go-live happens, the team disbands. No one owns the decommissioning plan. Six months later, a finance manager argues to keep S/4HANA alive 'for one more close cycle, just in case'. Two years later, S/4HANA is still consuming £2M+ annually — and the business case that justified the migration is silently being eroded.
Syntra ETL's S/4HANA decommissioning workstream exists to close that gap. We treat decommissioning as a discrete, structured project with its own deliverables: archive every BKPF/BSEG/ACDOCA row to cloud cold storage; catalogue every ABAP customisation, CDS view, BAdI, and IDoc partner profile; disconnect every integration touchpoint with orchestrated cut-over; stand up a historical reporting layer that satisfies finance ops, tax, internal audit, external audit, and regulator access needs; release the HANA database licence, the S/4HANA application licence, and the RISE with SAP subscription on a defined date.
The result: a clean shutdown 4–7 months after Fusion go-live, with full audit and tax compliance preserved for the German HGB 10-year retention window, the SOX 7-year window, the BaFin sector-specific retention, and any FDA / MHRA pharma manufacturing retention requirements. The £1M–£8M+ annual run-rate that motivated the migration starts hitting the P&L in year one, not year three.
The full set of cost line items and operational dependencies you're eliminating.
HANA Enterprise Edition is licensed per GB of in-memory data; mid-large customers pay £500K–£2.5M/year. Decommissioning releases the full draw — directly recoverable at the next SAP renewal cycle.
Per-user FUE (Full Use Equivalent) and limited-use licensing for the application layer — £200K–£1.5M/year typical. Wound down with HANA. RISE customers see this consolidated into the subscription.
RISE bundles HANA, application, and infrastructure into a single subscription escalating 8–12% annually — £400K–£3M typical. Wind-down requires 30–90 day contractual notice; Syntra ETL's archival makes the notice defensible.
Self-hosted on-prem customers retire HANA-certified appliances (HPE Superdome, IBM Power), or TDI infrastructure (Cisco UCS, Dell PowerEdge), or hyperscaler HANA-certified instances. £150K–£800K/year recovered.
Typically 1.5–3 FTE of Basis administration (HANA DBA, SAP application admin, Solution Manager admin) — £200K–£600K/year fully loaded. Reassigned to Fusion or other priorities.
PUM (PeopleSoft Update Manager equivalent for SAP is SUM/SPAM), HANA SP revisions, security CPUs — 4–8 person-weeks per year. Archive has no patch cycle, no security CVE exposure.
A repeatable, governed workflow that protects audit / tax / regulatory position while extracting the full TCO benefit.
Stakeholder alignment (finance, audit, tax, IT, security, compliance). Retention design per data domain (HGB 10y, SOX 7y, BaFin sector-specific, FDA full-lifecycle). Integration touchpoint inventory. Decommission criteria and success metrics defined.
Pre-built HANA extractors pull every in-scope SAP table — full history. Output staged to cloud object storage as Parquet, hash-signed, partitioned by fiscal year and company code. Customisation catalog (ABAP, CDS, BAdI, IDoc) captured in parallel.
SQL/REST/BI access provisioned. Pre-built reports (trial balance, AP/AR aging, asset register, journal detail) deployed. UAT with finance ops, internal audit, tax. GoBD-compliant export tested.
Every IDoc/BAPI/OData/SAP CI integration mapped to its Fusion successor. Orchestrated cut-over: upstream systems re-pointed to OIC, downstream consumers re-pointed to Fusion REST. Each integration validated before next.
S/4HANA moves to read-only (no further postings). Archive parity validated for the read-only period. Side-by-side query results compared between S/4HANA and archive for sign-off. Tax-authority and audit sample-queries validated.
Sign-off pack issued. SAP-side notice given for RISE wind-down (if applicable). HANA database brought down. Application servers retired. Hardware repurposed or decommissioned. Licences released at next SAP renewal cycle.
Every regulatory regime that applied to live S/4HANA continues to be satisfied by the archive, often more defensibly.
10-year retention for accounting records, invoices, tax-relevant documents. WORM-locked archive, GoBD-compliant immutability, IDEA-compatible export for Finanzamt audits — more defensible than live HANA.
7-year US retention for financial records and supporting documentation. SOX 404 control evidence preserved (security snapshot, change history). Auditor-direct SQL access for sampling.
6-year UK retention. Pre-built HMRC-format extracts. Companies House filings traceable back to source SAP documents via archive.
Sector-specific retention for regulated financial services; often 10 years for transaction records. Role-partitioned access for regulator queries with full audit log.
Manufacturing batch records, equipment qualifications, deviation history (QMEL) — full product lifecycle preservation, electronic-signature records preserved per Part 11.
Data-protection-by-design: PII masked by default, role-controlled unmask with audit log, configurable Article 17 (right to erasure) workflows that respect HGB-mandated retention.
SAP S/4HANA decommissioning is the structured retirement of a production S/4HANA instance — typically after migration to Oracle Fusion or another successor system. The work spans five threads: data archival (every BKPF/BSEG/ACDOCA, LFA1/KNA1, MARA row preserved to queryable cloud archive per German HGB/SOX/BaFin retention), customisation inventory (ABAP code, CDS extensions, BAdI implementations, IDoc partner profiles catalogued as audit-evidence artifacts), integration disconnection (orderly retirement of every IDoc partner connection, BAPI consumer, OData service consumer, and SAP Cloud Integration tenant), licence release (HANA database licence, S/4HANA application licence, RISE with SAP subscription wound down), and infrastructure decommission (HANA appliance or TDI hardware retired, RISE managed-service unsubscribed).
Typical mid-to-large customer savings: HANA database licence £500K–£2.5M/year, S/4HANA application licence £200K–£1.5M/year (depends on user count and module licensing), RISE with SAP subscription £400K–£3M/year (where applicable, replaces both of the above), infrastructure £150K–£800K/year (HANA-certified appliance refresh + DC space + power + network), Basis support £200K–£600K/year (typically 1.5–3 FTE), patch cycles £80K–£200K/year (PUM, SP-stack, HANA revisions). Total: £1.0M–£8M+/year depending on scale. For RISE customers, the saving consolidates into the subscription line item but follows the same scale.
A typical S/4HANA decommissioning runs 4–7 months from project kickoff to source-system shutdown — assuming the migration to Oracle Fusion (or alternative successor) is complete and the archival design is approved. Breakdown: weeks 1–4 archival scoping and stakeholder sign-off (German HGB, SOX, BaFin, FDA retention compliance review); weeks 4–14 archival extraction and validation (full BKPF/BSEG/ACDOCA history, customisation catalog, security snapshot); weeks 14–20 historical reporting layer build, UAT with finance/audit/tax; weeks 20–28 read-only period with side-by-side parity validation; weeks 28–30 source shutdown and licence release. Customers on RISE with SAP have additional 30–90 days for contractual subscription wind-down; on-prem customers can shut down on the date the archive sign-off pack issues.
Yes — and you should. A read-only S/4HANA kept alive 'for queries' still consumes HANA licence (HANA charges for storage and CPU regardless of read-only mode), still consumes infrastructure, still needs Basis patching for security, still draws Oracle/SAP support fees. Cost is typically 70–85% of an active production system. Syntra ETL's archival + historical reporting layer covers every reasonable historical-query use case (finance ops, internal audit, external audit, tax authority response, regulator enquiry) without the source-system overhead. Customers regularly decommission S/4HANA within 6 months of Fusion go-live, releasing the full £1M–£8M annual run-rate.
Custom ABAP code (Z*/Y* reports), CDS view extensions, BAdI implementations, user exits, ABAP CAP services, and IDoc partner profiles are inventoried as a customisation catalog artifact during the decommissioning archival phase. The catalog includes source code, version history, last-modified date, transport history (E070/E071), and business purpose where derivable. This serves three needs: post-decommission audit evidence ('what did our SAP system actually do at decommission?'), retroactive migration support ('if Fusion needs the equivalent of this BAdI six months from now, we have the original logic to reference'), and IP retention (the custom code your organisation invested in remains accessible). The catalog is signed, timestamped, and retained per the same retention policy as the data.
Integration disconnection is its own workstream. Syntra ETL's discovery engine identifies every integration touchpoint: IDoc partner profiles for B2B EDI (ORDERS, INVOIC, DESADV), SAP Cloud Integration / PI / PO tenants, OData services consumed by downstream apps, BAPI/RFC consumers, REST endpoints exposed by SAP Gateway. Each integration is mapped to its replacement in the target architecture (typically Oracle Integration Cloud against Oracle Fusion). A cut-over plan orchestrates the redirect: upstream systems point to OIC instead of SAP CI, downstream systems consume Fusion REST instead of OData. Once all integrations are redirected and validated, the SAP integration layer can be safely retired alongside S/4HANA.
No — exactly the opposite. The Syntra archive is more defensible than a kept-alive S/4HANA in tax-authority audits. Reasons: (1) the archive is immutable by design (Parquet on versioned/WORM-locked storage) — auditors can't object that data was modified after the fact; (2) every read access is logged with user, timestamp, and query — full GoBD audit trail; (3) the archive supports the formal export formats tax authorities use (IDEA for German Finanzamt under GoBD, equivalent for HMRC UK and IRS US); (4) sensitive-data masking with audit-logged unmask satisfies GDPR while still enabling tax-authority access. Multiple Syntra customers have completed full German Finanzamt audits sourced entirely from the archive.
We don't recommend it. The right sequence is: Fusion goes live → 1–2 close cycles in parallel (S/4HANA still active, validating Fusion against S/4HANA to the cent) → audit and finance sign off on Fusion as system of record → S/4HANA moves to read-only → archival runs against the read-only source → historical reporting layer UAT with finance/audit/tax → S/4HANA shutdown. This typically takes 4–7 months from Fusion go-live to S/4HANA shutdown. Trying to decommission earlier creates parallel-run rollback risk; trying to delay past 12 months wastes the licence-saving opportunity that motivated the migration in the first place.
30-minute call. We'll walk through your S/4HANA footprint, RISE / on-prem licence position, retention obligations (HGB, SOX, BaFin, FDA), and decommission readiness — and give you a credible savings number for year one.