SAP BW Archiving Strategy: The Complete Guide to DAP, NLS, and ADK-Based Archiving

Every SAP BW system tells the same story eventually. Loads that once finished before breakfast now spill into the business day. Backup windows stretch. Queries on your largest InfoCubes crawl. And if you run BW on HANA, your infrastructure team keeps circling one line in the budget: memory.

The root cause is rarely mysterious. Business Warehouse systems accumulate years, often more than a decade of transactional history, and the vast majority of it is almost never queried.

Industry experience consistently shows that in a mature BW system, most reporting activity touches only the last two to three years of data. Everything older sits in your primary database which consumes space, memory, and money.

A well-designed SAP BW archiving strategy fixes this. Enterprise data archiving moves aged, rarely-used data out of your primary database into cheaper storage tiers while keeping it accessible for reporting and compliant with retention rules.

This guide covers the full picture for SAP BW 7.x / NetWeaver BW and BW on HANA: the concepts (data aging, data temperatures, DAP), the two archiving methods (ADK-based archiving and Near-Line Storage), a practical decision framework, plus the operational topics.

What Is a SAP BW Archiving Strategy?

An SAP BW data archiving strategy is the set of policies and processes that govern how aged data is moved out of your BW system’s primary database while remaining retrievable and compliant. It answers four questions for every InfoProvider that matters:

• What data qualifies as “cold” (which InfoProviders, which time slices)?
• When should it move (residence periods — how long does data stay “hot”)?
• Where should it go (ADK archive files, Near-Line Storage, or deletion)?
• How will it still be accessed (transparent query access, reload, or audit-only retrieval)?

A strategy is more than a one-time cleanup. Done properly; data archiving becomes a recurring, automated part of your data lifecycle, a monthly or quarterly process chain, not a heroic annual project.

Data Temperatures: Hot, Warm, and Cold Data in SAP BW

Modern SAP BW archiving and data aging strategies are built on the concept of data temperature:

Warm data: accessed occasionally, with relaxed performance expectations. On HANA, warm options include extension nodes or dynamic tiering, which keep data inside the HANA system but outside precious main memory.

Cold data: historical data that is rarely (or never) queried but must be retained for legal, fiscal, or occasional analytical reasons. Cold data is the target of archiving: it is physically moved out of the primary database into Near-Line Storage (NLS) or ADK archive files.

Also Read: What Is Cold Data Storage? The Guide Enterprises Need

Data Aging vs. Data Archiving: What’s the Difference?

The two terms get mixed up constantly, so let’s separate them:

Data aging / tiering manages where inside the database landscape data resides based on temperature — for example, displacing warm data from HANA memory to disk or an extension node. The data stays part of the database.

Data archiving physically relocates data out of the primary database via a Data Archiving Process (DAP) either to nearline storage (still query-accessible) or to ADK files (offline). The primary database genuinely shrinks.

For BW on HANA customers, this distinction is the heart of the business case: only true archiving removes data from HANA’s memory footprint which directly reduces the hardware and license capacity your HANA sizing must cover.

Why Archiving Pays Off: The Business Case

Before the technical detail, here is what a working archiving strategy actually buys you:

• Lower SAP HANA memory and license costs: Every gigabyte of cold data held in-memory is premium infrastructure spent on data nobody queries. Moving historical data to an SAP IQ Cold Store removes it from HANA’s memory footprint and stores it in compressed form, dramatically reducing demand on primary system resources.
• Faster queries and data loads: Smaller fact tables mean smaller indexes, faster aggregation, quicker DSO activation, and shorter change runs.
• Shorter backup, restore, and maintenance windows: Your backup only needs to cover the (much smaller) primary database; the archive tier is backed up separately and far less frequently.
• Cheaper, faster upgrades and migrations: Every terabyte you archive is a terabyte you don’t migrate. Organizations preparing a BW/4HANA conversion routinely archive first to shrink migration scope, runtime, and target sizing.
• Compliance without bloat: Legal and fiscal retention requirements (often 7–10+ years) are met in a low-cost tier instead of the production database.

The Building Blocks: DAP, ADK, and NLS Explained

SAP BW’s archiving architecture rests on three components. Understanding them is essential before you configure anything.

Data Archiving Process (DAP) in SAP Business Warehouse

The Data Archiving Process (DAP) is the central object of SAP BW InfoProvider archiving.

A DAP is attached to exactly one InfoProvider and defines the archiving method (ADK-based, nearline, or both), the time-slice characteristic used to cut the data into archivable segments, the semantic grouping of records for efficient later retrieval, and the technical connection to the destination — an archive file path for ADK or a nearline database connection for NLS.

When a DAP is activated, the system generates the required archiving objects in the background. The DAP concept was introduced with SAP NetWeaver BW 7.0, replacing the older, more limited archiving approach of BW 3.x.

ADK-Based Archiving

ADK-based archiving uses the classic Archive Development Kit, the same framework that powers ERP archiving. Data is written into compressed archive files, verified, and then deleted from the InfoProvider through a separate deletion step.

• Lowest cost — archive files sit on standard file storage, with no additional database required.
• Offline access — archived data is not available to BEx queries without a reload, making ADK best suited to compliance-driven retention where data must exist but is rarely read.
• Proven and license-free — no additional software license is required.

Near-Line Storage (NLS)

Near-Line Storage keeps archived data queryable. Data moves out of the primary database into a separate, cost-optimized columnar database — compressed and read-only, but still transparently accessible to BW queries.

SAP’s delivered nearline solution is SAP IQ (formerly Sybase IQ), often called the SAP IQ Cold Store. SAP IQ’s column-store compression routinely shrinks historical data to a fraction of its original footprint while keeping it available to BEx and analytic queries.

Archived time slices become locked and read-only, guaranteeing consistency between the online database and the nearline store. On BW on HANA, queries reach NLS data through HANA Smart Data Access (SDA) — archived data feeds standard HANA queries and calculation views without users knowing where it physically lives.

Note the supported scope: InfoCubes, classic DSOs, and advanced DSOs can go nearline; master data cannot.

Where BW/4HANA’s Data Tiering Optimization (DTO) Fits

If BW/4HANA is on your roadmap, this discipline evolves into Data Tiering Optimization (DTO), a unified framework where a DSO partitions are classified as hot, warm, or cold, and the system moves data between HANA memory, extension nodes, and cold stores accordingly. The strategic thinking you invest now on residence periods, time slicing, temperature classification — carries directly over.

Designing Your Archiving Strategy: A Six-Step Framework

Tools are the easy part. The strategy work is deciding what to archive, when, and where. Here is a framework that works in practice.

Step 1: Identify Candidates

You can’t archive what you haven’t measured. On BW on HANA, the SAP HANA SQL Statement Collection (SAP Note 1969700) provides scripts that rank tables by memory consumption and disk size — your archiving shortlist almost writes itself.

Complement this with usage data from BW statistics to see which InfoProviders and time slices are actually being queried. An InfoCube where 95% of query traffic hits the last 24 months but holds a decade of data is a textbook archiving candidate.

Read more: SAP S/4HANA Archiving Explained for Enterprise IT

Step 2: Classify Data by Business Usage and Retention Requirements

For each candidate InfoProvider, work with business and compliance stakeholders to establish two numbers: the residence period (how long data must stay hot for active reporting, typically 2–3 years) and the retention period (how long it must be kept at all — often 7–10 years or more for fiscal data).

The gap between those two numbers is your archive window.

Step 3: Choose the Method per InfoProvider

A simple decision rule covers most cases:

• Historical data still needed in reports (year-over-year comparisons, multi-year trend analysis, occasional audits with analytical access) → NLS. Users keep transparent query access; you keep the memory savings.
• Data retained purely for compliance, with essentially zero expected read access → ADK-based archiving. It’s the cheapest tier, and the lack of query access doesn’t hurt.

Some organizations combine both in one DAP: nearline for the mid-aged window, ADK for the truly ancient tail.

Step 4: Define Time Slices and Residence Periods

Choose the time characteristic that will slice the data like calendar month, fiscal period, or a request-based approach. This setting cannot be casually changed later, so choose deliberately. Prefer a characteristic that matches how the business talks about data age: “everything before FY2022.”

Step 5: Pilot, Simulate, Verify

Start with one mid-sized, low-risk InfoProvider. Run a simulation before any productive archiving to preview affected data volumes. Verify record counts before and after, run key queries with and without nearline access, and only then scale out.

Step 6: Operationalize

Fold archiving runs into automated process chains on a monthly or quarterly rhythm, define monitoring and alerting for failed requests, and review residence periods annually. An archiving strategy that runs manually will quietly stop running.

How SAP BW Archiving Works

The archiving process starts with the Data Archiving Process (DAP), the configuration object that turns your strategy decisions into automated action.

The DAP defines what gets archived, how the data is sliced by time, and which method applies. Once configured and activated, it generates the underlying archiving objects and connects to the destination, whether that’s an archive file path or a nearline database.

For ADK-based archiving, the system writes selected time slices into compressed archive files, verifies them, and then runs a separate deletion job to remove those records from the InfoProvider.

The two-stage design is intentional: it gives teams a window to confirm data integrity before anything is permanently removed from the primary database. Archive files can optionally be transferred to a connected content repository for long-term, tamper-resistant retention.

For Near-Line Storage, data moves to the SAP IQ columnar database through archiving requests managed directly on the InfoProvider. Once complete, the archived time slice is locked read-only and served transparently from NLS — BEx queries that include the nearline read flag return combined results from HANA and SAP IQ without users needing to do anything differently.

On BW on HANA, this federation happens through HANA Smart Data Access, meaning historical data can also feed native HANA analytics and calculation views without touching the original InfoProviders.

Whichever method you use, the process closes with verification — record counts before and after, query spot-checks, and confirmation that the expected memory or space reduction has materialized. Once a single InfoProvider runs cleanly end to end, the same pattern extends across your landscape and slots into automated process chains.

System Copy Handling with Archived Data: A Risk Most Teams Discover Too Late

System copies are where archiving strategies get quietly broken. When a production BW system is copied typically to refresh a QA or development environment, the copy inherits all the archiving metadata, including pointers to the production nearline store and archive file paths. If those connections aren’t addressed immediately, two things can go wrong.

First, teams discover that archived data is inaccessible in the copied environment: nearline connections are disabled automatically in the target as a safety measure, which is by design but is frequently absent from system-copy runbooks.

Second, and more seriously: if archiving jobs are allowed to run in the copied system before connections are repointed, they can delete or corrupt data in the production archive. This isn’t a theoretical risk but is documented in SAP KBA 2344235 and has caught organizations off guard after otherwise successful go-lives.

The fix is straightforward: treat archiving as an explicit checklist item in every system-copy procedure.

Nearline connections should be repointed to a non-production store or deliberately disabled in the target; archive file paths should be verified to ensure the copy isn’t sharing productive archive storage. Five minutes in a runbook prevents what can otherwise be a serious compliance or data-integrity incident.

Operational SAP BW Archiving Best Practices

A sustainable SAP BW archiving strategy lives or dies on operations:

• Automate via process chains. BW provides a process type for archiving, so recurring runs slot into your existing chains — schedule them off-peak, after loads complete.
• Separate write and delete in time. Keep the deletion step on hold until verification is routine; even then, prefer a deliberate gap between writing and deleting archived data.
• Back up the cold store. The nearline store holds production data — include it in your DR concept and back it up on a schedule consistent with your primary database recovery point objectives.
• Monitor request health. Failed or hanging archiving requests block subsequent loads into affected slices; alert on them like any critical chain step.
• Archive little and often. Monthly or quarterly slices keep runtimes short and risk low; big-bang annual archiving does the opposite.
• Review annually. Data volumes, query patterns, and retention laws change. Revisit residence periods, add new InfoProviders to scope, and confirm the sizing headroom you’re banking on.

ADK vs. NLS at a Glance

SAP BW 7.x, BW on HANA, and the Road Ahead

Release context shapes the strategy:

On any DB SAP BW 7.x / NetWeaver BW, the drivers are database size, load performance, and backup windows. Both ADK and NLS work; native SAP IQ NLS support begins with BW 7.3x, while certified partner nearline solutions extend coverage back to BW 7.0x.

On BW on HANA, the driver is memory economics — NLS becomes the strategic default for cold data, with HANA Smart Data Access providing query federation.

Looking forward, mainstream maintenance for SAP BW 7.x is ending — for most customers 2027, with extended options which makes BW/4HANA conversion planning the strategic frame.

Archiving before conversion is one of the highest-ROI preparation steps: less data means faster conversion runtime, smaller target sizing, and lower risk. Your NLS investment carries over into BW/4HANA’s Data Tiering Optimization, though partner nearline interfaces do not.

Beyond Native Tools: SAP BW Archiving with Archon ArchiveLink

Everything above works and for many landscapes, native NLS plus ADK is the right answer. But SAP-native archiving has structural limits that show up at scale:

• SAP IQ adds its own license, infrastructure, and administration footprint
• ADK archives are effectively dark data locked in proprietary files with no query access once they leave the primary system
• Retention and legal-hold management remain manual, spread across transactions
• When a legacy BW system reaches end of life, native archiving offers no path to decommission it without losing access to its history

This is where Archon ArchiveLink extends the strategy. Available on the SAP Store and built to work within the SAP ArchiveLink framework, Archon ArchiveLink archives SAP ECC and SAP BW / S/4HANA content, documents, and data to an independent, lakehouse-based repository reducing your active HANA footprint while keeping every record accessible, governed, and audit-ready.

Rather than replacing your DAP-based processes, it addresses the gaps native tooling leaves behind:

• Reduces HANA footprint without losing access to historical records. Archon ArchiveLink moves historical BW data and SAP-generated content like invoices, purchase orders, HR records, financial postings, print lists, and spool files — out of the live database into a secure external archive. The HANA footprint shrinks directly, and archived content remains retrievable through familiar SAP-style transaction screens with no live system dependency. Finance, audit, and compliance teams navigate historical records the same way they did before archiving, with no disruption to existing workflows.
• Works within the existing SAP ArchiveLink framework. Compatible with SAP’s native ArchiveLink interface, Archon ArchiveLink serves as the content repository for the archiving workflow — document linking, storage, and retrieval across SAP transactions continues unchanged. Finance, audit, and compliance teams access historical records the same way they did before archiving, with no disruption to existing workflows.
• Compliance enforced through policy, not process. Retention rules applied at data ingestion enforce hold periods automatically per document type and jurisdiction — purchase orders, HR records, and financial postings each follow their own schedule, from 7 years to 30 or more. A compliance dashboard provides centralized visibility into retention policies, legal holds, and disposition status, with audit-ready reporting built in. WORM immutability and tamper-evident storage ensure the archive is defensible if challenged.

• Enables full decommissioning of legacy BW systems. SAP BW 7.x systems often remain running years after a migration purely to serve audit queries against historical records. Archon ArchiveLink makes full system retirement possible, historical data stays retrievable through SAP-familiar screens without the original instance running, eliminating the infrastructure, licensing, and maintenance cost of keeping a decommissioned system alive.
• Extends SAP ILM for organizations already using it. Archon ArchiveLink offloads archived data, automates retention policies, and centralizes compliance controls — handling SAP BW content alongside documents and data from across the wider SAP landscape in a single governed archive.

In practice, the two approaches compose cleanly: keep hot and warm data in HANA, use NLS where transparent BEx query access to recent history is essential, and land long-tail retention, compliance archives, and decommissioned-system data in Archon ArchiveLink where it stays accessible, governed, and dramatically cheaper to keep.

Conclusion: From Cleanup Chore to Data Lifecycle Discipline

An effective SAP BW archiving strategy follows a repeatable arc: measure your largest and least-used data; classify it into hot, warm, and cold with business-agreed residence and retention periods; choose the right destination per InfoProvider — NLS for report-relevant history, ADK for compliance-only retention; configure the Data Archiving Process with clean time slices; execute carefully with verification built in; and operationalize it in automated process chains with monitoring and system-copy runbook entries.

The payoff compounds: lower HANA memory and license spend, faster loads and queries, shorter maintenance windows, and a dramatically lighter lift when the BW/4HANA conversion arrives.

And where native tooling reaches its limits — dark ADK archives, manual retention management, legacy systems that need to be switched off — Archon ArchiveLink closes the loop with governed, policy-driven archiving that keeps historical data accessible long after the source system is gone.