SAP Data Archiving & ILM
SAP databases grow continuously — every transaction posted, every document created, every movement logged adds to the data volume that every query must scan and every migration must process. SAP Data Archiving moves completed, legally retained historical data from the active database to a structured archive store — reducing database size, improving system performance, cutting HANA memory costs and accelerating S/4HANA migrations. SAP ILM (Information Lifecycle Management) extends this to a compliance framework — managing retention periods, legal holds, data blocking for GDPR and controlled data destruction. 2iSolutions designs and executes both as a certified SAP Gold Partner.
What database growth actually costs — and what archiving solves
A typical SAP ECC or S/4HANA database doubles in size every 4–6 years of active operation. Each gigabyte of data growth costs more to store, more to back up, more in HANA memory and more in migration downtime. Archiving is not housekeeping — it is a cost control and performance management activity.
Archived data is not deleted data. Archived documents remain fully readable via SAP's standard read programmes and reporting transactions — users can display and report archived data without knowing the data has been moved. The difference is that archived data is no longer in the active database affecting query performance and migration runtime.
SAP archiving objects — module-by-module coverage
SAP provides a library of standard archiving objects — one per data type (FI documents, sales orders, purchase orders, inventory movements etc.). Each archiving object has defined residence time rules (minimum age before archiving), predecessor checks and read programmes for accessing archived data.
Financial Documents
G/L postings, vendor invoices, customer invoices, payment documents and clearing entries — typically the largest data volume in any SAP system. Residence time usually 7–10 years per local legal requirement.
FI_DOCUMNT · FI_ACCOUNTSales & Billing Documents
Sales orders, deliveries, billing documents and credit/debit memos — archived after business process completion (delivery confirmed, invoice cleared). Frees significant space in VBAK, VBAP, VBRK tables.
SD_VBRK · RV_LIKP · SD_VBAKPurchase Orders & GR/IR
Purchase orders, goods receipts, invoice receipts and GR/IR clearing documents — archived after PO completion and invoice settlement. EKKO, EKPO and related tables are typically very large in mature systems.
MM_EKKO · MM_MATBEL · MM_REBELMaterial Documents
Goods movements — goods receipts, goods issues, transfer orders and physical inventory documents. MSEG is consistently among the largest SAP tables; material document archiving delivers significant size reduction in most landscapes.
MM_MATBEL · MM_SPSTOCKProduction Orders
Completed production orders, process orders, planned orders and production confirmations — archived after technical completion and settlement. PP tables accumulate rapidly in manufacturing-intensive operations.
PP_ORDER · PP_PORDCLS · CO_ITEMCO Documents & Line Items
Controlling documents, cost centre line items, internal orders and profitability segments — archived after period close and settlement completion. CO data volume often mirrors FI but is archived separately.
CO_ITEM · CO_ORDER · CO_COSTCTRMaintenance Orders & Notifications
Maintenance orders, notifications, service entries and time confirmations — archived after technical completion. PM history is valuable for maintenance analytics; archived data remains queryable.
PM_ORDER · PM_QMELQuality Notifications & Inspections
Quality inspection lots, usage decisions and quality notifications — archived after completion and GR posting. Pharma and regulated industries often require longer retention; archiving supports this without keeping data in the active DB.
QM_CONTROL · QM_QMELPayroll Results
Payroll cluster data — historical payroll results accumulated per employee over years of operation. Archived payroll remains accessible for retroactive payroll calculations and statutory audits via standard read programmes.
PY_RESULT · HR_MASTSAP Information Lifecycle Management — beyond archiving to compliance
SAP ILM extends data archiving into a managed compliance framework — governing not just where data is stored but how long it must be kept, who can access it, whether it is subject to legal hold and when it must be permanently destroyed. ILM is the framework that connects data archiving to GDPR compliance and data governance.
Data Retention Management
Define how long each data type must be retained — financial documents 7+ years, payroll 8+ years, production records per GxP requirements. Retention rules enforced systematically; data cannot be deleted before the retention period expires regardless of who requests it.
Legal Hold Management
When litigation or regulatory investigation is pending, a legal hold freezes specific data from destruction — even if the normal retention period has expired. The hold is released by authorised personnel when the matter is resolved; the data then resumes its standard retention lifecycle.
Data Blocking (GDPR)
GDPR requires that personal data no longer needed for its original purpose is blocked from processing — even if it must still be retained for tax or legal reasons. ILM manages data blocking at the record level; blocked data remains in the system for statutory purposes but is inaccessible for business processing.
Data Destruction
When retention periods expire, no legal holds exist and no blocking applies, data can be permanently and irreversibly destroyed from both the active system and the archive store. ILM enforces the destruction workflow with audit trail — proving to data protection authorities that personal data was destroyed as required.
Traditional SAP archiving writes to file system. SAP ILM Store provides a structured, certified archive repository with retention rule enforcement, legal hold integration and WORM (Write Once Read Many) support for audit-grade immutability. ILM Store is the recommended approach for organisations with regulatory compliance requirements.
SAP DART (Data Retention Tool) extracts financial and tax-relevant data into a standardised format for submission to tax authorities in countries that require it (GDPdU in Germany, FSKR in Switzerland). DART extracts from both the active database and the archive — covering the full data history for tax audits.
Four scenarios where data archiving delivers the highest business value
Data archiving is sometimes treated as a long-term housekeeping activity — something to do "eventually." These four scenarios show when archiving should be treated as urgent, with a defined timeline and measurable outcome.
Pre-S/4HANA Migration Archiving
The single most impactful use of data archiving. SUM DMO runtime is directly proportional to the data volume it must migrate. Archiving FI, MM, SD and CO documents before migration compresses the cutover window — reducing planned downtime and the risk of a missed go-live window. For large ECC systems, pre-migration archiving can reduce the SUM DMO runtime by 30–50%.
- Archive FI, MM, SD, CO before SUM DMO run
- 30–50% reduction in migration runtime achievable
- Smaller HANA database post-migration = lower HANA sizing cost
- Begin archiving 3–6 months before migration cutover
HANA Memory Optimisation
SAP HANA stores data in memory — unlike traditional databases that read from disk on demand. Every gigabyte of active database data requires HANA memory. For organisations on RISE or GROW with SAP, HANA memory is directly linked to subscription cost. Reducing database size through archiving reduces the HANA memory sizing requirement — and the associated ongoing subscription cost.
- Analyse HANA memory consumption by table
- Identify highest-volume tables with archivable data
- Archive in volume order for maximum memory release
- Validate HANA memory reduction after each archiving cycle
GDPR & Data Protection Compliance
GDPR requires that personal data is not retained beyond its necessary purpose — but tax and legal requirements mandate retention for 7+ years. This conflict is resolved by ILM data blocking: the data is retained for compliance purposes but blocked from business processing. When retention expires, ILM manages controlled destruction with audit evidence. Archiving is the prerequisite that moves personal data to an ILM-managed store where blocking and destruction can be enforced.
- Personal data in customer masters, HR records, vendor contacts
- ILM blocking removes data from business processing
- Retention periods enforced — cannot be bypassed
- Destruction audit trail for data protection authority evidence
System Performance Improvement
Slow SAP reports and batch jobs are frequently caused by large table sizes — queries scanning millions of historical rows that are no longer operationally relevant. Archiving financial documents more than 7 years old, closed production orders, completed deliveries and old purchase orders removes historical data from the tables that every operational query scans — improving response times without any ABAP or index changes.
- Identify largest tables contributing to slow queries
- Archive historical data beyond operational relevance
- Measure query response time before and after archiving
- Combine with regular archiving schedule to maintain improvement
Five-phase archiving & ILM methodology
Data archiving has a specific sequence — resident time analysis, dependency checks, pilot run and production run must follow in order. Skipping steps creates archiving errors that are expensive to reverse.
Analysis
Table size analysis, archiving object identification, residence time assessment, data growth trend modelling
Configuration
Archiving object customising, residence times configured, archive store setup, variant and job scheduling defined
Pilot Run
Test archiving in development and QA — verify read programmes, predecessor checks, no orphaned records, business sign-off
Production Archiving
Scheduled production archiving runs — write phase followed by delete phase, database size measured before and after each run
Ongoing Schedule
Regular archiving schedule (monthly or quarterly) to prevent re-accumulation, ILM retention rules enforced automatically
What we measure before and after archiving
- Total database size (GB) before and after
- Individual table sizes — BKPF, BSEG, VBAK, EKKO, MSEG
- Archiving volume per object (documents archived)
- Query response time on key archiving-impacted transactions
- HANA memory consumption before and after
- Estimated SUM DMO runtime improvement (for migration scenarios)
Common mistakes we prevent
- Archiving data before the legal residence time has elapsed
- Running the delete phase before verifying the write phase
- Archiving with missing predecessor documents (orphaned data)
- No read programme tested before production archiving
- Archive store on the same server as the SAP database
- No ongoing schedule — data re-accumulates within 12 months
What makes our data archiving & ILM practice effective
Pre-Migration Archiving as a Standard Deliverable
For every ECC-to-S/4HANA migration engagement, we include a pre-migration archiving assessment as a standard activity — not an optional add-on. The assessment identifies the highest-volume archivable objects, estimates the SUM DMO runtime reduction and schedules archiving runs to complete before the migration window. Clients who skip this consistently encounter longer-than-expected SUM DMO runtimes.
Functional Knowledge of What's Safe to Archive
The decision to archive is not purely technical — it requires understanding which business processes still depend on data in the active database. A production order archived before settlement is complete creates a CO reconciliation error. An FI document archived while open items exist creates problems in AP/AR. Our functional consultants validate business process completion before archiving runs, not after.
Read Programme Verification Before Deletion
A non-negotiable step in our archiving methodology: every archiving object's read programme is tested and verified in QA before the delete phase runs in production. Users confirm they can access archived data through the standard transaction before we delete it from the active database. The archived data must be readable before the active record is removed — no exceptions.
ILM for Regulatory Compliance
We implement SAP ILM with retention rules mapped to actual legal requirements — statutory retention periods per jurisdiction (India: 8 years for financial records; sector-specific for pharma, financial services), GDPR data blocking for personal data, legal hold management and controlled destruction. ILM configuration is done with the legal requirements as the input, not generic best-practice defaults.
Ongoing Archiving Schedule — Not One-Time
A single archiving project reduces database size, but without an ongoing schedule the database returns to near its original size within 12–18 months. We design a recurring archiving schedule — monthly or quarterly per archiving object — and either execute it under our AMS engagement or hand over a documented schedule for client execution. The improvement is sustained, not reversed.
HANA Sizing Analysis — Cost Reduction
For clients on RISE or GROW with SAP, we model the HANA memory reduction achievable through archiving against the current HANA sizing and subscription cost. In many cases, archiving reduces the HANA memory requirement enough to move to a smaller HANA subscription tier — delivering ongoing annual savings that dwarf the archiving project cost.
SAP data archiving & ILM from a Gold Partner with 21 years of ERP data management experience
Our archiving practice spans pre-migration compression, HANA memory optimisation, regulatory ILM implementation and ongoing archiving schedule management — across manufacturing, pharma, distribution and FMCG landscapes.
SAP data archiving & ILM: frequently asked questions
What is SAP data archiving and how is it different from deleting data?
SAP data archiving moves completed documents from the active SAP database to a structured archive store — it does not delete them. Archived data remains readable via standard SAP programmes and reporting transactions; users can display and report archived FI documents, purchase orders, sales orders and production orders exactly as they can display active data. The difference is that archived data is no longer in the active database tables, so queries and transactions run faster and HANA requires less memory. Deletion, by contrast, permanently removes data — archiving is always the preferred approach for data that must be retained for legal or business reasons.
How long must we wait before we can archive SAP documents?
Each archiving object has a configured residence time — the minimum period a document must remain in the active database before it can be archived. For FI documents this is typically set at the legal retention requirement (7–10 years depending on jurisdiction); for production orders, after technical completion and settlement; for sales documents, after invoicing and payment clearing; for MM documents, after GR/IR clearing. Residence times are configured per client, not fixed SAP values — we set them based on your legal retention requirements and business process completion criteria.
Can we access archived data after it has been removed from the active database?
Yes — SAP provides read programmes and reporting transactions for every standard archiving object. Archived FI documents are displayable via FB03; archived MM documents via MB03; archived sales documents via VA03. Archive information systems (AS) provide cross-object archive queries. The archive store is queried transparently — users are typically unaware whether data is being read from the active database or the archive. The one limitation is that archived data cannot be changed — it is read-only, which is intentional for audit and compliance purposes.
What is SAP ILM and when do we need it versus standard archiving?
Standard SAP archiving manages where data is stored and provides read access to archived data — it does not manage retention periods, legal holds or data destruction. SAP ILM adds the compliance layer: retention rules that prevent data from being destroyed before its legal hold period expires, legal hold management for litigation freezes, GDPR data blocking for personal data no longer needed for its original purpose, and controlled data destruction with audit trail. ILM is needed when regulatory compliance (GDPR, GxP, financial regulation) requires documented retention management and evidence of controlled data destruction.
How much does archiving reduce database size in a typical SAP system?
Results vary significantly by industry, age of system and historical archiving activity. For a mature SAP ECC system that has never been archived, a comprehensive first archiving project typically reduces database size by 40–60%. The largest gains come from FI documents (BSEG is often the largest table in any SAP system), MM material documents (MSEG), SD billing documents (VBRK/VBRP) and CO line items. The exact reduction depends on which archiving objects are included and the age profile of the data — we model the expected reduction during the analysis phase before committing to a timeline.
Should we archive before migrating to S/4HANA?
Yes, if the migration timeline allows it — and planning should ensure it does. SUM DMO runtime is proportional to the data volume it must convert. A 40% database size reduction through pre-migration archiving typically translates to a proportional reduction in SUM DMO runtime and cutover window duration. For large ECC systems where the cutover window is a constraint, pre-migration archiving is not optional — it is the mechanism that makes the migration window achievable. Begin archiving 3–6 months before the target migration date to allow sufficient archiving volume before the SUM DMO dress rehearsal.
Want to know how much your SAP database can be reduced — and what that means for migration timing and HANA cost?
A data archiving assessment analyses your current table volumes, identifies the highest-impact archiving objects and models the database size reduction, SUM DMO runtime improvement and HANA memory saving achievable — giving you a business case for archiving before you commit the project budget.