When the CTO Says We Need to Rebuild

Sooner or later a CTO walks into the room and says the platform has to be rebuilt. The case is usually sincere. The system is hard to change, outages are rising, and the team is frustrated.

A rebuild is also one of the riskiest things a technology team can propose. It costs a lot, takes longer than planned, and leaves the business running two systems for a while. Many fail or deliver late.

The board's job is not to say no. It is to make the proposal compete against the alternatives and to ask for evidence, not conviction.

TLDR

• A rebuild should compete against repair, phased replacement and doing nothing.

• Ask for evidence that the current system cannot scale or be fixed, not opinions.

• Phased replacement is usually less risky than a full rebuild.

• Count switching costs: running two systems, retraining and delayed features.

• Set decision gates so the board can stop the project if the evidence changes.

The four options

Every rebuild proposal should be set beside three alternatives.

• Do nothing. Keep the system as is and accept the costs. Sometimes right, but the cost should be written down.
• Repair. Fix the worst problems in place: remove the most fragile parts, add tests, improve deployment.
• Replace in phases. Build new parts around the old system and move functions across over time.
• Rebuild. Build a new system and switch over.

Martin Fowler describes the phased approach as the strangler fig pattern: a new system gradually grows around the old one until the old one can be retired. Its main appeal is that risk is spread over time instead of concentrated at one cutover.

The criteria sheet

Ask for one page that scores each option on the same criteria. The entries below are illustrative.

Criterion (illustrative)	Do nothing	Repair	Phased replacement	Full rebuild
Evidence current system cannot scale	Not applicable	Tested, partly	Tested	Required, with load test results
Switching cost	None	Low	Medium, spread over time	High, one cutover
Time to first benefit	None	Weeks	Quarters	Often more than a year
Risk if it fails	Rising outages	Low	Medium	High
Reversibility	Not applicable	High	Medium	Low

The first row matters most. If the case rests on a belief that the system will not scale, ask to see the test that shows it.

Questions for the CTO

Ask what specific business outcome the rebuild unlocks that repair cannot. Ask what has been tried. Ask who has done this before in a similar company, and how it went.

Then ask for the exit: at what point would the team stop and what would they keep. A good proposal has an answer. A weak one treats the question as disloyal.

Set gates, not a blank check

Fund the first phase and review it before funding the next. Each gate should have a working result to inspect, not a status report.

For how to tie this to the broader plan, see what what your executive tech roadmap should say.

Frequently asked questions

Is a rebuild ever the right choice?

Yes, when the evidence shows the current system cannot meet the business need and cannot be repaired or replaced in phases at a reasonable cost. The evidence has to be specific and tested.

What is phased replacement?

Building new components around the old system and moving functions across gradually, so the old system shrinks until it can be retired. It spreads risk over time.

What costs do rebuild proposals usually miss?

Running two systems at once, retraining staff, features delayed during the project, and the cost of data migration and testing.

How should a board oversee a rebuild?

Fund in phases with gates tied to working results, and ask for a short regular report on scope, cost to date and the evidence behind the next phase.

A Defensible Next Step

Before approving anything, ask your CTO for the four-option criteria sheet and the load test or other evidence behind the first row. Whichever option wins, it will have earned it. Book a Decision-Clarity Call if you want an independent review of the proposal.