As I mentioned in my first blog post devoted to Delphi XE2 release, the product has way more features than any past release. That's the reason why a long-awaited and very significant new features, like 64-bit support, faces the risk of passing almost unnoticed.
Another reason there is some risk of downplaying the new compiler and the updates in the RTL and VCL to fully support 64 bit, is that it works smoothly. There are some areas of your code you might have to revise, but mocing to 64bit seems significantly easier than the previous migration to Unicode, which took developers (and this party tool builders) somewhat off guard.

Why Moving to 64bit?

First of all, let me state that only a fraction of Delphi applications badly need the new 64bit compiler. Applications eating up a lot of memory and applications that need to inter-operate with other 64bit programs (either calling 64bit DLLs or getting called by 64bit applications) are two categories for which migration is a must. Most other programs, however, won't have a direct benefit. 64Bit applications are not automatically faster than their 32bit counterparts.
However, it is true with most computers shipping with 64bit version of Windows, uses are asking for 64bit applications and now Delphi developer can deliver those without too much trouble.

Migration Issues

As I mentioned, migration is quite smooth, but not totally automatic. Since pointers and references change in size, but Integers don't change, whenever you are casting between these types your are going to get in trouble. The most obvious solution is to cast to the NativeInt type, which also changes depending on the compiler version. This way your code keeps working OK on both 32bit and 64bit compilers, without having to resort to IFDEFs. Similar issues can appear in Windows API calls, since buffer pointers but also message paraemters move to 64bit.
Other troublesome areas are more subtle. First, calling conventions are now ignored, as there is only one option. No need to change the code, though. Second there are low-level differences in exceptions handling and the way stack frames are managed. Third, code uses relative jumps (that is, Win64 uses Position Independent Code) rather than patching the jumps on loading (also related with libraries relocation).
Some of these changes and the goal of making Delphi as cross-platform as possible have prompted the R&D team to ask developers to remove (or at least reduce) assembly code. While there are technical issues involved, asm support has not been totally remvoed from the compiler, but you'll need different code from the 32bit version. Unless the speed gains are vital, moving to "pure pascal" should be the standard path.

Still Pending

A few issues are still pending. Slowness in the some floating point operations can be bypassed using a new directive. The FastMM4 memory manager has some extensions that are now available but didn't ship with the product (see this blog post).
But the big issue, once again, can lie with third party component vendors. Until all the components you use are fully 64bit compatible, you might want to wait converting your own code. At the same time, you should really insist they get out a 64bit version soon, because if they don't get request from customers they might be tempted to put their time in other projects.

The same is true also for your truly. Unless I get a lot of requests, I might not work on a book covering Delphi 64bit, as I'm putting my priority on FireMonkey!