This is part 2 in a four-part series on key elements of a Windows 7 migration. Part 1 discusses the pros and cons of enterprise desktop migrations and whether Windows 7 is compatible with an organization. Future sections will cover migration tools and an inside look at Windows 7 licensing.
The decision to upgrade to Windows 7 may be an easy one, but the actual transition to Microsoft's desktop operating system can be a complex endeavor filled with unexpected complications, many of which stem from incompatibilities and underlying changes in the OS. Nowhere is this truer than with legacy and line-of-business applications.
Unlike commercially available software products, such as office suites and mainstream applications, line-of-business (LOB) applications do not follow the typical upgrade path. In other words, just because a new operating system enters the market, your LOB applications may not have available upgrades, especially if they are custom-developed apps for vertical markets.
It is best to check for compatibility issues under both 32-bit and 64-bit versions of Windows 7.
The simple solution to this problem is to rule out an OS upgrade, but while that may work for legacy apps, it may not be practical for the entire enterprise. Most businesses find Windows upgrades forced on them because of support issues, added features or new hardware deployments. That creates a catch-22 -- you must upgrade desktop OSes, but are unable to because of legacy application concerns, such as compatibility, reliability and serviceability.
While there is no simple formula for solving that problem, you do have options that can eliminate legacy application problems or at least make upgrades feasible. However, the first task should be to gauge the level of incompatibility, if any even exists.
Researching legacy applications
Gauging incompatibility, or in this case, compatibility, comes down to research and testing. You must contact a program's designers and find out if the product has been tested for Windows 7 compatibility and what problems (if any) to expect.
Further complicating the OS upgrade conundrum is the fact that many older applications were developed for 16-bit or 32-bit environments. In the past, that did not present much of a problem, because most businesses used 32-bit OSes, such as Windows XP and Windows Vista. However, most Windows 7 adopters will install the 64-bit version of the OS, which may not run 32-bit or 16-bit applications.
Simply put, it is best to check for compatibility with both 32-bit and 64-bit versions of Windows 7. But that doesn't mean you won't encounter any issues. Another serious problem can arise -- the software development company could have gone out of business or stopped supporting that particular application.
If that's the case, you have two choices: replace the LOB application (normally an expensive, complex endeavor) or research the development tool that was used to create the application. The second option may give some insight into the expected level of compatibility. If the original development tool is compatible with Windows 7, you may be able to run the application natively under Windows 7.
The testing phase
As important as research is, the real proof for compatibility comes from thorough testing of legacy apps. Each aspect of the application should be tested under Windows 7 before actual deployment. Don't overlook anything.
That means you should test rarely used procedures, such as quarterly or year-end processes, as well as reporting, archiving and other resource-intensive chores that rely heavily on full compatibility. Be sure to conduct those tests in a multi-user environment that provides an accurate representation of your actual production environment. Leave as little as possible to chance.
But what if the application fails to run natively under Windows 7? Fortunately, Microsoft created the Windows 7 Compatibility Mode Wizard, which can be accessed from the Windows Control Panel applet named Use an older program with this version of Windows. The wizard walks through a series of questions to determine compatibility settings, including Compatibility Mode, Run in 256 Colors, Run in 640x480 resolution, Disable Visual Themes and several others. You can also access those settings manually with the compatibility tab found under an applications shortcut.
For most applications, compatibility settings will do the trick. They control many basic options such as OS reporting, display settings and disk access. However, some applications may be buggy even under Windows 7's compatibility options. If that is the case, all is not lost.
XP Mode to the rescue
For severe compatibility problems, Microsoft offers XP Mode, a free add-on that can run an application under a virtualized version of Windows XP. XP Mode uses Microsoft's virtual PC technology to create a separate, complete virtual machine running Windows XP. Simply put, if the application worked fine under Windows XP, it will likely work flawlessly in XP Mode.
However, there are some caveats to XP Mode. First, it's a virtual machine, so you need to reserve space for a virtual hard drive on the Windows 7 system. In addition, make sure that you have adequate RAM to run the host OS (Windows 7) and the guest OS (Windows XP) and that your CPU supports virtualization.
With that in mind, having to rely on XP Mode may increase the cost of hardware, support and deployment. In addition, the legacy applications will have to be reinstalled under XP Mode and then distributed, which can complicate large-scale deployments.
The lesson here is not to dive blindly into a Windows 7 upgrade but to follow a plan to ensure compatibility and ease transitions. The steps are simple -- research, test, take advantage of compatibility tools if needed, develop compatibility plans, test again, pilot a deployment and then fully deploy.
ABOUT THE AUTHOR
Frank Ohlhorst is an IT journalist who has also served as a network administrator and applications programmer before forming his own computer consulting firm.
This was first published in May 2011