> 2 years to rebuild in Rails?! How?!

Big companies get in this trouble when they practice "Big Requirements Up 
Front". If you schedule a huge number of requirements, then try to do them 
all at the same time, you make development extremely hard. This is how the 
huge multi-billion dollar software project failures happen in the news. 
Rails is not immune.

http://www.oreillynet.com/onlamp/blog/2007/09/big_requirements_up_front.html

The correct way to replace an old project is a process pattern called 
"Strangler Fig". You ask the client what's one tiny feature to add to the 
old system - what are they waiting for - and you implement it using the new 
technology. You link the old system to it, and you put it online as soon as 
possible.

A project that succeeds early cannot fail in 2 years. (It can be cancelled, 
at any time, of course, but with no difference between the cost and the 
amount of features deployed.)

Then you ask the client what's the next feature, and you implement this, and 
use it as an excuse to convert a little more of the old system into the new 
system. And if there's no reason to completely retire the old system, you 
don't. You could save 1 year like that!

Someone got ambitious, and actually believed Rails's hype, and was 
over-confident.

-- 
  Phlip