This question already has an answer here:
A piece of software is a patchwork of old and undocumented efforts. There are no comments, no documentation, and the code is hairy -- it involves Unix shell scripts that check for dummy files and then call SQL statements that call database procedures that modify data.
The original developers have left and we score a solid 2 on the Joel Test but I can raise it to at least 4 - yay...
The code is reasonably error-free, but we constantly need to add new features into it which is highly error-prone because of the state of the code, so the deadlines slip and the efforts rise.
We want to rewrite this software in order to reduce maintenance and development efforts. As part of the rewrite, we will introduce specs, comments, test cases -- all things that we currently don't have. It'll still be a bit complex afterwards, but no more than necessary.
This is not a BIG rewrite because we are not going to switch languages or frameworks; we'll still need shell scripts (but fewer) and database procedures (but fewer). The implications are also fairly simple because we're in control of the installation sites and we can fully replace the old code with the new code at the flick of a switch.
I know a rewrite is never good but I think these are reasonable counterarguments. Nevertheless, my concern is the typical danger of introducing brand new bugs instead of the old known ones, and also the danger of not implementing certain details because nobody even knows they exist or are needed.
How can I approach this rewrite in an efficient manner?