1 · Readiness
What must be true?
Use the ERP Decommissioning Readiness Checklist to identify the work.
Application decommissioning sign-off template
Application Shutdown Evidence Checklist
Assemble the proof, authorize the shutdown and record what was actually disabled, retained, transferred or destroyed when retiring a legacy application.
Decision principle: Do not approve shutdown from verbal assurance. Every material conclusion should identify its owner, evidence location, review status and any accepted exception.
2 · Acceptance
Does historical access work?
Use the Historical Reporting Acceptance-Test Template to prove user journeys.
3 · Authority
Is the proof sufficient to shut down?
This template records the evidence, approvals, execution and final disposition.
Executive decision page
Shutdown recommendation and decision.
Application / system ID: ______________________________
Business purpose: ___________________________________
Business owner: ____________________________________
Technical / service owner: __________________________
Environment(s) in scope: ____________________________
Replacement or historical-access service: __________
Proposed shutdown date and window: _________________
Evidence repository and pack version: ______________
Data classification / policy reference: _____________
| Recommended decision | Authorize / Authorize with conditions / Do not authorize |
|---|---|
| Evidence status | Accepted: ___ Accepted exception: ___ Missing: ___ Not applicable: ___ |
| Open critical blockers | ________________________________________________ |
| Accepted exceptions | ________________________________________________ |
| Earliest safe shutdown date | ________________________________________ |
| Post-shutdown user route | ____________________________________________ |
| Final decision owner | ________________________________________________ |
Stop the decision if: required historical information is materially missing; a critical dependency remains unresolved; reconciliation variances are unexplained; an applicable legal hold or lifecycle requirement is unresolved; recovery or fallback is untested; unauthorized access remains possible; or accountable approval is absent.
Master evidence register
Point every assertion to dated, reviewable proof.
Use one row per decision outcome. Store detailed artifacts in the controlled evidence repository and reference them here.
| ID | Decision area / required proof | Artifact and location | Owner / reviewer | Review date | Status / exception |
|---|---|---|---|---|---|
| EV-01 | Approved application boundary and accountable ownership | ________________ | ________________ | ________ | ________________ |
| EV-02 | Dependency inventory and owner-confirmed closure | ________________ | ________________ | ________ | ________________ |
| EV-03 | Approved historical data, documents and context scope | ________________ | ________________ | ________ | ________________ |
| EV-04 | Technical reconciliation and explained variances | ________________ | ________________ | ________ | ________________ |
| EV-05 | Business reporting and access acceptance | ________________ | ________________ | ________ | ________________ |
| EV-06 | Retention, privacy, legal-hold and disposition review | ________________ | ________________ | ________ | ________________ |
| EV-07 | Post-shutdown identity, authorization and audit approval | ________________ | ________________ | ________ | ________________ |
| EV-08 | Recovery, fallback and operational continuity proof | ________________ | ________________ | ________ | ________________ |
| EV-09 | Approved shutdown runbook, change and communications | ________________ | ________________ | ________ | ________________ |
| EV-10 | Contract, license, infrastructure and media disposition | ________________ | ________________ | ________ | ________________ |
Status values: Accepted · Accepted exception · Missing · Not applicable. “Accepted exception” requires a linked exception ID, accountable approver and expiry or next-review date.
Minimum evidence pack
Organize proof by decision risk.
Scope and ownership
Authoritative system boundary, environments, repositories, components and named decision owners.
Dependencies removed
Owner-confirmed closure or redirection of interfaces, feeds, schedules, identities, analytics and manual workarounds.
History preserved
Approved structured data, custom information, documents, relationships, metadata, exceptions and source identifiers.
Reconciliation and acceptance
Control totals, explained variances and accepted historical searches, reports, documents and exports.
Lifecycle and holds
Applicable retention rules, privacy decisions, legal-hold checks, authorized disposition and residual-copy treatment.
Security and continuity
Post-shutdown access, privileged-account treatment, logging, recovery proof, fallback window and support route.
Contracts and infrastructure
Disposition for licenses, vendors, hosting, certificates, storage, backups, cloud resources, devices and media.
Execution and communication
Approved change, runbook, command ownership, escalation, user notice and timestamped completion evidence.
Dependency closure register
Confirm that nothing still depends on the old application.
| ID / type | Provider or source | Consumer / owner | Required action | Closure evidence | Status / risk |
|---|---|---|---|---|---|
| DP-___ | ________________ | ________________ | ________________ | ________________ | ________________ |
| DP-___ | ________________ | ________________ | ________________ | ________________ | ________________ |
| DP-___ | ________________ | ________________ | ________________ | ________________ | ________________ |
| DP-___ | ________________ | ________________ | ________________ | ________________ | ________________ |
| DP-___ | ________________ | ________________ | ________________ | ________________ | ________________ |
Review inbound and outbound interfaces, APIs, file transfers, batch schedules, reporting feeds, identity services, monitoring, backup jobs, content repositories, downstream analytics and manual processes.
Exception and residual-risk register
Make every condition explicit and time-bound.
| ID / related evidence | Issue and impact | Compensating control | Owner / due date | Approver / date | Closure evidence |
|---|---|---|---|---|---|
| EX-___ | ________________ | ________________ | ________________ | ________________ | ________________ |
| EX-___ | ________________ | ________________ | ________________ | ________________ | ________________ |
| EX-___ | ________________ | ________________ | ________________ | ________________ | ________________ |
Gate A · Before shutdown
Authorization to execute the shutdown.
- Mandatory evidence is accepted or has explicitly approved treatment.
- No unresolved issue materially compromises required access, preservation, security, reconciliation, recovery or continuity.
- The shutdown runbook, fallback decision, commander, executor and approved window are recorded.
- Communications, escalation routes and post-shutdown support are ready.
Decision: Authorize / Authorize with conditions / Do not authorize
Conditions: __________________________________________
Authorization expires: _______________________________
Business owner: ____________________ Date: ________
Records / legal / privacy reviewer, as applicable: __________
Security / control owner: ___________ Date: ________
Technical / service owner: __________ Date: ________
Executive decision owner: ___________ Date: ________
Reauthorize if execution falls outside the approved window or a material change affects scope, evidence, dependencies, controls or risk.
Execution record
Record what happened during shutdown.
Change / ticket reference: _____________________________
Actual start and end time: ____________________________
Commander, executor and witness: ______________________
Components stopped or access disabled: _______________
Interfaces, jobs and accounts disabled: ______________
Backup / snapshot / fallback state: ___________________
Post-action verification performed: ___________________
Unexpected events: __________________________________
Rollback invoked: Yes / No Reference: _________
Communications issued: _______________________________
Execution evidence IDs: ______________________________
Gate B · After shutdown
Completion and disposition confirmation.
- The legacy application is no longer available for normal business use.
- Required historical access remains available and priority checks still pass.
- Monitoring shows no unresolved dependent activity, and privileged or service access was removed or transferred.
- Infrastructure, storage, backups and media have a documented retain, transfer or destroy decision.
- Licenses and vendor services were terminated, reassigned or intentionally retained.
- Configuration, runbooks, audit evidence, residual copies and future review or destruction dates are recorded.
Final outcome: Completed and closed / Completed with post-shutdown actions / Reversed or not completed
Post-shutdown actions and owners: ______________________
Evidence-pack retention location: _____________________
Next review / residual-copy date: _____________________
Final owner: _______________________ Date: ________
Independent reviewer: ______________ Date: ________
Related decision tools
Build the evidence before asking for authority.
ERP Decommissioning Readiness Checklist
Identify the work that must be complete before retirement.
Use the readiness checklist →Historical Reporting Acceptance Test
Prove that required historical access works for representative users.
Use the test template →S/4HANA Historical-Data Matrix
Classify information for migration, archiving, independent preservation or disposition.
Use the decision matrix →Review one application’s shutdown evidence with ArchiveHub.
Bring your current evidence pack, open exceptions and target shutdown date. We can help identify missing proof and structure the decision gate.
Scope note: This template supports application-decommissioning governance. Adapt it to the organization’s change, records, privacy, security, continuity, financial and infrastructure policies. It is not legal advice and does not guarantee that shutdown is appropriate for a specific environment.