The entire set of backend service tools at Amazon.com was in Perl and C (almost no Perl facing customers but tons facing employees). The tools were disparate, separate, and sometimes overlapping so they were difficult to learn and maintain. Someone high up decided Java would fix this. 18 months later there was a GUI replacement tool (mostly replacing just Perl and wrapping existing C) that was 18% code complete compared to the original base. What was there was buggy and often too slow to be practical (long conversations to distract customers while you waited for data to come back). Still it was hailed as a huge success by management.

The old tools were still around because of the incomplete nature of the GUI and even new, untrained employees gravitated back to them because they worked consistently and in much deeper ways. Even though it was the only sanctioned way to do the work, the Java tool had about an 80% abandonment rate.

Many, many millions of dollars (training, retraining, lost hours, developers' time, new hardware, in fighting, work on an open list of 500 bugs, etc, etc), and lots of confused, frustrated, or plain angry employees, later the entire thing was sent to the scrap heap and recoded as a web app in Perl (again, just replacing Java parts mostly and still wrapping C).

I understand it's all now being redone again in Java, though this information I only know from an overheard conversation so it could be erroneous.

These kinds of decisions are often from work-flow illiterate senior managers who cannot get good information through the bureaucratic layer cake. They make terrible choices and blame the technologies for their failures because that's easier than admitting a good bit of your managers, technical PMs, and maybe even you and a few of your developers are incompetent and should be culled or repurposed.