Deployment Blocker No. 9: Carry all applications over into the new environment
Tempting as it may be to promise users that they can hang on to every single one of their old, familiar applications, there are three problems with this offer. The moment you announce you will carry everything over from the old environment into the new environment, the following will happen:
1) High priority applications, the ones that really drive your business, get precisely the same weight as lower priority applications.
2) Many applications which are simply not appropriate and never were appropriate will get dragged into the new environment, despite severe security issues or obvious duplication of functionality
3) You’ve tipped off stakeholders that you don’t really believe in change.
Application decisions and testing is where the rubber meets the road. Many environments begin the project by telling me they think (key word, think) they have thousands if not tens of thousands of applications running on their desktops. I’ve had customers draw up elaborate project plans showing it will take them several years to test each application, one by one, on Windows 7, and then throw their hands up in desperation. We’ve done scans of systems several of these large customers (50,000+ desktops) and discovered as many as 80,000+ unique executables installed on the desktops. None of this is unusual.
But here is what I noticed once we dug into what was going on: the vast majority of our customers, once they really sit down and comb through a recent, accurate software inventory, almost immediately drop between 60% to 80% of the applications from their list. They do this by first eliminating executables that are unique to Windows XP, replacing them with equivalent built-in Windows 7 features or Windows 7 compatible applications. Then they use four common sense rules of engagement:
- Replace older versions with a single (preferably the latest) version of each application
- Agree on a minimal seat count below which the business will not invest in testing and supporting an application. For instance, the business will not support anything installed on less than ten desktops, or fifty, or one hundred.
- Eliminate duplicate functionality, e.g. multiple versions of Antivirus or compression tools, or utilities whose capabilities are already integrated into Windows 7 (examples: zip compression, CD burning)—here is a chance to establish a standard for the enterprise
- Demand installation media. Require application stakeholders, those who want the application, to produce legitimate licensed installation media
The first two rules alone frequently eliminate over half of my customer’s applications, with few to zero objections from the various stakeholders. The third is really a matter of whether the customer wishes to establish some sort of enterprise standard for the most commonly utilized applications—some do, but some shy away from that despite clear cost savings. I’m big on standardization wherever it is possible, because I’ve seen such enormous savings result from it.
Do not demand the fourth step (gathering installation source media) before doing 1 through 3—cull through the list before making people go to the effort to find the CDs or it will simply annoy people.
Our experiences show that asking for installation media really drops the numbers. I have noticed that some of the most vocal application stakeholders drift away quietly when asked for the installation media. Suddenly it isn’t so important after all.
If an application is important, the customer ought to have the installation media. For those who continue to insist that they must have that missing application on the new OS, even when they cannot find the installation media, it is probably a true need. Examine the reasons and if it is agreed it is a priority, have a cache of funds ready to help people buy or upgrade to the latest compatible version.
A better way: Start with a fresh inventory, agree on basic rules and policies for software purchases going forward (e.g. it passes certain certifications, such as the Windows Logo program), and apply those rules rigorously. Scrub the list with the basic common sense rules listed above, and start controlling what new applications come into your environment in the future, if only in self-defense. Share the list frequently with the application stakeholders so they see how it shaping up and can protest if they see something missing. Keep things open and transparent as to why something got dropped—never delete items from the list, just filter them out and clearly explain the reasons for each filter. Don’t allow the application stakeholders to hijack the process, making it an exercise for personal preferences.
This is part of a ten part series of blogs “Top Ten Deployment Blockers”