A rewrite can leave you maintaining two systems

The old system is difficult to change, so a team starts over. Its replacement will be cleaner, and surely will not take long. Meanwhile, maintenance on the original becomes less attractive because everyone expects it to disappear.

Then the replacement team discovers how much undocumented behavior the old system contains. Deadlines force a partial launch. Priorities move on. Both systems remain.

Simon Willison’s account of this familiar trap favors improving automated tests around the existing software before deciding how much needs replacing. Targeted refactoring may get the desired result without recreating every accumulated behavior. When a migration is necessary, retiring the original is part of the project—not something that automatically follows writing the new code.