In the pre-Linux world IT departments migrated data to the current MS incarnation. Which was often concurrent with the hardware needing replacement for whatever reason. The applications were either the bundled MS or niche "suite concept" style with attendant learning curves. And it hammered tech support in grim fashions. Then it got worse. Having seen migrations from Win95 to present, we all have war stories to share. Some of them having avoidable Very Stupid Things. And then there are the migrations/refresh projects we saw go in smooth flow states. I have been cursed to suffer the botched projects. And blessed with some joyously easy ones.

The short list make or break so to speak centers on process preview and bottom back up to top feedbacks. Trying a dry run on a sandboxed desktop and/or network segment for example. Having a "THIS IS STUPID" feedback channel/s With an inviolable policy of *ZERO* risk in using it! IF folks fear saying Foo is an epic fail and why/how -it won't get commented on let alone fixed The last shortlister is granularity. Choosing your applications for interactions where practical- if possible.Some applications demand data conversion or unique servers. Where others are a painless import . So far there's a body of comment covering nearly everything I list here both on KCLUG and the rest of the web

MY little whack at these scenes is from NOT wanting anyone else to be still onsite at WtFthirty because some clue lacking exec decided pre-imaged drives were not worth it.Or that swapping a drive into new hardware and copying files with a tech onsite made more sense than using a USB copy the night before!

Same concept goes to installing Firefox and Thunderbird for your supported user base ASAP. So by the time you do give users a desktop lacking IE and Outlook-They won't curse at you :>

There is an inestimable gulf between the "one true path" dogmatic model and the "Best tool for the job" view.

Choose wisely or much wailing and gnashing of teeth will be the reward.