What classic ADK archiving does
The Archive Development Kit provides the technical framework used by many SAP applications to archive business-complete data. An archiving object groups the relevant tables, programs and business context. Archive Administration—transaction SARA—offers the actions supported by that object. Not every object exposes the same actions.
The usual lifecycle has three controlled phases: write eligible objects into archive files, delete successfully archived objects from the database using those files, and store the archive files in the chosen repository. SAP allows storage before or after deletion depending on configuration. Historical access must be designed and tested before production removal.
Step 1: define scope and success before opening SARA
Write down the business process, organizational units, fiscal periods, candidate volume and reason for archiving. Name the business owner and technical owner. Define what “business complete” means and which downstream objects, reports, documents and interfaces depend on the records.
Step 2: identify and study the archiving object
In SARA, enter the candidate object and open its object-specific documentation. Review the available actions, programs, tables, preprocessing requirements and dependencies. Use system analysis to connect large tables to supported objects; never infer eligibility from table size or record age alone.
Confirm whether the object requires earlier objects to be archived first, whether attachments or linked documents follow a separate lifecycle, and whether reloading is supported. Record the relevant SAP Help pages and SAP Notes for your exact release.
Step 3: inspect object-specific customizing
From SARA, review Customizing. Typical settings include archive-file size or maximum objects per file, logical file path, storage-system connection and delete-program behavior. Pay particular attention to any setting that starts a deletion program automatically after the write phase.
Step 4: prepare access before removal
List how users currently retrieve the information: standard transactions, application reports, Archive Information System, custom reports, attachments and cross-object navigation. For Archive Information System access, check whether a suitable archive information structure exists. An activated information structure is normally populated during the delete run, though existing archives can also be filled later.
Create representative test cases: known document numbers, date ranges, organizational units, linked documents and totals. Capture expected results from the live database before archiving.
Step 5: build a narrow test variant
Choose a small, representative and business-approved dataset. Use the selection screen offered by the object’s write program. Give the variant a clear purpose and scope. Avoid overlapping variants and verify that the same data is not already present in archive files awaiting deletion; SAP warns that multiple archiving can produce incorrect results for some objects.
Use test or simulation modes where the object provides them. Review the application log for ineligible records and dependency failures. Treat exceptions as information about process completion—not as obstacles to bypass.
Step 6: schedule and monitor the write job
In SARA choose Write, select the approved variant, define the start and spool parameters, and schedule the background job. Monitor Job Overview and Logs. Verify that the run completed, archive files closed successfully and expected object counts and file sizes are plausible.
Do not equate “job finished” with “safe to delete.” Confirm file readability, storage behavior, counts and access prerequisites. Investigate interrupted sessions and unprocessed files before starting another overlapping write run.
Step 7: verify the archive and repository path
Use SARA management and storage views to confirm archive-file status. If a content repository or external storage system is configured, verify successful transfer and retrieval from the intended repository. Confirm backup, immutability, encryption, access control and recovery responsibilities with the storage owner.
Step 8: authorize and run controlled deletion
The delete program reads the archive files and removes the corresponding database records. Before scheduling it, verify that the write result is complete, the archive files are readable, required storage has succeeded, access tests are prepared, exceptions are understood and the change is approved.
Run a narrow deletion in non-production. Monitor logs and reconcile deleted objects to the successful archive population. Never delete source records using ad-hoc database operations; the object-specific delete program protects the lifecycle and consistency expected by ADK.
Step 9: prove retrieval and business usability
Execute the test cases captured earlier. Depending on the object, use the original application transaction, object-specific read program or Archive Explorer. Verify searches, document display, relationships, attachments, authorizations, reports and exports. Test with representative business roles—not only an administrator account.
If Archive Information System is used, confirm the intended information structure is active and populated. SAP notes that reloading archives does not automatically update available information structures, so reloaded-data procedures need separate attention.
Step 10: reconcile and operationalize
Compare pre-run candidates, written objects, deleted objects, retained exceptions, archive files and accessible test records. Business owners should accept the result. Turn the tested configuration into a runbook covering schedule, variants, monitoring, capacity, exceptions, recovery, evidence retention and periodic access testing.
Common mistakes
- Choosing candidates by age or table size without business-completion checks.
- Running overlapping variants while earlier archive files remain unprocessed.
- Discovering automatic deletion only after scheduling a production write.
- Testing technical file creation but not business retrieval.
- Ignoring documents, attachments, custom reports or dependent objects.
- Assuming archive files alone constitute a usable historical-data solution.