What is most important is what are you trying to achieve. Are you trying to make the system as stable as possible at the lowest cost to the client or are you trying to bring this system into a future proof state and the client is willing to pay for that?
Personally if I were in your position I would explain to the client that I'm happy to temporarily fix some bugs but long term the system needs to be rewritten. 700k lines of code is a lot, but the way you've described it I get the feeling most of that code is needless. Depending on what the system actually does you could conceivably rebuild in a few months.
I've spent quite some time the cross-component spaghetti code large companies sometimes write.
I've come to believe that the skill of not rewriting from scratch but forcing yourself to slowly refactor (as per Martin Fowler's definition) existing systems into a proper state is one of the most important skills you can develop.
That way, once you've refactored most of the system (which includes adding tests for all the important functionality) you can indeed confidently rewrite everything.
If you do it any sooner than that though, you're in for a world of pain.
Second this. The temptation to rewrite from scratch is to be avoided; the code is going to be a mass of edge-cases, and you can't spot them all at once. Rewriting will take just as long as refactoring and introduce new bugs instead of killing old ones.
Comments
What is most important is what are you trying to achieve. Are you trying to make the system as stable as possible at the lowest cost to the client or are you trying to bring this system into a future proof state and the client is willing to pay for that?
Personally if I were in your position I would explain to the client that I'm happy to temporarily fix some bugs but long term the system needs to be rewritten. 700k lines of code is a lot, but the way you've described it I get the feeling most of that code is needless. Depending on what the system actually does you could conceivably rebuild in a few months.
I've spent quite some time the cross-component spaghetti code large companies sometimes write.
I've come to believe that the skill of not rewriting from scratch but forcing yourself to slowly refactor (as per Martin Fowler's definition) existing systems into a proper state is one of the most important skills you can develop.
That way, once you've refactored most of the system (which includes adding tests for all the important functionality) you can indeed confidently rewrite everything. If you do it any sooner than that though, you're in for a world of pain.
Second this. The temptation to rewrite from scratch is to be avoided; the code is going to be a mass of edge-cases, and you can't spot them all at once. Rewriting will take just as long as refactoring and introduce new bugs instead of killing old ones.