SAP archiving before S/4HANA

Archiving SAP ECC 6.0 data before a move to S/4HANA shrinks the database that has to be converted, which cuts cost, risk and downtime, while keeping every record available to the people and auditors who still need it.

The timing is not optional. SAP ends mainstream maintenance for ECC 6.0 in December 2027, with paid extended maintenance only through 2030. And because S/4HANA runs on an in-memory database, every gigabyte carried forward consumes premium resources. Database size drives the running cost of the new system, not just the effort of the move.

The instinct to keep everything is where these projects go wrong. Varmoda’s SAP teams separate two decisions: what active data to carry into S/4HANA, and what history to keep in an accessible, compliant store. SAP provides the means to do both, so archived never has to mean lost.

Why archive before the move

• The clock. Mainstream maintenance for ECC 6.0 ends in December 2027, with paid extended maintenance through 2030. S/4HANA is committed to maintenance into 2040. Waiting narrows the options and raises the price of all of them.
• The economics. Data sits in memory, so volume carried forward drives licensing and infrastructure cost for the life of the system. Trimming before conversion lowers the recurring bill, not only the one-off migration effort.
• The mechanics. A smaller database converts faster, with shorter downtime and a smaller, cheaper set of test systems to build. Migrations consistently run faster when archiving is done first.
• The data quality. Archiving clears closed, aged and duplicate records, so the project converts a lean, relevant dataset rather than carrying years of obsolete records into a new platform.

How SAP archiving actually works

Archiving is a controlled lifecycle process, not a backup. It removes data from the live database and writes it to retrievable files, governed so that nothing is deleted until it has been safely stored.

Data is archived by business object, and each object knows its own tables and dependencies.

The phases run in a fixed order. Write reads qualifying data into archive files. Store moves those files to a repository. Delete removes the rows from the database, and only the records verified as successfully written. That sequence is what makes archiving safe.

Two timings are set per object, with the business, and they are different decisions. Residence time is how long data must stay in the live database before it can be archived. Retention time is how long it must be kept once archived.

Before any of this, a data volume analysis shows where the volume actually sits, which objects can be archived, and what reduction to expect. It is the planning backbone for the whole program.

Keeping the archive available

The fear that stops most archiving programs is that the history will no longer be visible. That fear is misplaced, but only if access is engineered before anything is deleted.

• The Archive Information System. Searchable indexes built over the archive files so users can find and display archived records quickly. Think of it as a catalog laid over the archive, designed around the searches users actually run.
• Standard read and display. Most archive objects ship with read programs, and many standard transactions are archive-aware. Displaying a financial document, for instance, reads from the archive transparently when the record is no longer live. The user barely notices.
• Document Relationship Browser. Follows the flow from order to delivery to invoice across both live and archived data, so relationships stay intact even when parts have been archived.
• ArchiveLink. Keeps attached content, such as scanned invoices and forms, linked to the business object and retrievable.

Retention and compliance

Where the goal is not just space but retention and compliance, SAP Information Lifecycle Management governs how long data lives, when it may be destroyed and when it must be preserved.

• Retention rules. Policy-based rules set retention and expiry per object and condition, so legal periods are enforced automatically rather than tracked by hand.
• Legal holds. Destruction can be suspended for data under audit or litigation and released when the hold lifts, which archiving alone cannot do.
• Storage that enforces the rules. Archived data carries its expiry date with it, and premature deletion is blocked.
• Both questions answered. Can this be deleted yet, and can it still be produced on request. That dual control matters where data-minimization rules sit alongside multi-year retention mandates.

One qualification: this capability is powerful but adds complexity and ongoing licensing, and it governs SAP data specifically. For many organizations it is the right backbone. For others it is one option among several.

Where legacy data should live

Not all ECC data needs to live in S/4HANA. The skill is matching each category of data to the right home, and most organizations use more than one of these.

A common pattern combines all three: migrate the active data, archive what has aged, and decommission the old system to a retention store, so the organization stops paying to run software that is reaching end of life while staying fully audit-ready.

How to run the program

This is a disciplined sequence run with the business, not an IT clean-up done on the side.

• Start with the analysis. Archive where the volume and the savings actually are, not where it is easiest.
• Take the easy volume first. Interface documents, application logs and change documents give quick wins, then move to the large transactional objects.
• Respect the dependencies. Archive in the right order so related records are never orphaned.
• Set the timings with legal and business owners. These are compliance decisions, not IT guesses.
• Build retrieval before deleting. Stand up the indexes and confirm access for every data set users must still see.
• Test and verify. Write, store, verify, then delete. Never delete unverified data.
• Schedule carefully. Run write and delete in quiet windows and watch database and job performance.
• Govern it. Document the rules, retention and access paths so the program survives both the migration and any audit.

How Varmoda delivers

Varmoda treats pre-migration archiving as what it is: the step that makes the S/4HANA move smaller, cheaper and safer, with no loss of access to data the organization still depends on.

Varmoda’s SAP practice works across the stack the migration actually touches, including S/4HANA, Solution Manager, ChaRM and Cloud ALM, so archiving is planned as part of the conversion rather than bolted on afterwards.

The legacy data decisions are made explicit, carry forward, retain or decommission. Retention is set with the client’s legal and business owners. And the retrieval paths are stood up so users and auditors never lose the history. Delivery is United States led and the data is handled securely throughout.

War Mode here means planning the data before the migration, so the conversion runs lean and the record stays one click away. The organizations that move well decide what to keep, keep it accessible, and stop paying to run software that is reaching end of life.