How to move ADFS to new servers

It depends on your needs, if you need to provide SSO to your environment you should deploy ADFS. On the other side if you only want your users use their AD password to log on Office365 you should user DirSync.

In the fomer scenario the authorization is performed by your AD environment and trusted by Office 365. In the DirSync scenario is actually Office365 which will perform the authentication instead of your local AD.

Since your AD will be the main authentication system I cannot see a real reason to deploy ADFS instead of using only DirSync.

I've managed large numbers of workstations without AD. I had power tools (Altiris Deployment Solution), but it still hurt in certain situations:

1. Security auditor comes in and says that our default workstation password policy isn't good enough. In order to change password complexity and expiration, etc., on 5,000 machines, we had to write a (nontrivial) script and schedule that to run on all machines. (Good luck catching the laptops, by the way!)
2. Mapping department printers. Sure, we could use the IP number. That means that if Department A and Department B get into a printer war, the remedy involves staking out the printer and then following the offender back to their workstation to remove the printer from their workstation. (I suppose you could buy print management software instead.) Also, how did that printer end up on their workstation in the first place if they're not supposed to use it, and how will you prevent it from ending up there again?
3. There are registry keys for WSUS, so you technically don't need AD for patch management. However, if you include those registry keys in the image, you need to make sure and delete a couple of keys (SusClientID and PingID) or else they will never get updates ever. Or, to be more specific and accurate, only one of them will get updates.
4. Software installs. You can do these with power tools (LANdesk, Altiris, etc.), but that's extra money.
5. "Poison" printer drivers. I've seen a couple of these. The best remedy was a print queue with an updated driver.
6. Windows 7 printing would have epic tantrums unless we set allowed forest/allowed hosts in point and print restrictions. Perhaps this wouldn't be a big deal if all printers were ip-only, as long as User1 never wants to use User2's local printer. Without AD, our techs had to either use gpedit on the workstation or on the master image.
7. You're assuming cloud Exchange, but I'm also going to add that email migrations and other large infrastructural changes without AD are painful on the client end. I scripted the "remove software from old failed migration/add workstation to AD/migrate user's profile from local to domain/demote user from admin to power user/make changes to firewall" jobs and ran them through Altiris. (The Microsoft consultants were suggesting we hire temps with thumb drives until I showed them my kung-fu.)

Also, there are software vendors who look at you like you have three heads when you tell them you have workgroups rather than domains. Altiris runs in workgroups, but your desktop techs are never allowed to change their passwords, for example. (Okay, okay. They can change their password. But they also have to swing by your cube and type their new password into the server, or tell you what their new password is.)

What I'm getting at is: You can manage lots of workstations without AD, but you may need to buy replacement software, and even with nice software you'll run into painful things.