The roadmap shows what arrives and never what stops
The version of the modernization plan I see most often has a slide for everything the program will deliver and no slide for anything it will switch off. Twelve capabilities, four waves, a go-live date in a coloured box. When I ask what stops on the Monday after go-live, the answer is usually a pause, followed by the old system, eventually. That one word carries most of the cost of the program.
A retirement list fixes this. It is a plain table of the reports, interfaces, spreadsheets, batch jobs and manual handoffs that will no longer run once the new process is accepted, with a named person against each row. That is a different document from the decommissioning plan for the old platform. The retirement list is smaller and earlier, and it belongs in the scope document rather than in the operations handover.
Every new capability adds work before it removes any
Each capability the program adds brings an interface someone has to monitor, a support routine someone has to staff, and a training obligation someone has to schedule. Those costs land whether or not the old way of working ever goes away. The saving in the business case only appears when something on the other side of the ledger actually stops.
I reviewed a Workday HCM program where the new position management process went live cleanly, and six months later the finance team was still receiving the Monday headcount extract from the previous HR system, because the extract ran from a scheduled job nobody had been asked to cancel. Two headcount numbers, two arguments at every month-end, and a payroll analyst quietly reconciling them by hand. The program had delivered exactly what it scoped. It had never scoped the extract.
The same shape turns up on SAP work. A team rebuilds a custom report as a proper extension on SAP BTP, tests it, and hands it over. The original Z-program keeps running in the nightly batch, because turning it off was never a line item, and its output still lands in a shared folder that three people open out of habit. You now support both, and the clean core effort has cost more than it saved. Amani made the funding version of this argument in clean core is a budget decision, and the retirement list is where that budget line becomes a set of named objects.
Write the list while scope is still open
The list belongs in the scoping phase because it changes what gets scoped. When a workstream proposes a capability, the question I ask is which row of the retirement list it lets us close. If the answer is none, the capability is an addition. Additions are sometimes right, but they should be budgeted as new running cost, and the steering committee should see that it is paying for a wider estate rather than a replaced one.
Scoping is also when the list is cheapest to write. The business analysts are already sitting with the payroll team, the HR operations lead and the finance controller, mapping what happens today. Ask them to record every report, extract, spreadsheet and manual approval they come across, together with who consumes it. That inventory is the raw material. Later in the program those same people are testing, and nobody wants to open a new document during testing.
If you have already drawn an integration map before the roadmap, most of the interface rows exist. The rows that get missed are the human ones. The weekly email with the attachment. The approval that happens by walking to a desk. The spreadsheet a regional HR partner keeps because the old system could not hold a secondary cost centre.
A useful row names a report, not a system
The rows I send back in reviews say things such as legacy HRIS or old reporting. Nobody can verify that a system has stopped being used, because a system is many things at once. A report is one thing. An interface is one thing. A row that says the Monday headcount extract from the old HRIS to finance, consumed by the planning team, replaced by the Workday headcount report, retiring on acceptance of wave two, is a row one person can act on and another can check.
Each row needs an owner, the evidence you will use to confirm it is no longer needed, the acceptance event that triggers retirement, and the date it goes dark. Evidence matters more than people expect. For a report it might be download counts over a month. For an interface it is the message log. For a spreadsheet it is a conversation with the two people who fill it in, because there is no log.
Put the access on the list as well. When the old process ends, the roles that let people run it should end too. On the Workday HCM side that means the old security groups. On the SAP side it means the authorisations tied to the retired transaction. If the roles stay, the process stays available, and someone will use it under pressure during the first month-end after go-live. The retirements sitting in a payroll program are the clearest case, and the parallel-run discipline in payroll cutover as a reconciliation project only pays off if the old run actually ends.
Somebody has to be paid to switch it off
The line in most program plans says the business will transition away from the old process. Nobody is named, so nothing happens. The old report keeps running for one more quarter, then another, and by the second quarter the program team has been reassigned and the operations team has inherited two of everything.
Name a person per row. Not the program manager, who will be gone, and not the platform owner of the new system, who has every incentive to declare success and no way to see what the finance team is still opening. The right owner is usually the person who consumes the old output, because they are the only one who can honestly say they no longer need it. Their job is to verify non-use, tell the remaining consumers the date, and then request the switch-off. Give them a decommission window with a date, after which the job is disabled rather than deleted, so the first complaint can be answered by turning it back on for a week while the gap gets fixed.
This is ordinary ownership discipline, the same kind that goes missing where automation owners lose the thread after a failed run. The list only works if the owner column holds names rather than team labels, and the governance forum that reviews the program should treat an empty owner cell as a defect in the plan.
What to ask at the next steering meeting
The question I put to program boards is short. Show me the row that says what stops. If the roadmap has fourteen deliverables and zero retirements, the program is an expansion, and the business case should be read again with that in mind.
Then ask each workstream lead to bring three rows to the next meeting: one report, one interface, one manual handoff, each with a named consumer and a proposed switch-off date. Put those rows in the scope document next to the capabilities that replace them, and treat a missed retirement date as a slipped deliverable in the status report. The first time a retirement row turns red, you will find out whether the program is modernizing the estate or adding to it.
