For any Windows XP administrators who haven't looked into application compatibility since Microsoft released Windows Vista in 2006, I have good news for you: Most vendors have updated their applications to versions that run on Microsoft's newer client operating systems. The only applications that haven't been recently updated are most likely from vendors that have gone out of business, or in-house solutions that no one has bothered to update.
Related: Windows XP Migration: User State Migration Toolkit
Of course, if your organization is still using applications for mission-critical tasks from vendors that are long-since out of business, you have additional issues. But for current applications, you can use the Microsoft Application Compatibility Toolkit (ACT), which is part of the Windows Assessment and Deployment Kit (ADK), to determine which applications might be problematic in a migration.
The current version of ACT (6.0) lets you assess whether the applications running on your organization's Windows XP computers will run on Windows 8.1, Windows 8, or Windows 7 computers. ACT has a built-in compatibility database that includes information gathered from users about their compatibility experiences. In addition, ACT includes compatibility fixes that let you run some applications that might initially appear to be incompatible on newer operating systems.
ACT lets you do the following:
- Collect an application, system, and device inventory to determine which applications are being run by users in your environment and whether current computers and devices are compatible with newer versions of the Windows client operating system.
- Analyze applications to determine if the application performs tasks while running that will cause compatibility issues when run on a specific version of the Windows client operating system.
- Configure and deploy compatibility fixes that will allow some applications that would otherwise be incompatible with newer versions of the Windows client operating system to run.
ACT uses a central database to store data, including information gathered about clients and applications. You can use the following versions of SQL Server to host the ACT database:
- SQL Server 2012
- SQL Server 2008 R2
- SQL Server 2008
- SQL Server 2008 Express
- SQL Server 2005
- SQL Server 2005 Express
Taking an Inventory
ACT's inventory collection functionality performs the following tasks:
- System inventory: Collects information about the client computer, including the amount of RAM, the processor speed, and the processor architecture.
- Device inventory: Collects information about devices that are installed on or attached to the computer. When run, this inventory task collects information that includes the device model, class, and manufacturer.
- Software inventory: Collects information about software installed on the computer, including version information.
Taking an inventory involves identifying computers on which to collect inventory, creating an inventory-collector package, and then deploying the package—which is in the form of an executable file. You can use Group Policy, Microsoft System Center Configuration Manager, or another software deployment tool to deploy an inventory package to the computers that you want to inventory. The inventory information collected on the clients is forwarded to the SQL instance that hosts the ACT database.
The accuracy of your inventory depends on how many computers on which you perform an inventory. The goal in taking an inventory is to get an accurate picture of which applications have been deployed in your environment, so that you can then determine whether any of these applications suffer from compatibility problems.
Compatibility Exchange
After you have the inventory information, you can use the Microsoft Compatibility Exchange web service to view compatibility information about applications that were discovered during the inventory process. The Compatibility Exchange provides information about applications that others have tested, as well as compatibility fixes that might exist for specific applications.
Using the Compatibility Exchange allows you to determine which of your applications are compatible, which will work with a compatibility fix, and which are incompatible with a newer version of the Windows client operating system without actually having to perform tests on each application in your environment. Unless your organization is using a unique set of applications, it's likely that the Compatibility Exchange already contains compatibility information for your deployed applications.
Compatibility Monitor
The Compatibility Exchange might not include information for every application in your inventory. In this case, you can perform compatibility testing by deploying the Compatibility Monitor runtime analysis package to a computer that hosts the application so that you can monitor the application during execution to determine whether it has compatibility issues.
The Compatibility Monitor looks for common compatibility problems, including the following:
- Problems related to User Account Control (UAC)
- Attempts to write to protected system files or locations
- Attempts to use deprecated .dlls, executable files, COM objects, registry keys, or APIs that are no longer available in newer versions of the Windows client operating system
- Use of Session 0
- Problems related to operating system version numbers
- Problems related to the use of the WOW64 emulator
Compatibility Administrator
The Compatibility Administrator lets you create and deploy compatibility fixes and compatibility modes to allow some applications that are incompatible with newer versions of the Windows client operating system to run on those clients. You can use the Compatibility Administrator to view existing fixes, as well as to create new compatibility fixes and compatibility modes. A compatibility fix is a software layer that intercepts API calls from incompatible applications and translates those calls so that they can be processed by the APIs available in the more current version of the Windows client operating system.
In many cases, you can use an existing compatibility fix to resolve an application compatibility problem without having to create a custom compatibility fix. In previous versions of ACT, compatibility fixes were called shims. Although the Compatibility Administrator can help resolve common compatibility problems, there are cases in which an application that was designed to run on Windows XP simply can't run directly on a Windows 8.1 or Windows 7 computer.
Application Use
In planning your migration, a final application compatibility factor to consider is application use. I remember hearing a story about a large Australian company that was planning to move from Windows XP to Windows 7 but had approximately 50 applications on their Windows XP computers that wouldn't run on Windows 7. Eventually someone from the local Microsoft branch office asked the all-important question "How often are these applications being run?" After some further analysis, the company determined that only 3 of those 50 incompatible applications were still being actively used; in addition, those 3 applications were being used by less than 1 percent of the company's employees.
A Benefit of Procrastination
ACT is a complex tool. To use it effectively, you need to leverage the Microsoft Compatibility Exchange web service to find compatibility solutions for any Windows XP applications that are incompatible with Windows 8.1 or Windows 7. An advantage of postponing your Windows XP migration until the very last minute is that the likelihood is increased that someone else has already having faced and overcome your particular application compatibility problems. Sometimes it really does pay to procrastinate.
