LOOK Before 26 BY FRANK J. OHLHORST T
he 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. 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.
A Little Research Goes a Long Way 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.
Test Everything! 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
WWW.MOREDIRECT.COM
VOLUME 3 • ISSUE 4
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36