Although I'd personally recommend moving to 64-bit as soon as possible and just bite the bullet sooner rather than later, it won't be without impact to your IT support team. If the support team's bandwidth is already stretched to a maximum (i.e., already understaffed), then I'd actually consider waiting.
So, this is one answer that concerns human resources, not just software in/compatibility.
The roll-out should be of course carefully planned (preferably gradual rather than all-at-once). There are going to be issues "discovered" that will take hours to resolve on a per-user basis. Once the more common issues are identified, "how-to's" can guide faster resolutions for both support calls as well as self-service.
Mostly, (for example), I'm thinking of all the 32 and 64 bit (in)compatibility issues between the OS, a specific software package and the associated plugins, such as having both 32-bit and 64-bit browsers installed (and/or multiple browsers) on a single 64-bit OS, shortcuts for 'run as admin' vs 'run as normal user', having options for both a 32 and 64-bit plugin for those browsers (or sometimes maybe restricted to only 32-bit plugins which only work in one version of the browser) -- all that break applications and workflows built on top of those plugins. (By "plugins" I mean anything from Java to flash to embedded pdf readers to web conferencing software -- either built in-house or widely available, both commercial and free.) You can attempt to test for all of these issues, but it's hard to predict if a user will inadvertently install plugin B before plugin A, which causes a different result than another user who installs plugin A before plugin B (basically it's always hard to predict what damage users will do when their actions change the state of the system.)