Data Ageing and the Simplified Data Footprint

Classic ECC behaviour

S/4HANA behaviour

Project impact

• Custom ABAP or interfaces that SELECT directly from BSIS, BSAS, COSP, COSS, or GLPCA return nothing or partial data because those tables are compatibility views over the universal journal rather than populated tables; the fix has to be in the code, not in the data.
• Sizing teams who assume data ageing will shrink disk requirements are wrong; it shrinks memory requirements only, and a hardware sizing exercise based on that misunderstanding under-specifies storage or over-promises RAM savings to the business.
• Month-end and year-end closing jobs that do full-period scans across FI or CO line items can slow down once large volumes sit in the cold partition, because cold reads still happen, just at lower priority and with a decompression cost.
• Functional teams are asked to define what business complete means for their object (a closed FI document, a delivered and invoiced sales order, a settled CO object) and this decision, not a technical one, determines when and whether ageing produces any benefit.
• Authorisation and audit teams need reassurance that ageing is not archiving: nothing has left the system of record, so legal hold and audit trail obligations are unaffected, but this has to be demonstrated, not assumed.

Migration actions

• Run the simplification item check early and treat every finding that touches FI, CO, or MM aggregate tables as a mandatory remediation item, not a nice-to-have; this is a pre-conversion gate, not post-go-live cleanup.
• Inventory every custom report, interface, and extractor that reads BSIS, BSAS, BSID, BSAD, COSP, COSS, GLPCA, or GLPCT directly, and redirect them to the universal journal or its released compatibility views before cutover.
• Decide separately, and later, whether to activate data ageing; this is a sizing and cost decision that belongs with the technical architect and the Basis sizing exercise, informed by functional definitions of business complete per object, and it is genuinely optional.
• If data ageing is adopted, define and test the business complete logic per object in a volume-representative environment, because logic that never marks records complete produces zero ageing benefit despite the feature being switched on.
• Keep classic archiving in the roadmap regardless of the ageing decision; ageing addresses memory, archiving addresses disk and retention, and dropping archiving on the assumption that ageing replaces it leaves storage costs unaddressed.

Whose problem this is

Common pitfalls

• Test systems are usually a fraction of production volume, so cold-partition read performance issues in reporting and closing only appear once production-scale data exists, well after go-live.
• Business complete rules copied from a reference implementation without adaptation to local closing cycles or document flows either age nothing, giving no benefit, or age records still needed for open reporting periods, causing confusing gaps in current-period reports.
• Once ageing has run for a period, reversing the decision to deactivate it and reload everything into the hot partition is a real project of its own, not a configuration toggle.
• Custom code that assumes any record found via Open SQL is automatically fast forgets that a hit against the cold partition carries a real, sometimes significant, latency cost that shows up as a mysterious slowdown in month-end batch windows rather than a clear error.