Decommissioning Discipline
The work of actually switching a legacy system off, which is where migration savings are realised and which is routinely left undone.
A migration that does not decommission has produced two systems and doubled the cost. This is the most common way modernisation programmes fail to deliver their business case, and it fails quietly — the migration is declared complete, the team moves on, and the old system runs for years.
The sequence that works: confirm no remaining traffic using evidence — access logs, network flow logs, database audit — over a period long enough to capture monthly and quarterly jobs, which is the step that catches the forgotten batch process; notify remaining consumers if any are found, with a date; disable access before deleting anything, which converts an irreversible action into a reversible one and surfaces any consumer nobody knew about; archive data according to its retention obligation, which frequently outlives the system and must go somewhere queryable; then delete and release the licences, which is where the financial benefit actually lands.
The organisational requirements: funded and scheduled as part of the migration, not proposed afterwards when the enthusiasm and budget have gone; a named owner; and the savings tracked, so the business case is closed out with evidence.
The technique that reliably surfaces the last consumers: a brownout — a short scheduled outage, announced in advance, lengthening on repetition. Email produces no response; unavailability produces immediate ones.