I always found an iterative refactoring of the old code a better engineering approach: small changes that do not modify the external behavior, but end up extrac

I always found an iterative refactoring of the old code a better engineering approach: small changes that do not modify the external behavior, but end up extracting a better design. Martin Fowler expressed it clearly in a 1999 book: "Refactoring: Improving the Design of Existing Code" Another approach that I would advice using is studying the usage pattern of the current code base (analyze the logs over a long timespan, and/or instrument the server), in order to avoid making assumptions about how the old codebase is used. The idea is that an old project, albeit ridden with awkward technical debt, is a project that is currently delivering business value, and - as such - it is important to have ways in your toolbox to extract meaningful information from it, filtering out the bad parts