[EdSharkey]

What you are saying sounds cavalier to me. Fact is, big rewrites are very risky and there's nothing appealing about working on them, I can attest! Any developer worth his salt should fight tooth and nail to kill such a rewrite project and then run screaming when business and management go forward anyhow with scrapping the working legacy system in order to "start fresh".

Lost opportunity does suck. It would be nice if the first system was written in an extensible way with lots of tests and correct documentation, but it rarely is. All software needs to be replaced at some point. All software has a finite useful lifespan. So, this is a common problem. But you must have a responsible plan for replacing any first system. Any sort of project plan that has a magic day where the legacy system is shutdown and the second system is turned on is reckless and absurd. I've heard of failure rates for such projects being 80%, with the rest going way over budget before completion.

The best you can do when replacing a crufty old system is to employ strangulation. You slowly, methodically kill off the legacy system one feature at a time with the equivalent features in the well-written/tested new system. You run both systems side by side, sharing the processing load until one day, years in the future, when you have replaced all the features and the legacy system has nothing to do. It's a hassle and it requires everyone to be organized from start to finish, but you eliminate the big-bang release risks.

Luckily, with all the web services and factored out componentry we've been building in software over the past 10 years, the strangulation approach has never been more feasible.

There's lots of good youtube lectures and agile community blog posts on the topic of second systems and strategies to implement the strangulation. Here's an old classic that introduces the concept better than I could:

http://www.martinfowler.com/bliki/StranglerApplication.html