Earlier quoted context omitted.
> If the developers are not competent enough to write maintainable code or maintain existing code Or if the old system simply doesn't work with modern environments. Or if it depends on long abandoned frameworks. Or if the business grows but the old implementation scales badly or not at all. Or if it depends on components that incur licensing fees that become prohibitively expensive when it's scaled up. Or if there ar…
The key is identifying which parts of the code needs to be adapted or replaced and which do not. If the code is well designed with separation of concerns, replacing a framework or library or external dependency should not require all the code to be scrapped, just the layers directly interacting with replaced part. Some trivial applications are basically just glue between frameworks, but most non-trivial application o…
Granted, that concept can and should be introduced into old codebases. Last year my team successfully warded off the Sirens of Rewrite by just doing the hard work of extracting all of the dead framework calls and then NOT adding them back in drag-and-drop style, but properly exposing them through interfaces that don’t require everything to know everything about the particular replacement framework we used.