I've seen multiple posts about rewrites of applications being bad, people's experiences about it here on Programmers, and an article I've ready by Joel Spolsky on the subject, but no hard evidence or case studies.  Other than the two examples Joel gave and some other posts here, what do you do with a bad codebase and how do you decide what to do with it based on real studies?For the case in point, there are two clients I know of that both have old legacy code.  They keep limping along with it because as one of them found out, a rewrite was a disaster, it was expensive and didn't really work to improve the code much.  That customer has some very complicated business logic as the rewriters quickly found out.  In both cases, these are mission critical applications that brings in a lot of revenue for the company.  The one that attempted the rewrite felt that they would hit a brick wall if the legacy software didn't get upgraded at some point in the future.  To me, that kind of risk warrants research and analysis to ensure a successful path.Have there been actual case studies that have investigated this?  I wouldn't want to attempt a major rewrite without knowing some best practices, pitfalls, and successes based on actual studies.Aftermath:  okay, after more searching, I did find three interesting articles on case studies: Rewrite or Reuse.  They did a study on a Cobol app that was converted to Java.  The other was on Software Reuse: Developers Experiences and Perceptions.Reuse or Rewrite Another study on costs of maintenance versus a rewrite.I recently found another article on the subject: The Great Rewrite. There the author seems to hit on some of the major issues.  Along with this was the idea of prototyping by using the proposed new technology stack and measuring how quick the devs picked it up.  This was all as a prelude to a rewrite, which I thought was a great idea!
Are there any actual case studies on rewrites of software success/failure rates?
source code;planning;code reuse;rewrite
I can't take credit for these great comments, but they were never put into an answer by the original author, so I'm marking it community wiki.I don't know about case studies, but I think the standard answer for an approach is probably add unit tests and refactor.It strikes me as quite possibly the lowest risk approach available. Of course, I don't know enough details to be certain it's the right approach, but based on what I know so far, I don't know of much that's particularly likely to be a lot better.If they do unit tests (properly -- truly capturing all the requirements) it's difficult to come up with a way for refactoring to result in a true disaster. About the worst that can happen is that you don't make as much progress as fast as you'd like. At the same time, if their code base is in as bad of shape as the question implies, chances are pretty good that serious effort will be needed to enable progress, regardless of the route taken.I would assume that rewrite projects aren't significantly different in failure rates than projects in general, and would refer to latest CHAOS report for best info.