Answer
A new development can be right in the long term, but it is not automatically the safer decision. Old software often contains business rules that have grown over years, rare exceptions and integrations that nobody has fully documented. With a complete restart, these rules have to be rediscovered, implemented and tested alongside ongoing operations. The risk then lies not only in the old code but in lost business knowledge.
A step-by-step approach is often better: stabilise operations first, add observability and tests, choose a functional boundary and build new functions alongside or in front of the existing system. This allows the old core to shrink in a controlled way. In other cases the system is so insecure or unmaintainable that a limited parallel rebuild is more economical. The decision should be based on risk, need for change, data and the ability to verify acceptance – not on the age of a programming language or how the code looks.
As of 3 September 2026
Further reading
Related topic: Taking over existing software