Replacing legacy systems incrementally instead of rebuilding

When a grown system costs more in maintenance than it delivers in new features, the proposal to rebuild it from scratch tends to follow quickly. That is understandable and usually too expensive.

Cost of a full rewrite

An existing system holds years of domain knowledge that is written down nowhere: special cases, exceptions, rules someone added on request eight years ago. A rewrite has to reconstruct all of it before it delivers any value at all. Meanwhile the old system keeps running and keeps needing care — so you pay twice, often for years.

Conditions for incremental replacement

It is not possible in every case. Three conditions decide:

• Clear domain boundaries. If you can name an area that makes sense on its own, it can be carved out first.
• A dependable data interface. Old and new have to run side by side for a while and see the same data.
• Someone who decides. Incremental replacement produces a constant stream of scope questions. Without a named decision maker it becomes a permanent state.

When a rewrite is the right call

Sometimes a rebuild is right — when the technology base no longer receives security updates, or when the system is being retired for business reasons anyway. That decision should rest on an assessment, not on the feeling that the old code is unpleasant to work with.