Of all the measurements a transformation depends on, the most valuable is also the most perishable. A benefit is a comparison between an after and a before, and the "before" can only be taken from the system that is about to be retired. That gives it an expiry date — cutover — after which the source is gone, the reports that produced it can no longer be run, and the comparison you built the whole business case on becomes an argument instead of a fact.
Most programmes discover this too late, because the baseline feels like something that can wait. It can't. It is the one number on the plan whose window closes permanently, and it closes at the busiest, most distracted moment of the entire programme.
Why it breaks at cutover, not go-live
Go-live is when the new system starts. Cutover is when the old one stops — and it is the stop, not the start, that destroys the baseline. The legacy report that told you your average order took four days to fulfil, your close took nine, your invoice-matching failed 12% of the time: those numbers lived inside the old system's data and logic. Once that system is decommissioned, you cannot re-run the report, cannot re-derive the figure, cannot even reliably reconstruct how it was calculated. The "before" doesn't degrade gracefully. It disappears.
A baseline is the one measurement on a programme whose window closes for good — and it closes at the exact moment everyone is looking the other way.
A baseline is a definition, not just a number
Capturing the baseline in time is necessary but not sufficient. A number without its definition is only half a measurement: "nine days to close" means nothing later unless you also captured what counted as the start and end, which entities were included, which adjustments were in or out. When the new system reports its own close time, it will define those boundaries its own way — and unless the baseline was recorded with the same precision, the comparison is apples to something that merely resembles apples. The baseline you can defend is the one captured with its method, from the source, before the source is gone.
What "capturing it properly" actually means
Doing this well is unglamorous and entirely within reach. It means deciding your benefit metrics early enough that the baseline can be taken from the live legacy system, not reconstructed from memory. It means recording each figure together with the exact query or report that produced it, so the same logic can be re-applied to the new system for a true like-for-like. And it means storing that evidence somewhere independent of the system being switched off, so the proof outlives its source. The effort is modest. The alternative — a benefits case that cannot be reopened because its foundation was demolished — is not.
Where we sit. Roltrader's assurance layer captures the baseline from the legacy system with its full definition, and holds it independently so the post-cutover comparison is reproducible rather than remembered. But the timing is the point, tool or no tool: decide the metrics early, measure the "before" while the old system still runs, record how you measured it, and keep the evidence somewhere the decommissioning can't reach. The window is real, and it does not reopen.