The Kill List: Giving Sunset Dates Equal Billing on Your 2026 Roadmap

Open almost any transformation roadmap approved in a UK boardroom and you will find the same shape. Fourteen initiatives, each with an owner, a start date and a go-live. What you will not find, in the overwhelming majority of cases, is a column for what stops. Addition is celebrated; subtraction is unmanaged. The result is an estate that grows every year while the capacity to run it does not.

This is not a housekeeping complaint. It is a cost and risk argument, and it deserves the same rigour as the business case for the next platform.

Addition without subtraction is a form of borrowing

Every system retained past its usefulness draws on four budgets at once. There is the obvious run-rate: licences, hosting, support contracts, the specialist contractor who understands the customisations. There is integration debt, since each surviving tool is a connector to maintain and a schema to reconcile. There is cyber exposure, concentrated in platforms that have fallen out of vendor support and no longer receive patches. And there is the quieter cost of cognitive load, where staff maintain familiarity with three tools that do one job.

None of these appear as a line item. They surface instead as an unexplained rise in the infrastructure budget, a failed audit finding, or an integration project that takes twice as long because nobody documented what the legacy system does.

A kill list is a register, not a rant

Informal opinions about retiring systems circulate in every IT department. They rarely survive contact with a finance committee. What changes the outcome is a standing register, reviewed on a fixed cadence, with the same fields as any project portfolio: system name, business owner, function served, annual cost, risk rating, proposed action, target date and known blocker.

The proposed action should be limited to three words — retain, consolidate, retire — so that the register forces a decision rather than hosting a discussion.

What earns a place on it

A useful starting set: pilots that ran for two quarters without reaching agreed adoption thresholds; tools that duplicate a function already covered elsewhere; platforms past end-of-support; systems whose original owner has left and whose purpose is now unclear; subscriptions discovered during a SaaS audit that no cost centre recognises; and heavy customisations that now block upgrades on a strategic platform.

Each entry needs evidence attached, not sentiment. Usage statistics, ticket volumes, cost per active user and the last date of meaningful change are usually enough to move a conversation from opinion to arithmetic.

Who signs a sunset

Retiring a system is both a technical decision and a contractual one, and organisations routinely fail by treating it as only the first. A workable split is three signatures: the accountable business owner, who accepts the change in how work is done; finance, who confirms the run-rate actually leaves the books; and a technology authority, usually the CIO or equivalent, who confirms the migration and data retention position.

Set delegated thresholds. Below a defined run-rate, the business owner and technology authority can proceed together. Above it, the decision belongs to the executive committee, where the cost avoidance should be reported alongside the saving.

The vocal internal owner

The obstacle is rarely technical. It is a respected manager who has run the system for nine years and can list six things that would break. Handle this with data and with a route out. Share the usage figures before the proposal, not after. Give the owner a defined role in the replacement, whether that is requirements, testing or migration sign-off. Offer a migration path and a date rather than a closure notice.

Two claims deserve polite scrutiny. The first is "we might need it". Ask what would trigger that need and whether an archived read-only copy would satisfy it. The second is "it's a regulatory requirement". Ask for the citation, the regulator and the retention period. In many cases the requirement concerns the data, not the application, and a data retention arrangement resolves it at a fraction of the cost.

Escalate once, with facts, and only if the owner will not engage with a plan. Repeated escalation converts a portfolio decision into a territorial dispute.

What a credible date looks like

A single sunset date is a wish. Three gates make it a plan. The decision gate confirms the retirement and the replacement route. The migration gate confirms that data is transferred and the old system is read-only. The closure gate confirms that credentials are revoked, the contract is terminated and a deletion certificate is on file.

Simple SaaS tools can travel that path in 90 to 180 days. Anything with deep integrations, historical records or a regulatory retention obligation needs considerably longer, and pretending otherwise is how retirement programmes lose credibility after the first missed date.

One page, two columns

Put go-lives and retirements side by side on the same page, in the same format. Then apply a single rule at the intake stage: no new system enters the roadmap without naming the system it displaces, or stating explicitly that nothing does and why. That rule alone tends to reduce the queue.

What to report

Two numbers carry the argument: systems retired in the period, and annual run-rate avoided. A third, the average age of the estate, is a useful leading indicator for the following year. Align reporting to the financial year end of 31 March so that avoided cost lands in a budget cycle where it can be redeployed.

Start with three entries. Three is enough to prove the mechanism, generate a saving and demonstrate to the board that the roadmap subtracts as well as adds.