Analytics Legends The knowledge platform for SAP Analytics
Academy module

Historical Data Strategy

Historical data tiering and the legal retention gate — architecture diagram for Historical Data Strategy, Analytics Legends Academy module M071

As of 2026-08-16

Edited by , sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

Decide history disposition by access tier (hot 2-3y full granularity · warm 3-7y aggregated · cold statutory-only archived) before cutover — not by migrating everything at full granularity. Four options: full migrate (hot only), aggregate-and-migrate (warm 80/20), archive to NLS/object store (cold), read-only legacy sunset with a hard date. Retention is a legal input (DE tax 10y AO; GDPR forbids over-retention) — get the matrix signed by legal first. "Do we need 12 years of daily granularity?" is the money question; aggregating to monthly cuts warm storage ~10×. Saving the client money is the durable rate justification.

What you will learn

  • Classify BW/4HANA historical data into hot / warm / cold access tiers and select the correct disposition (full migrate · aggregate-and-migrate · archive to NLS/object store · read-only legacy sunset) for each tier
  • Build a retention matrix reconciling statutory retention (e.g. German tax records 10y under §147 AO, commercial records under §257 HGB) against GDPR purpose-limitation, signed off by legal/finance before any archive or delete decision
  • Challenge unnecessary full-granularity retention (e.g. 12 years of daily-grain history) with a monthly-aggregation alternative and quantify the resulting storage saving
  • Set a hard sunset date for a read-only legacy fallback system and integrate it into the decommission wave plan (companion module M068)

Module overview

Historical data strategy answers the question every BW migration eventually hits: what do we do with 8-15 years of history that lives in the system we are about to retire? The wrong answer (migrate all of it, at full granularity, into the expensive new platform) quietly doubles the storage bill and slows every query. The senior answer is a deliberate, retention-aware tiering decision made before cutover.

Start from the access pattern, not the data volume. History splits into three access tiers: (1) hot — last 2-3 fiscal years, queried constantly, needs full granularity in the active platform; (2) warm — 3-7 years back, queried occasionally (audit, year-over-year trend), tolerable at aggregated granularity or with higher latency; (3) cold — beyond statutory minimum-use, queried almost never but legally must be retained. Most organisations carry all three at hot-tier cost because nobody made the tiering call.

Prerequisites

  • Intermediate hands-on experience on SAP analytics projects
  • Review core concepts first: C035, C033, C032

Outcomes

  • Classify historical data objects into hot/warm/cold access tiers using query-frequency evidence, not data volume
  • Produce a legally-signed retention matrix that reconciles statutory retention with GDPR purpose-limitation
  • Quantify the storage and cost impact of aggregating warm-tier data from daily to monthly granularity
  • Design a legacy read-only sunset window with a hard retirement date tied to the decommission wave

Full module available to members. The full module adds: the decision framework · the end-to-end scenario walkthrough · the KPI scorecard · the anti-patterns · the code blocks · the knowledge check · the diagrams.

Open in the app →

Next in this track