Relying on some blog or forum entries or anything shy of a vendor statement of support will fail the test component of a change management system (which is a critical component of the application rollout). That can result in a red flag on a Sarbanes-Oxley, SAS70, or other audit. Corporate management would not be pleased.Also, many mid-sized and larger firms have internally written applications; nothing on the 'net will discuss those.
SOP is to bring in a few copies of the software, preferably for free but that's not always an option, do an applications inventory, and do compatability testing between the two. For many companies the cost of the staff time for the inventory & testing will far outweigh the cost of the licenses for the test machines. As many companies use a mix of mass-market (Windows) and proprietary/vertical market applications, people from all business units will wind up getting involved in the testing.
My personal opinion is that any new software product, be it from Redmond or elsewhere, should be left out in the sun to dry for a bit before you even bother to test it. Wait for three or so months or until the first round of patches has been released. Then test against the patched version as it likely will have fixed any glaring issues, which will speed your testing. It also lets those who do adopt early work out the kinks in a deployment strategy, letting you use Google to help find eficient methods for deployment.
Especially when it comes to a desktop operating system, this isn't easy. My employer spent months doing the inventory & testing. In the end, though, it was worth it as the deployment went very smoothly.
[ Parent | Reply to This ]