Any organization that has been around for some time has “that” codebase that no one wants to talk about. It was written in a rush, features have been layered over time, the technology is stale, and any time you touch it – pain.

This can be an even larger issue if that pain is only experienced by the development team. If business units and stakeholders are able to ignore – it creates some very real contention.

The most common challenge with legacy technology is it’s existence seems to provide value but the justification for a major development investment hasn’t yet been uncovered (and may not exist).

The solution to alleviating the pain is to get proactive and develop a game plan:

Buy, Rebuild, Kill, Life support


Assess the type of value the technology is providing and determine next steps:

Kill: Retire anything that doesn’t fit the Meaningful Software Model. If it doesn’t provide value to a substantial segment of end users and doesn’t fulfil the objectives of the maintainers – get rid of it.

Buy: Technology that doesn’t facilitate a core business services should be evaluated for replacement with a 3rd party solution. Somewhere out there the need you have is someone’s core competency.

Rebuild: Technology that directly facilitates/enables core business offering. This includes anything that allows your organization to differentiate it’s products and services.

Life Support: If it provides enough value to keep around, no cost effective 3rd party solutions exist, and it isn’t worth re-writing (aka a rewrite can’t be sold to leadership) – then put it on life support. This means break-fix and that’s about it. Make a clear distinction between break-fix and enhancements. If you don’t it will eventually overwhelm your team.

Strategies for Rebuild


Depending on the size of the codebase it may not make sense to rewrite it all at once. A common approach that works well is to rewrite portions of functionality and then integrate the new functionality with the legacy codebase. When possible this allows the team to incrementally build & test without a big-bang style launch.

When incremental change isn’t an option – and a full rewrite is the only choice, the key to success in many cases is to attack the rewrite from a “functionality” standpoint vs a “code” standpoint. Advantages for doing this is it allows for simplification of the replacement system whereas complexity very well may be the reason the legacy solution requires a rewrite in the first place. Doing this will require collaboration between stakeholders to “re-discover” the necessary features of the system.

Selling a Rebuild to Leadership



Sometimes convincing your boss that an investment is required proves more challenging than the rebuild itself. It’s also an opportunity to really evaluate if a rebuild is a worthwhile. Here are some considerations to help build a case for investing the time

1) Where can support & maintenance costs be reduced?

2) Opportunity costs – what capabilities/features are not feasible to build in the legacy solution?

3) What risks does not rebuilding create (loss of support on tech stack, security gaps, inability to find developers with required skillset..)

4) Does a rebuild change the infrastructure requirements – ex: does it allow the organization to utilize platform as a service?

5) Does a rebuild provide a marketing opportunity? Does a rewrite allow you to promote a “version 2.0” product?


In the end if you can’t create a compelling case you can and should be proactive by locking it down. Taking control over legacy solutions is the only way to prevent them from draining resources and time.