I can give an in-depth explanation for migrating from Windows 2000 to Windows XP for a similar number of computers when I was a network admin at a school.
One of the initial blockers was hardware - we were updating our computers in cycles rather than all at once, so many of them were simply not powerful enough to run Windows XP. You could easily forsee a delay of several years due to this alone.
Then you have the domain controllers. We actually stuck with Windows 2000 Server on them for a while, but really they should have been upgraded to server 2003 to be properly managing Windows XP clients. Upgrading the server OS means training your network admin staff, moving over any configuration or scripting that relies on deprecated things, re-creating your software deployment chain to use the latest features available to you, and so on. For us this was maybe a couple of man months of work.
Upgrading the server OS in the MS stack typically means you're simultaneously upgrading a lot of the other software too, such as the email server, so there's all the testing you would expect from such an initiative.
Next you need to re-create your base image that will get installed on all the computers. This could require months of testing because it's quite hard to get a base image running on all of your computers if they aren't identical hardware. This part also covers the sort of things you would expect in doing an upgrade on your personal computer, such as finding new device drivers (probably not an issue going from Windows 7 to Windows 8). I think this part took us 5 or 6 iterations, which worked out as about one man month of work.
Also on the desktop side your admins have to know how to use the new OS - a lot of the control panel changed in XP for example so we had to learn all that. (Of course by this time XP had been out a while and we knew most of it quite well already)
Once you have a working base image you need to update your group policy, as a new OS brings new settings, so you have to ensure everything is suitably locked down.
Then you have to actually test doing mass roll-outs of that image and applying the policy and make sure it works across your entire spectrum of hardware (multiplied by number of policies you have if they differ across some hardware, multiplied again by differing user policies).
Next up is making sure all your software actually deploys correctly on your new images. This is a great opportunity to upgrade to the latest versions of any software that's lagging behind a little (which may well be necessary if any of your software fails to run on the new OS). This was probably the most tedious and frustrating part, especially when applications aren't available as .msi installers as that makes the process for deploying them far lengthier.
Then of course you need to test all the software you deploy to make sure it still works.
Finally you can train users, decide on a good downtime window to do the deployment (and make sure you have a rollback plan for when it inevitably goes wrong), and then roll it out!