They're almost all program and language dependent. If your game doesn't use threads, you don't have to port anything to do with threads. If it does, but you use Java or C++11 and their platform independent thread libraries, you (ideally) don't have to port anything to do with threads. But maybe you used C or C++98 and now you have to run around putting in ifdefs for CreateThread vs. pthread_create and debugging subtle differences between Win32 and POSIX threads, etc.
Or maybe you decided to write the whole thing using multi-platform libraries like Qt in the first place, so that you don't have to change hardly anything. Or maybe you wrote it in Visual Studio using .NET heavily and you have to practically rewrite everything from scratch. It's totally dependent on the decisions you made when writing the original program.
In addition to what AnthonyMouse said, it also gets a bit more complicated than that. If you have a high performance game engine, it's very likely that the inner loops are written in assembly to squeeze every last drop of performance out. The guys who write this code are optimizing for the OS's memory handling behaviors, aligning data to fit into cache lines, using SSE instructions for faster matrix multiplications, and all sorts of other exotic techniques that "mere mortals" don't even think about.
So when you change platforms from, say, the Xbox 360 to the PS3, those assumptions you made about the OS, the CPU, the chipset, and other minute details are suddenly completely, horribly wrong. So the guy who wrote all of that highly optimized code has to write it again to optimize against a completely different set of quirks.
Or maybe you decided to write the whole thing using multi-platform libraries like Qt in the first place, so that you don't have to change hardly anything. Or maybe you wrote it in Visual Studio using .NET heavily and you have to practically rewrite everything from scratch. It's totally dependent on the decisions you made when writing the original program.