I recently caught up with a former IT manager at my company, Prowess. He was involved in everything at our medium-sized company. He helped upgrade our primary SAN, roll out our VOIP system, virtualize a chunk of our server infrastructure, and was the primary force that got ourMicrosoft Windows 7 migration done. He was awesome. But our discussion got me thinking. First, I need to hire this guy back on, which we’re doing. And second, what a three-ring circus OS migration can be.

Specifically, migrating to Windows 7 is no casual undertaking, especially if you’re making the leap from Windows XP. It is not an arbitrary rip-and-replace proposition for any organization. At home it might be a slightly different story, but many of the same challenges exist. You need to plan and make a series of calculated moves that might keep you on an existing operating system longer than you might have anticipated.

By no means am I advocating that people keep an operating system forever. There are lots of good reasons to stay on top of changing technology. But what I am arguing is that the move has to be systematic and well thought out, and you have to be prepared. Based on feedback from our customers, most organizations are not ready to move. They are waiting for a number of factors to come together, and when they’re good and ready, they’ll move. This is contrary to a lot of articles from analysts and journalists saying that “this is the year.” If by “this” they mean 2015, then they might be right. Why? There are five big things to consider.

Application compatibility has been a problem since Windows Vista started to be discussed, much less released. Microsoft was forthcoming about it. Customers were frustrated by it. But it was accepted as reality and part of the trade-off for advancing technology. Windows 7 uses the same core OS foundation and therefore has the same challenges as Windows Vista from an application compatibility perspective. This isn’t news.

The problem is that many people chose not to deploy Windows Vista and skipped all the positive IT activities associated with keeping pace with changing operating systems. I don’t mean to imply that you have to deploy each and every OS released, but if you or your IT people are testing and evaluating, you’ll know what to expect and what has to happen in order to execute a migration successfully.

This is a tricky one. You probably thought that by making a Web application you were going to avoid OS-related platform dependencies. Since this all happened during your years running Internet Explorer 6, you developed for IE6 and now IE8 has all kinds of compatibility issues. And it isn’t your OS. It’s the browser you’re stuck with in your OS. Your app will run fine in IE6, but there is no way to run that on Windows 7.

Although this isn’t a Windows application, it’s a Web application; you’re still left with two options:

Again, most of our customers opt for the former. The latter usually involves some form of application virtualization or desktop virtualization. Both are expensive, add lots of management, and require more computer resources.

If you have XP workstations that are five years old, it is probably a bit optimistic to think that they’re going to run Windows 7. Fortunately, most organizations are prepared to trade up. Hardware is less something to really worry about, but it is something to approach intelligently. You want to think both in terms of the immediate (consider how you are deploying and managing the systems) and in terms of the future (determine whether your future will include any aggressive new technology like desktop virtualization).

You don’t necessarily need to be perfectly standardized on a model to have perfectly replicated, systematic deployment processes. You should be able to deploy one standard image to any piece of hardware or virtualization environment without blue screens, error messages on startup, or any of the other typical problems. Use this time to find better ways to do things.

And if your future does have some new technology in it, buy the power now. As long as you’re procuring hardware, get an extra gig or two of RAM. The cost will be incremental, but the long-term savings in time, flexibility, and preemptive problem solving could be monumental.

This is a big one. You’ve probably already done something about this. You probably need to do more and know it. Getting Windows to an end point both quickly and easily has been a near impossibility, historically.

Assuming you have addressed applications and hardware, you still have a couple major considerations. Specifically, two big ones are:

Fortunately for migration, there are lots of free tools that work reasonably well. The Microsoft User State Migration Tool is fine. There are lots of third-party tools that work great, as well, using varying degrees of automation and technical sophistication.

Imaging and deployment, however, have historically been the ultra-geeky domain of IT rocket scientists, but it doesn’t have to be. And the old solutions everyone has relied upon are hard to quit because you know them. It’s like that old remote control that you have to shake to work, but you know where the buttons are even though the labels have worn off, so you tape the cover on to the back and keep using it.

Well, throw that remote away.

My two cents: Drop the sector-based imaging solution. Explore other options.

The “free” tools from Microsoft can do amazing things. The Windows Automated Installation Kit(WAIK) can allow you to work magic. And Microsoft also provides the Microsoft Deployment Toolkit (MDT) to help guide you in your use of the WAIK. The drawback is that the only thing that is free is the download, as you are back in rocket scientist territory. You will invest a ton of time in a system that will probably frustrate you back into using your old sector-based imaging solution. Or you will implement the new tools so rudimentarily that you get only a part of the value out of them that you should.

The good news is that there IS a better way. It requires thinking about deployment differently, but not much differently. As a first step, embracing virtualizing and making your reference computer a virtual machine is a critical step.

You should worry only about future versions of Windows insofar as you have to keep up with them as described above. There’s talk of a Windows.next beta in September with previews at WPC in July. Great. Fine. Just have someone start poking it and pushing it around. It doesn’t mean you actually have to use it or should scrap your plans with Windows 7 to wait for the next-great version. But you should still commit to keeping up.

These kinds of projects seldom go perfectly, and there’s no way to anticipate every potential problem. Just take your time and be calculated. If your apps all work, or you can at least make them work, and you are happy with your hardware plan, start building images and factor migration of user data into that plan while you keep an eye over your shoulder for what’s next.

IT is at an interesting inflection point today with new operating systems, a hardware refresh wave, virtualization coming to the desktop, and other trends like the consumerization of IT. As an individual involved in evaluating and influencing the course of your IT strategy, you should carefully evaluate all your options. And, specifically, as you migrate to Windows 7, if you address the key points in this article you’ll save a lot of potential pain along the way.