How SAP archiving automation actually works: automating SAP data archiving with ASC

09 November 2026 | 11 min | SAP Data Archiving, SAP Data Management

Introduction

SAP Data Archiving uses archiving objects to write eligible historical business data to archive files and then remove that successfully archived data from the live database. SAP itself recommends Data Volume Management ahead of an S/4HANA conversion because a smaller data footprint can reduce the load processed during conversion and lower the memory requirements of the target system.

The difficult part is keeping that process running consistently. An SAP archiving session is not simply one background job. Depending on the archiving object, it can involve pre-processing jobs, variant creation, the WRITE step, a storage phase, database deletion, post-processing, dependencies between objects, restricted batch windows, monitoring, and recovery when jobs fail. The Archiving Sessions Cockpit (ASC) automates this orchestration around SAP’s standard archiving rules. Once the archiving strategy is configured, the ASC selects the sessions that are due, creates the required variants, sequences jobs, controls parallel processing while respecting prohibited periods, and restarts any interrupted sessions.

The result is archiving automation that turns a repetitive SAP Basis task into a controlled, continuous process with a very clear goal: keep HANA database growth under control.

Why SAP database growth becomes a technical problem

SAP databases continuously accumulate transactional and technical data. For SAP Basis teams and S/4HANA administrators, the issue is not simply that storage is getting expensive. It is all the side effects that accompany unchecked growth: degraded system performance, longer backup and restore processes, extended system copies and refreshes, pressure on maintenance and migration windows, and batch or reporting workloads reading large volumes of historic data.

Consider a practical example from one of our customers. Their Service Desk noticed an increasing number of tickets reporting that a critical Z report was running slowly. On investigation, the report was reading very large tables containing over 10 years of historic data, when only the last 5 years were relevant. After adding an archiving object to the ASC and archiving those 5 years of surplus data, the table size was reduced by over 50%, and the report ran significantly faster.

In S/4HANA, SAP’s Data Volume Efficiency tooling identifies database growth, memory consumption, top-consuming tables, and outdated data that may be candidates for archiving. Yet these tools identify the problem; they do not solve it on their own. Data volume management is an ongoing technical discipline, not a one-off pre-migration exercise.

Why manual SAP Data Archiving often fails to keep pace

The problem is not that SAP archiving does not work manually. It does. The problem is operating it continuously at scale. SAP standard archiving uses archiving objects and SARA/ADK principles, but behind each archiving session there are many invisible jobs.

Before running an archive session, teams must:

  • Determine the period and data eligible for archiving.
  • Select the company code, country, organisational unit, or document type scope.
  • Create and check variants.
  • Define residence times and archiving depth.
  • Consider object dependencies and configure them.
  • Decide on available servers/processes and work around month-end, financial close, and other restricted periods.

During the session:

  • Archiving windows are often limited to nights and weekends to protect production resources.
  • If an overnight job fails and nobody sees it until morning, much of the available window is lost.
  • Teams frequently launch jobs, return the next morning, inspect cancellations, and rerun failed work.

After the session:

  • Check jobs and identify errors.
  • Restart or reprocess failed sessions.
  • Verify which sessions completed successfully.
  • Calculate archiving results and the archive ratio, and document the session.
  • Prepare the following period.

This is why archiving automation is more than putting a recurring SARA job into a scheduler. It involves automating the creation of hundreds of variants, automatically restarting jobs that were interrupted, and defining approval workflows so that data governance and compliance are enforced.

Real-world example: from quick wins to automated archiving at Diversey

Diversey Ltd (now part of the Solenis Group) is one of the world’s leading providers of cleaning and hygiene products. Due to its large customer base and incredible diversity of product lines, Diversey had reached a point where its SAP ERP data in storage had become too vast. Its two production SAP systems contained 43.6 TB of data and were growing by around 0.7 TB per month per system.

Following an initial assessment by TJC Group, Diversey began implementing the recommendations and quick wins identified in the analysis. The first archiving phase focused on technical objects and removed 27.6 TB from the wider landscape. However, because new business data continued to accumulate during the project, the net reduction was closer to 21.4 TB. This highlighted an important reality: even after a successful clean-up, SAP databases continue to grow, so archiving needs to become an ongoing process.

Diversey initially considered maintaining the process by scheduling the recurring archiving jobs itself. But the team soon realised how much ongoing time and human effort this would require. A Senior Delivery Manager at Diversey explained at UKISUG Connect 2023 that the initial quick-win phase required significant attention from the SAP Basis team and competed with other priorities:

This led Diversey to implement the Archiving Sessions Cockpit (ASC) to automate the recurring data archiving processes. During the later ramp-up, the company archived around 120 million documents between October and December 2022.

The lesson is simple: one-off archiving can reduce the database, but automation is what helps keep data growth under control over time.

What does “SAP archiving automation” actually mean?

A generic job scheduler can launch a program at a specified time, but it does not have the capacity to understand object dependencies, data retention constraints, or any business logic. While conventional job schedulers can manage execution times and dependencies, they do not inherently account for the archiving-specific rules, selection criteria, and operational requirements of SAP data management. It lacks the intelligence and context required to manage the full complexity of SAP data archiving.   

Effective data archiving automation must also understand what data needs to be archived first, for which region or company code, when it is eligible, with which selection criteria, and what to do next if something fails. 

The ASC embeds business logic specific to SAP data archiving. It understands archiving object dependencies, organisational granularity, retention and residence times, and ILM and destruction constraints. This translates into three core functions: 

  1. Select archiving and/or destruction sessions that need to be processed. 
  1. Create the variants required by the relevant SAP programs. 
  1. Schedule and manage all jobs making up the complete session. 

Why variant creation is critical

Variant creation is arguably the most underestimated aspect of productive data archiving. The quality and granularity of your variants directly affects archive file organisation, data accessibility, runtime performance, and your ability to handle organisational changes such as system splits or company divestments.

If you archive 15 objects across 10 company codes on a monthly basis, that is 150 variants per month, or 1,800 per year. With a job scheduler, each variant must be created manually, verified, and linked to the correct job definition. A mistyped fiscal period, an omitted company code, or an incorrect date range can result in business users losing access to recent data. Because many archiving objects do not support a reload option, these errors can be irreversible.

The ASC automatically generates all required variants based on its configuration, and populates archiving session notes using a standard naming convention. Whether you need 24 archiving runs per year for a single object or hundreds of runs across dozens of objects, the ASC handles the complexity without additional effort.

For a detailed technical comparison, see our article:

How SAP archiving automation works with ASC, step by step

The ASC manages archiving sessions through three main fields: Objects, Areas, and Options.

  • Object defines the SAP archiving object to run.
  • Area is a logical grouping of organisational entities (company codes, plants, sales organisations, or controlling areas) used to define the scope of archiving variants.
  • Option defines different management rules for a given object and area, such as different rules depending on document types, or different residence times.

Together, these determine the frequency of execution, residence time, retention time, applicable information structures, and the document types to include or exclude. This is particularly valuable in international or multi-company environments where retention requirements vary significantly.

Step 1: Define the archiving rules once

Configure the object, frequency, residence time, archiving depth, area, option, permitted periods, technical limits, and dependencies. Automation starts with good archiving design; it does not remove the need to understand business data and retention rules.

Step 2: Determine what is due to run

At execution time, ASC identifies eligible sessions according to the configuration. Delayed sessions are included and sessions are processed chronologically. The administrator does not have to reconstruct every monthly to-do list manually.

Step 3: Generate the variants

ASC dynamically creates the required variants based on the configured rules. Examples of granular selection include: company code, country, fiscal year or period, document type, organisational entity, and date range. The variants remain inspectable, supporting transparency and troubleshooting.

Step 4: Orchestrate the complete SAP job chain

Depending on the object and configuration, the ASC manages user pre-processing, SAP/ADK pre-processing, the WRITE step, ADK file backup, storage, the DELETE step, post-processing, Archive Information Structure unloading, and reporting. An archiving session is a managed chain, not a single background job.

Step 5: Respect dependencies

Object B should not run simply because its calendar says it is due if object A must be archived first. A classic example: SD deliveries (RV_LIKP) must be archived before sales orders (SD_VBAK). The ASC supports relationships so predecessor processing can be completed before dependent objects proceed. Dependencies are defined once and enforced automatically, including across SAP systems.

Step 6: Deal with interruptions

Interrupted jobs can be restarted according to configured limits. Pending steps continue when the required storage or service becomes available. The ASC will not start a deletion job until the corresponding archive file backup has completed successfully, guaranteeing data security.

Step 7: Continue with the next eligible session

The result is not merely one successful archive; it is a managed queue that keeps progressing through due sessions within the capacity and windows the organisation permits, delivering higher and more consistent archiving throughput.

Automation without losing control of production

A common objection from SAP Basis teams is: “I do not want something automatically consuming production resources or archiving the wrong data.” This is a valid concern, and good archiving automation removes repetitive intervention without removing governance.

Prohibited dates and time slots

The ASC allows you to define prohibited days, dates, and time slots to prevent archiving during financial close, Black Friday, product launches, or other peak periods. Once the date passes, archiving restarts automatically with no user interaction.

Limit parallel processing

If an organisation has 20 objects due but permits only three in parallel, the ASC works through the queue three at a time rather than launching all 20 or manually scheduling successive groups.

Separate processing phases

The WRITE step can take place during the week, and the DELETE step (which physically removes data from the database) can be configured to run at the weekend, aligning different phases with different technical windows.

Stop one object without stopping everything

Temporarily pause MM_EKKO during a heavy purchasing period while other permitted objects continue. The start/stop feature allows precise control without affecting the broader schedule.

Simulation before execution

Simulation previews which sessions and variants would be created before the actual run, giving teams visibility and confidence.

Approvals where human validation is necessary

An approval workflow can hold processing until required recipients approve it, for example before a new fiscal period or where prerequisites such as DART extraction must be confirmed.

Seamless deployment

The ASC is an SAP add-on solution delivered as a standard SAP transport request. It is installed using STMS and delivered within TJC Group’s dedicated SAP namespace (/TJC/), preventing naming conflicts. The ASC is certified for deployment on SAP S/4HANA Cloud, Private Edition (release 2023) and operates fully within RISE with SAP landscapes. It has been recertified year after year for over two decades, used by over 400 SAP teams worldwide.

Where archiving automation makes the biggest difference

Save money on S/4HANA migration by reducing data volume

There is a significant opportunity to reduce S/4HANA migration costs by reducing the data volume that needs to be migrated. SAP Data Volume Management guidance states that reducing the data footprint before an S/4HANA move can shorten the migration times and lower HANA memory requirements in the target system. An initial assessment by TJC Group reveals the biggest tables, maps them to the relevant archiving objects, and prioritises the areas that will deliver quick wins. Automating archiving jobs adds an extra layer and accelerates the volume reduction. 

For guidance on what data should be migrated, archived, or retained outside SAP, read: SAP ECC to S/4HANA: What data should be migrated? 

BT Group: reducing the footprint on the journey to S/4HANA

As part of its S/4HANA transformation, BT Group combined SAP Data Archiving with automation to keep long-term data growth under control. At its peak, the relevant data volume reached 12.5 TB; following the archiving programme, it was reduced to 8 TB. BT also automated recurring archiving activities with the ASC to reduce the manual support needed to keep the process running.

Savings on HANA memory once you are on S/4HANA

After migration, the database will continue to grow. A Data Archiving programme in the new S/4HANA system monitors HANA memory growth and ensures the database size stays within the contracted T-shirt size. Avoiding a scale-up to the next tier prevents significant additional costs. SAP’s Data Volume Efficiency dashboard helps monitor growth, and TJC Group supports clients with monthly reports summarising data volume savings for each SAP system. Data archiving is considerably more cost-effective than expanding HANA memory.

What still requires SAP expertise after automation?

No tool can decide what is best for your organisation’s goals, retention policies, and infrastructure. Your team is best placed to assess the following:

  • Legal retention obligations per country and industry.
  • Whether business users still require certain data online.
  • Whether custom reports can correctly access archived data.
  • The appropriate residence periods for each archiving object.
  • The right objects to prioritise based on volume and business impact.
  • Audit or legal-hold exceptions that may temporarily block archiving.

When putting a data archiving programme in place, TJC Group teams spend a great deal of time understanding business rules, eligible data, permitted windows, and operational constraints. This includes close collaboration between teams, and workshops with Finance, Controlling, Tax, and IT departments to understand their needs and reassure them that no data will be lost.

Before moving to production, testing in a sandbox environment and validating normal operational activities and archive access remains essential. We demonstrate that archived data remains accessible, easily retrievable for display purposes, and fit for business-as-usual activity.

The ASC removes the burden of the manual jobs: creating variants, watching jobs, manually restarting failed jobs, and setting up object dependencies. The human expertise defines what to archive and why; the ASC handles how and when, consistently and at scale.

Conclusion: from periodic clean-up to continuous data volume management

SAP Data Archiving is the mechanism for moving eligible historic data out of the online database. When treated as a one-off project, the benefits are diluted over time as the database keeps growing. It is a very manual process that can easily consume the time of one or two people. Automation takes away that burden, makes the process repeatable, governed, and far more efficient.

Here are the key recommendations:

  • Before S/4HANA migration, review your business reporting requirements and assess what data can be archived before the move. Reducing the data footprint translates directly into shorter conversion times and lower HANA memory costs.
  • After the go-live, continue archiving to control future growth on HANA memory. Avoid scaling up to a higher tier to prevent unnecessary costs. Data archiving is considerably more cost-effective than expanding HANA memory needs.
  • Bring in the Archiving Sessions Cockpit to turn your archiving strategy into recurring, automated execution. Configure once, automate always.
  • Engage specialist expertise. TJC Group, with over 25 years of experience in SAP data archiving and ILM, provides the analysis, implementation, and ongoing services to ensure your archiving programme delivers measurable and sustained results.

If your SAP database is growing faster than your current archiving programme can reduce it, get in touch with TJC Group for a free initial assessment. We will analyse the largest tables, review the current archiving programme (if one is in place), and identify the gains.

Frequently asked questions

Q1. Can SAP data archiving be fully automated?

Answer:

Yes. Many recurring SAP data archiving activities, including variant creation, job scheduling, execution monitoring, and recovery, can be automated. However, organisations still need SAP expertise to establish appropriate archiving rules, residence periods, business requirements, and retention policies.

Q2. What is the difference between SAP SARA and ASC?

Answer:

SAP SARA is the standard transaction used to administer data archiving processes. TJC Group’s Archiving Sessions Cockpit (ASC) works with SAP’s standard archiving mechanisms to automate recurring operational activities, including session selection, variant creation, job coordination and monitoring. ASC does not replace SAP archiving objects. 

Q3. Can automated SAP archiving reduce S/4HANA migration costs?

Answer:

Yes, depending on the migration approach. Archiving eligible historical data before a brownfield conversion can reduce the source database footprint, potentially lowering data processing requirements, conversion duration and target HANA memory needs. The benefits depend on the existing data volumes and transformation strategy.

Q4. What happens when an automated SAP archiving job fails?

Answer:

An archiving automation solution such as ASC can manage interrupted sessions and restart eligible processing according to configured rules and limits. This reduces the need for administrators to manually monitor and restart every failed job, particularly during overnight or weekend processing windows. 

Q5. Does SAP archiving automation improve system performance?

Answer:

It can improve performance when excessive historical data contributes to large database tables or inefficient workloads. However, the outcome depends on the application, queries and infrastructure. Organisations should measure results using database reduction, processing times and relevant system performance indicators.