What we tell boards about rewrites

Sooner or later every board hears the pitch: the legacy system is unfixable, the team that knows it is tired, and a clean rewrite will take eighteen months. We get called either just before that meeting or two years after it. The second call is worse.

Here is what we say in the first meeting, written down so you can say it without paying us.

A rewrite is not a technology decision. It is a bet that your organization can run two systems, fund two roadmaps, and hold one feature freeze, for longer than every estimate in the room. The eighteen months is the down payment. The industry's quiet record on large rewrites is three to five years, and the failure mode is not "it took longer". The failure mode is a half-migrated estate: two systems forever, which is the one outcome costlier than either choice you were weighing.

Four questions before any yes.

One: what, specifically, cannot be fixed in place? "The code is old" is not an answer; code does not rust. Answers that count name a wall with a date or a number on it: the runtime loses support in January 2027, the license model changed under us, the throughput ceiling arrives at the next customer. If nobody can name the wall, the rewrite is an expression of fatigue, and fatigue is fixed with staffing, not with three years of parallel running.

Two: can it ship in slices? A rewrite that delivers nothing until month eighteen is a barge with no lifeboats. The strangler pattern exists because slices change the risk math: each slice retires real load, proves the new estate under production traffic, and leaves you somewhere useful if the program stops early. Programs stop early. Boards approve them anyway and then re-approve them smaller in year two; slices are how the smaller version still means something. If the answer is "this one truly cannot slice", that is sometimes true, and it doubles the weight of every other question.

Three: what happens to the old system's change queue? The freeze everyone is imagining will not hold for eighteen months; the business will not stop needing things. Budget for double-entry: a real number, often 20 to 30 percent of the old team's capacity, spent implementing changes twice. If the plan has no double-entry line, the plan believes the business will politely pause. Put that belief in the minutes and watch someone withdraw it.

Four: who is on it in month thirty? Name the people. The pitch team is always the A team; the month-thirty team is whoever is left after the A team gets promoted off the strategic project onto the next one. Rewrites are finished by the people who inherit them, so the retention plan for those specific humans is part of the technical plan. This question gets the fewest good answers and predicts the outcome better than any of the others.

What we actually recommend, four times out of five: name the wall, slice toward it, retire load one slice at a time, and keep the old team's respect by treating their system as the load-bearing thing it is. The fifth time, when the wall is real and the slices truly do not exist, we say rewrite, with the double-entry budget and the month-thirty names in the same document as the architecture. It is never the exciting recommendation. It is the one whose numbers we can defend in the second meeting, the one two years later.