Modernization Budget Planning

By now the decision is made: the cost of inaction from Part 4 has outweighed the cost of action, and the business case from Part 3 has been heard. Now comes the practical problem that stops many programs at the finish line — how do you actually budget for something whose total cost, as Part 1 established, cannot be quoted before the system is examined? Finance wants a number. The honest answer is that the most useful number is not the total; it is the cost of the step that produces the total.

This is not evasion. It is the same discipline that runs through the whole series, applied to the budget: you price the small thing that tells you the price of the big thing, and then you budget the big thing one informed increment at a time. Done right, this is more predictable than a single upfront forecast, not less — because every commitment is made with real information rather than a guess.

Why you can’t start with a total

A traditional budget wants a single figure approved upfront. For modernization, that figure can only be a guess, because the cost is a function of the specific system and the specifics are exactly what no one has examined. A total committed before discovery is either padded heavily to cover the unknown — wasting budget on risk that may not materialize — or it is optimistic and sets up the overrun that the program will later be blamed for. Either way, the upfront total is the source of the unpredictability that makes modernization budgets frightening.

The fear, as Part 1 noted, is rarely that the program will be expensive. It is that it will be expensive and unbounded — that the number will keep climbing and no one will know when to stop. A budgeting approach that addresses that fear directly is worth more than one that produces a confident-looking total no one believes.

Fund discovery first

The first line in a modernization budget is a fixed-scope discovery phase. This is a bounded, predictable, separately funded investment whose entire job is to remove the largest unknown. Discovery reads the codebase, the data, the dependencies, and the undocumented rules, and it produces the things finance actually needs to plan: an evidence-based effort estimate, a risk assessment, and a roadmap of slices in priority order.

Budgeting discovery is easy precisely because it is fixed in scope — you know what you are buying and what it costs. And its output transforms the rest of the budget from a guess into a plan. After discovery, finance can set a credible multi-year envelope grounded in the actual system rather than an analogy to some other company’s program. The point of funding discovery first is not to delay the budget; it is to make the budget real.

Budget slice by slice

With the roadmap in hand, the rest of the program is budgeted incrementally, slice by slice. Each slice is a bounded unit of delivery — working software in production — and each is estimated and funded as it is planned, with the information from the slices before it.

This changes the financial character of the whole program. Instead of forecasting years of work blind and hoping the total holds, you forecast a slice or two ahead with real data, and the forecast gets more accurate as the program proceeds, because each completed slice informs the next estimate. The budget becomes a rolling sequence of bounded, informed commitments rather than one large bet placed at the start. For finance, this is a more controllable instrument: spend is visible, paced, and tied to delivered value at every step.

Crucially, the per-slice structure preserves a real stop option. Because every slice ends with working software in production, the program can be paused or halted after any increment without stranding a half-finished rewrite. That optionality is the structural answer to overrun: you are never committed to spending the full projected amount on faith, so the budget can never run away while no one is looking.

What budgets routinely leave out

Even a well-staged budget runs over if it omits the costs that are not “development.” Four line items are commonly missed, and naming them upfront is the difference between a budget that holds and one that surprises everyone in month four:

• Running the legacy system in parallel. During the transition, the existing system keeps running — and keeps costing — alongside the modernized slices, until each is cut over. This is a genuine, ongoing line item for the duration of the program.
• The strangler facade and integration work. The infrastructure that lets traffic shift gradually between old and new is real engineering effort, separate from the slices themselves.
• Internal time. A modernization needs an executive sponsor and workshop time with the subject-matter experts who hold the system’s knowledge. That internal cost is real even though it never appears on a vendor invoice.
• The deferred queue. Work surfaced during one slice and intentionally pushed to a later one needs budget when it comes due. A small contingency for the deferred queue keeps it from reading as an overrun.

These are not hidden costs in the sense of being concealed — they are simply the costs that a development-only budget forgets. Putting them in from the start is what makes the budget honest.

Where this approach meets resistance

This staged approach is the right way to budget a genuine modernization, but it is not free of friction. Some finance functions are structurally uncomfortable with a budget that does not begin with a total, and forcing the work into a single fixed-total commitment to satisfy that preference reintroduces exactly the unpredictability the staged approach removes. If your organization cannot accommodate phased funding at all — if the only way to get money approved is one large number upfront — that is a real constraint, and it is better named early than discovered late. The staged budget assumes an organization that can fund a first step, learn from it, and decide. Where that assumption does not hold, the conversation has to happen before the work does, not after.

Where this leads

The staged budget maps directly onto how the work is contracted — fixed-scope for the bounded parts, more flexible structures for the open-ended delivery. Those are commercial decisions with real risk and incentive trade-offs, and getting them wrong can undo a sound budget. Part 6, Fixed-Scope vs Time-and-Materials Modernization, explains the two engagement models, what each optimizes for, and how a well-structured program uses each where it fits.