Choosing business value over a rewrite

We took over an existing solution for Folketinget with a significant amount of legacy code.

From a purely technical perspective, rebuilding parts of the solution would have been attractive. But the client had a limited budget, and a major rewrite would have consumed a substantial part of it without necessarily creating equivalent business value.

Legacy systems naturally create pressure to modernize. But modernization has a cost — and so does technical debt.

The important question wasn't simply "How can we improve the architecture?" It was "Is improving the architecture the best use of the client's budget?"

We treated the legacy architecture as a business trade-off, not automatically as a problem that needed to be eliminated. Technical debt carries a cost, but removing technical debt carries a cost too. In this case, the opportunity cost of a major rewrite was greater than the value it would have created.

A rewrite would have required significant investment while much of the existing solution was still capable of supporting the client's actual needs.

I worked with the project manager and the client to evaluate the situation from both a technical and business perspective.

Rather than advocating for a rewrite because the existing codebase was old or difficult to work with, I argued for keeping the solution and focusing available resources on making it reliable and extending its useful lifetime.

Rather than optimizing for architectural purity, we optimized for business value, reliability and appropriate technical investment — accepting some technical compromises while being deliberate about where engineering effort would create meaningful value.

The goal wasn't to create the architecture we would choose if starting from scratch. It was to make the right technical decisions for the system, budget and business context we actually had.

The client was able to continue operating the existing solution without investing a significant part of their budget in a rewrite that wasn't necessary for their immediate needs.

By working with the system rather than replacing it, we extended its useful lifetime while keeping investment focused on the areas that provided value to the client.

For me, this project reinforced an important part of technical leadership: good engineering isn't measured by how much technology you replace. Sometimes the better architectural decision is knowing when not to rebuild.