Usually it has nothing whatsoever to do with the code organization. The most common cause is lack of active developers to make the adaptationIt varies from shop to shop, but what I've seen is that code organization has a lot to do with it. Basically, if your code organization/factoring is really bad, then it's more likely that porting becomes untenable. Ironically, these are the projects that can have the longest lifespans, sometimes developing a history of multiple failed attempts to "port" them. (Really, re-implement while incurring huge opportunity costs.)
> If all of the environmental variables remain the same
Would you like a pony too?
You're seriously missing the point. My point is that the environmental variables never remain the same. (I was making two points, and I think you missed where I switched.)
> 2) you have a reliable syntax driven code rewrite tool
Would you like a pony too?
I repeat. I've been paid good money to use such a tool. I've used such a tool to enable the 1-step-removed porting of a project to a different language variant. Instead of doing the port myself, I was refining a tool which automated the port and enabled the maintainers to easily port all the changed code they were checking in. This lets you do a port without incurring the opportunity cost. I know of a consulting company that once made most of their income with this.
Yes, you can automate away the easy cases, but that's not even half the battle.
You can't simply hit a switch with this, of course. Someone has to put real thought into how the translations are made, especially if you want idiomatic, readable code going out the other end. The good thing about consistent idioms, is that they can be leveraged to multiply that work. The manual part can be re-leveraged through automation.
That's why people hire maintenance programmers like you.
That could be read in a way that sounds less than friendly and maybe a bit elitist.