If you thought about portability when you were writing the code, then yes, you just flip a compiler switch and you're good to go.

A lot of the older 32bit software didn't ever consider the need to switch to 64bit in the future, so there is plenty of implicit assumptions made. These are sometimes very obvious (e.g. hand coded 32bit assembly), but sometimes very hard to detect, and can have a lot of logic built on top of it. For example, consider these two structures:

    struct A { int n; void *p; float f; };
    struct B { int a, b, c; };

Both structures are 12 byte large on 32bit, but A is 16 bytes on 64bit, because the pointer will be naturally aligned to 64bit boundary, so it will have 4 bytes of padding after n.

There's plenty of ways the code could assume that sizeof(A) == sizeof(B). For example, it could use memcmp() to verify the structures are equal, or it could be allocating them from the same slab allocator to minimize fragmentation. These kinds of bugs will not be caught by the compiler, and they might not be easily noticeable at runtime. It takes significant effort to port a, say, 20 year old codebase written for 32bit over to 64bit.

Yes, it's easy to say "that's bad code, you shouldn't have written it like that in the first place", but programming 20 years ago was drastically different than today, and those "hacks" could make or break a product back then. And, at the time some 32bit software was written, it was not even obvious what 64bit would look like, so it was not obvious how you'd prepare for it even if you wanted to.