Prototypes get killed. Systems get transferred. Transferred systems eventually get retired — by a team that did not build them, using documentation written for a handover that happened years earlier, against a dependency map nobody has refreshed since.
It is the least-instrumented stage in the lifecycle and the one where the original evidence trail is worth the most. It is also the one nobody funds.
Everything degrades between transfer and retirement
Four things erode in parallel, and each is documented as its own problem while the combination is not.
Behaviour drifts. Operating conditions, inputs, users, and business processes change relative to the accepted assumptions. Input-data quality monitoring against a baseline and model-quality monitoring that joins predictions with outcome labels are separate instruments answering separate questions, and both need an owner after project governance ends.
Dependencies rot. Libraries, runtimes, APIs, models, and support arrangements move on their own schedules. A model retirement is a dated event; a version lock records an intention.
People leave. Knowledge, access, authority, and sponsorship are four functions that can sit with four different people, and one-to-one role transfer is frequently impossible. A service whose engineers can deploy and recover it, while the renewal decision has no assigned budget owner, has a governance gap that no technical assessment will surface.
Measurement stops. The question of whether the measurement itself still runs, and whether missing outcomes could conceal deterioration, is the one that goes unasked. A clean dashboard is consistent with a monitor that stopped reporting.
Continued evidence gathering and an updated economic model through live operation are the intended practice. The gap between that and what happens is where the retirement decision loses its inputs.
The decision, when it arrives
Retirement is the planned end of a system that previously entered accepted operation, and the initial successful transfer does not settle when later operation should end.
Loss of user need, or a lack of cost effectiveness in the current form, are both sufficient grounds. Neither requires the system to have failed.
The appraisal compares upgrade, narrower service, replacement, and retirement over a stated horizon using future resources and risks. Past accountability is preserved and past spending is not a reason to continue — and neither age alone nor accumulated investment establishes the answer.
Execution is where it goes wrong
The mapping comes first: users, integrations, records, and downstream obligations. What must migrate, what must remain accessible, and what is retained under a specific basis.
Dependency owners need time and information to act, and an announcement is not evidence that they migrated. Retirement guidance asks specifically about the time required to change API integrations, which is the dependency most likely to be discovered by breaking it.
A fallback has to remain feasible and authorised. It does not survive destructive data changes or provider retirement, so assuming one exists at cutover is the assumption that fails hardest.
And two obligations stay separate. A service with an accepted replacement, one downstream team still on the old API, and records under a documented retention requirement resolves the integration and arranges restricted record access before final shutdown. Keeping required records does not mean leaving the application operating. Turning the application off does not establish that records were lawfully disposed of.
Shutdown is not one action
Technical decommissioning ends authorised operation and resolves or explicitly assigns the remaining responsibilities. Issuing a shutdown command does neither.
Charges persist for documented reasons: prior usage, continuing reservations or subscriptions, storage surviving compute termination, resources in disabled regions. Deleting a volume does not automatically delete its snapshots.
So the sequence is an inventory — accounts, regions, workloads, schedulers, queues, webhooks, integrations, identities, secrets, domains, certificates, telemetry, paid commitments — including resources created by controllers or third-party services, and identifying shared infrastructure before changing it.
Then: disable new entry paths, handle queued and in-flight work under a declared drain or cancel plan, and confirm downstream effects separately. Stopping a worker does not reverse an action already accepted elsewhere.
Then: retire resources in a tested dependency order, revoke identities without interrupting unrelated systems, and assess already-issued sessions and external copies. Verify from the control plane, an authorised access check, and activity records — because a silent log with uncertain coverage is not evidence of inactivity.
Then: reconcile post-closure usage and commitments against the inventory, distinguishing charges for earlier use, retained assets, unavoidable commitments, and unexpected new activity.
And a named owner for the final invoice, the residual data, the restricted archive, and the scheduled follow-up.
The rule
What stays fixed is that every step is verified rather than issued, and that the closure record states what was checked, when, by whom, with what coverage, and what remains unresolved. What changes is who is available to do it, and the answer is nobody who was there at the start.
That is the argument for the evidence trail. The decision records, the dependency inventory, the ledger of what the system cannot do, and the evaluation set are the only things that will still be legible to the team that has to end this — and they are produced during the build, by people with no reason to imagine that moment.
Not to be confused with
Killing a prototype. Some shutdown controls overlap. A system in accepted operation carries user commitments, records obligations, and downstream dependencies that an unaccepted prototype does not.
A retention rule. No generic retention duration and no universal dual-running requirement follows from any of this. What must be kept, and for how long, comes from the specific obligations attaching to the specific records.