Legacy platform decommissioning evidence checklist

Gathered read-only from the platform itself, not from memory or old documents.

• Sessions, applications, connections, service accounts and data paths are inventoried.
• File shares and DFS paths that resolve through the platform are listed.
• Scheduled tasks and scripts running on or against the platform are captured.
• Service accounts created for the platform are traced to everywhere they are reused.Accounts outlive platforms. Reuse is where retirements break other systems.

• Real usage is observed over a window that covers month-end and quarter-end processing.A quiet fortnight proves nothing. Seasonal and batch work hides.
• Every login and connection in the window is attributed to a person, a team or a system.
• Apparent idleness is tested: batch, failover and break-glass roles are checked explicitly.

• Every dependency has a named owner.
• Every dependency has a written decision: migrate, replace, retire, or accept the loss.
• Accepted losses are signed by someone entitled to accept them.Acceptance by silence is not acceptance.
• Stubborn dependencies have a senior owner and a written residual risk, not a whispered one.

• Reduction stages are defined: observe, restrict, pause, switch off.
• Each stage has a checkpoint and a fast way back.Anything missed should announce itself while the platform can still be restored.
• Restore has been exercised at least once before the pause stage.
• The stage schedule respects month-end, quarter-end and known busy periods.

• The switch-off approval records who approved it, when, and what was checked.
• Monitoring confirms nothing is still calling the platform before removal.
• Licences, hardware and support contracts are released only after the agreed retention period.

The deliverable. Everything above, retained together.

• Inventory, usage record, dependency map and decision log are stored as one pack.
• Every sign-off and accepted loss is in the pack.
• The pack has an owner and lives where audit can find it.
• A successor could reconstruct what was retired, what replaced it and who agreed.That sentence is the test of the whole exercise.

Do not count the ticks. Read where the gaps sit: each section is a gate, and each gate failing means something different.

• InventoryGaps here mean the platform boundary is unclear: nobody can say precisely what the switch-off would switch off.
• Usage evidenceGaps here mean the observation window has not proved enough. Quiet is not the same as unused.
• Dependency decisionsGaps here mean the switch-off is still speculative, however confident the date in the plan.
• Staged reductionGaps here mean anything missed cannot surface safely, because there is no staged way back to offer it.
• Switch-off recordGaps here mean the action is not attributable: nobody can show who approved what, or when.
• The evidence packGaps here mean the retirement is not yet complete as a governed change, whatever the power state of the hardware.

A powered-off platform without its evidence pack is an outage waiting to be misunderstood, not a completed retirement.