Enterprise Software

OS upgrade myths and Windows 7

Many IT organizations are resisting the idea of wide-scale Windows 7 deployments for reasons that are time-honored retreads of traditional points of view. Here's why you may want to step past those upgrade myths.

Despite recommendations otherwise, many CIOs and organizations are resisting the idea of wide-scale Windows 7 deployments. The reasons to avoid executing a Windows 7 upgrade are time-honored retreads of traditional points of view.  They are supported by the weight and wisdom of decades of OS deployment experience—not to mention the horror stories culled from thousands of failed projects.

The IT world follows these mythical tenets when it comes to OS upgrades:

Myth 1:  Never deploy software, especially an OS, before its first patches/service pack

Myth 2:  Never deploy a new OS onto existing hardware

Myth 3:  Never engage in a large-scale/low-business value project in the middle of the worst economic climate of our lifetime.

Any one of the three "nevers" can stop any project from making it to the prototype stage, let alone proceed to actual pilots and deployments.  Each is, within the context it addresses, absolutely correct.  Each one is also self-limiting in several ways.

Myth 1:  Never deploy before the first patch/service pack

The first, and most time-honored, of these myths holds that all software is incomplete until the first patch comes out.  It acknowledges that customers are legion while developers are few.  No software company, no matter how dedicated, can hope to match the sheer problem-finding power of hundreds of thousands of customers using at a piece of software for a month or two.  The wisdom holds that once the company addresses this initial round of issues, it is safe for an enterprise to "test the waters."

While this is all true, it posits a very passive role for the IT organization.  IT in this case is unable to solve its own problems, unable to formulate work-arounds, and incapable of producing a working solution at the lowest possible cost.  Instead they have to wait for a vendor to come in and save the day.  This approach may have worked when companies had time and money on their hands, but today we need more from our organizations.

Myth 2:  Never deploy a new OS on existing hardware

Operating systems are notoriously difficult to debug, especially when it comes to the complex task of supporting every possible configuration of hardware components dreamed up by the computer industry over the last decade or so.  Deploying a new OS onto old hardware is just asking for trouble.  There's an off chance that it will work just fine, or even work better than the older OS did.  However, experience says that it is just as likely that something horrible will go wrong at the worst possible time—usually on the CEO's machine just before the meeting to get enough capital to see the company through the latest business cycle.

Yes, there are technical difficulties associated with deploying new software on old hardware.  However, the failure is generally not with the software.  Instead it lies with the IT department's passive approach, in which it has not a) formulated a clear set of expectations about what will happen during the deployment, b) outlined ways to capture deviations, c) established protocols for quickly resolving these deviations, or d) captured the knowledge gained from these resolutions to share with the rest of the team.

Myth 3:  Never deploy a high-risk/low business value product during an economic down-turn

Capital markets are incredibly tight, leading organizations to consider leasing en mass again despite the operational difficulties such contracts entail.  Profits are down, unemployment is up, and what little recovery the world has seen so far mostly amounts to a lessening of the rate of collapse rather than actual improvement.

In tough times like these, it's difficult to sell a "game changing" piece of software, let alone an operating system. Technical bits and aesthetics aside, operating systems do not as a rule change how people do business. They may make some things, like Search, easier, but they do not in and of themselves shift the work paradigm.

This approach is laudable, though it fundamentally misses the point.  Trying to do a new "what" (create new business value) while completely reformatting the way in which an organization does business demands a huge amount of change.  It's easier on the people involved to first suggest that they engage in something they already know and can control well in new ways—ways which can then be compared with previous experience to see if they had the desired effect.

In other words, the three IT tenets are valid, but they rise from a different age of IT, a different approach to business, and therefore not wholly useful in today's environment.

Is Windows 7 worth a different mindset?

In my opinion, Windows 7 offers some improvements over XP and Vista that make upgrading worth it, including:

  • Speed and performance-Windows 7 beats XP in all performance benchmarks
  • Compatibility-While you may be able to continue to run XP for a while, you run the risk of new devices not supporting the older OS. (For example, Windows 7 includes functionality for mobile hardware that will be invaluable.)
  • Security-Windows 7 provides much better "out of the box" security; it also doesn't suffer from the annoying UAC prompts you see in Vista
  • Design-Windows 7 offers a large range of customization options and features.

Tests run in the community comparing Windows 7 to older versions of Windows, including Windows XP, are very promising. The Gartner Group has lifted their long-standing ban on never recommending new software and has suggested skipping Windows Vista for Windows 7.

Furthermore, Windows 7 appears to have continued the evolution toward seamless migrations first started in Windows 2.0.  New features in terms of application compatibility, deployment options, hardware support, and user setting migration promise to make this upgrade even easier technically than the last one.

Whether to upgrade is a decision that needs to be made by the individual organization. But don't let some of the traditional upgrade myths hold the project back.

—————————————————————————————————————

Shannon Kalvar has fifteen years of experience in IT. His career has included stints as a developer, system engineer, enterprise architect, project manager and program manager with detours into being a writer and process designer. He has also produced a Windows 7 Migration Strategy Toolkit that offers tools for building a business case for a Windows 7 migration and the project tools you need once you decide to go for it.

Editor's Picks

Free Newsletters, In your Inbox