Move closed periods and cold history out of HANA and ECC into lower-cost storage tiers with retention rules, and keep every row answerable through the fabric. Databases get smaller, licence and hardware bills follow, batch runs get faster, and audit access works the way it always did.
HANA is sized and priced by memory. Closed fiscal years, completed orders, delivered shipments and old change logs sit in that memory at the same price as this morning's transactions. Moving them to storage priced for history shrinks the database, speeds the nightly runs that scan it, and cuts the size of the S/4HANA system you migrate to.
Closed periods and completed documents leave memory; the hot database holds what operations and planning use.
MRP, month-end and reporting jobs scan fewer rows because the history they never need is elsewhere.
Retirement specialists report 30–70% less data to migrate when history is offloaded first.
Auditors query the offloaded periods through the fabric with the same vocabulary and the same access policy.
| Tier | What lives there | Storage | How it is read | Cost signal |
|---|---|---|---|---|
| Hot | Current data plus the last two fiscal periods | HANA / ECC | The ERP itself; the fabric for questions | Memory-priced |
| Warm | Years one to seven: consulted by finance, planning and audit | Lakehouse tables (Parquet) in Snowflake, Databricks, Fabric or S3 | The fabric, live, in the same query as hot data | Object storage, columnar |
| Cold | Year seven onward, legal holds, records kept for statutory reasons | Archive-class object storage | The fabric on demand; restore into any target when needed | Cents per gigabyte-month |
Ten years for financial documents, seven for HR records, whatever your policy says — per table, per period, with an audit trail of every expiry.
A hold suspends expiry and erasure for the records it covers until it is lifted by the person who set it.
GDPR erasure runs against archived records with evidence attached; the 47-minute workflow from the showcase estate applies.
Any dataset reloads into S/4HANA, a warehouse or a file target through the same engine, reconciled the same way.
SAP's Information Lifecycle Management can hold the retention status auditors look for; Lima holds the same history in a form people can query. The two run side by side, fed by the same scheduled offload.
ILM for the compliance flag; Lima for everything that must stay usable. The same pattern serves a full system retirement when the ERP itself is switched off.
One engine underneath every page in this family. It reads from any source and writes to any target, runs batch loads or change-data streams, handles a nightly delta or a multi-terabyte migration, and is licensed by capacity, so the bill stays the same however many rows move. Lima's fabric answers questions on data in place; Lima Backbone moves, transforms and returns data on a deadline. When to federate and when to pipeline · The Backbone hub.
Yes. The fabric reads hot, warm and cold tiers in one query, so dashboards, ChatLima and agents see the full history. Access policy applies to every tier the same way.
Complete business documents move together with their dependent tables, following SAP's archiving objects. A purchase order never ends up with its items on one tier and its header on another.
Your offload policy: closed periods, completed documents, age thresholds. It is a rule with an owner, and it runs on a schedule with an audit trail.
Archive-class object storage from your cloud provider, at its published rate. Lima's subscription is sized by capacity and includes the scheduled offload runs.
Restore reloads any dataset into the ERP, a warehouse or a file target, reconciled the same way it was offloaded.
Offload keeps the ERP running with less inside it. Decommissioning extracts everything and switches the system off. Both use the same engine and the same reconciliation.
Policy in week one, first closed periods moved and proved in week three, retention rules running by week four.
