(This article is part of the "Big Rewrite":http://chadfowler.com/2006/12/27/the-big-rewrite series.)
To add to the stress of the "Big Bang":http://chadfowler.com/2007/01/02/the-big-bang comes another, mostly people-related issue. Almost all technology rewrites are driven by some technologist. Behind almost every technologist pushing for a Big Rewrite is a business person saying "But, why?" The question is valid. The product already works. It's successful enough to even consider re-plumbing it, so we must have already gotten something right, no?
So, then come the justifications. They start with the real reasons the software is being rewritten (but usually censored to avoid the technologist looking like he or she screwed up big time on the initial development of the product). The system will be more maintainable. It will be easier to add features. "Oh yea? So we can do more features faster?" "Uh, yea." "How much faster?" And so on.
As those discussions get heated and prove unsatisfactory, the list of promises gets longer. The system will be more scalable. System response time will improve for our customers. We will have greater uptime. And so on.
It's rare, in fact, that a technology rewrite can deliver on all these fronts. A J2EE Web application may not prove in practice to provide higher availability than a mainframe application. Rails might be a more flexible and productive environment for a developer, but Rails apps slightly underperform equivalent PHP apps. So, you don't sell Rails as something that will be _faster_ than PHP. You sell it as something that is more flexible and maintainable, and will perform reasonably compared to a PHP application.
The piles of justification lead to piles of additional work and/or piles of mismatched expectations and disappointment after release.