I've actually been involved in at least three projects to do precisely that. And mostly they worked fine.
In two of the three cases I was converting between "the same language" but different incompatible versions of it and the original code bases had strict style guides. At the end of it everything worked brilliantly, and the code was just as maintainable as it was before the conversion.
In the third case was an full lexer/parser built out to compile VBScript down to JavaScript. The resulting code was not readable or maintainable but it did run and that satisfied the needs of the project.
In my experience is that language conversion projects are gnarly, and depend heavily on style guides and accurate specifications for the languages to produce good output. But these are not doomed enterprises from the start and in the end it's the quality of your convertering code that determines the success of the project.
I once worked on a project that was auto converted from VB6 -> C#. Amazingly it compiled and parts of it actually ran.
We still rewrote the entire thing, line by line and then spent months refactoring it. It was our only choice really, so much of the original code was so unclear and all the original developers had left so it was our only hope of keeping the business logic intact.
There are some (very few) cases where it makes business sense.
For example, the company I work for has software developed in a legacy language with no support (Forte 4GL).
There are companies that offer Forte to Java migration, it would have been worth it because of better tools and support (even if the code was the same crap as usual :) ).
I have done it for a few files here and there without too much hassle. An entire project sounds like a nightmare though. Also, which language you are converting from/to will have a big impact. VB.Net>C#; no big deal. FoxPro>Erlang; ouch.
In the long run it would be cheaper rebuilding the entire thing.