Decommissioning with retained records separates the end of application execution from the continuing use of its information. The archive must preserve the required population, its meaning, and an authorized retrieval path while the old service’s schedules, interfaces, identities, and infrastructure are removed.
This is a joint acceptance problem. An application can stop successfully while historical questions become unanswerable, or an archive can work while an overlooked consumer still requires the live service.
Define the questions the archive must answer
Record owners should identify retained populations, relationships, provenance, access roles, and the decisions governing retention. The required historical questions give those artifacts a practical scope.
For example, a constructed archive requirement might ask who approved an adjustment and which evidence supported it. Preserving the adjustment amount alone would not satisfy that question if the approval identity, code meanings, or attachment relationships were omitted.
Applicable retention obligations require their actual organizational and legal context. A generic extraction method does not supply a universal retention period or establish compliance by itself.
Package integrity is one deliverable
BagIt, specified in RFC 8493, defines a valid package through completeness and verified manifest checksums. Its payload contents are opaque byte sequences to that validation mechanism.
A valid package can therefore prove that listed artifacts are present and match their recorded checksums without proving that a user can interpret them. It also does not establish that the original content was authentic or factually correct.
The extraction record should identify its consistency point, formats, failed items, and exclusions. Integrity checking can then detect changes to the retained artifacts while other tests address their semantic completeness.
Preserve the interpretation layer
Schemas, code lists, relationship mappings, descriptive metadata, and a searchable catalogue can be necessary to interpret historical data. Some meanings can also depend on the version of a business rule used at the time.
US National Archives finding-aid requirements treat descriptive documentation as necessary to reference and retrieve accessioned records. That accessioning context supplies an example of retrieval support, not a universal legal rule for every archive.
An authorized user should rehearse real historical questions without using the retiring application. The exercise should verify that required attachments and relationships remain accessible and that denied writes and restricted access behave as intended.
Retirement needs business-cycle coverage
Before permanent removal, a controlled stop can expose dependencies while retaining a defined restart path. Monitoring should cover the cycles relevant to the service’s actual use.
AWS retirement guidance warns that a short observation period can miss monthly or quarterly batch dependencies. Silence during a week cannot establish that a year-end process no longer depends on the application.
Consumer confirmation and operational observation complement each other. A known seasonal use needs a disposition even if the controlled-stop window cannot conveniently include its next production occurrence.
Close the service and own what remains
After acceptance, the closure record should address schedules, interfaces, credentials, licenses, and infrastructure. Shared resources need separate evidence that other consumers no longer require them.
The archive itself becomes a retained service with an owner, access process, integrity checks, recovery method, and a way to maintain its descriptive material. Removing the original application does not remove those responsibilities.
Acceptance means required current work and historical retrieval succeed without the retired service. The final record should make the remaining archive and its dependencies visible so that future operators can recover and interpret the information after the migration team has left.