Posted by: Ed Tittel
Desktops, Enterprise desktop, Vista ACT, Vista ACT resources, Vista application compatibility, Vista Application Compatibility Toolkit, Windows Vista, Windows Vista SP1, Windows Vista troubleshooting
For the next couple of weeks, I’ll be digging into issues related to application compatibility for organizations and enterprises considering the move to Windows Vista. For such outfits, one of the most important and pressing concerns that surround a migration has to be application compatibility, which should perhaps be pithily restated as “Will my apps work with Vista?”
Microsoft is keenly aware of this potential hurdle, and has devoted considerable time, energy, and resources to creating tools, guides, and processes for assessing application compatibility. In some upcoming blogs, I’ll take a closer look at that company’s Application Compatibility Toolkit 5.0, aka ACT. In this blog, I begin the overall process of assessing application compatibility by describing that process as Microsoft sees it, and pointing to some papers, resources, and how-to’s that the company has put together to help companies and organizations see their way through it. Much of the information you’ll find here, in fact, is summarized from the company’s paper entitled “Getting Started with Application Compatibility in a Windows Deployment” (PDF document, 301KB).
In a nutshell, the process works like this:
- Collect information about current applications in use.
- Prioritize and rationalize applications worth testing for compatibility, and supporting after Vista deployment.
- Test a finalized list of applications in priority order as need dictates, and resources permit.
- Mitigate issues to make applications workable or replace them as necessary (Or as MS puts it: “remediate, upgrade, mitigate, retire”).
Centrally managed environments that have established standard desktop configurations and that control the applications allowed to run on those desktops will have the easiest time of the inventory stage. ACT includes an inventory tool, in fact, for environments that don’t already maintain one (such as Microsoft Desktop Optimization Pack for Software Assurance, Microsoft System Center Configuration Manager 2007, or SMS 2003). The idea is to put together a comprehensive list of every application and version in use on enterprise desktops.
The next step, which MS delicately labels “prioritize and rationalize” is the tricky one. This really means choosing standard versions for apps in use across multiple versions (what MS calls “application relevancy”). It also means choosing a single app when more than one is used to do the same job (such as multiple productivity suites, video editing tools, and so forth; MS calls this “application redundancy”). Finally, it means getting rid of unauthorized applications or those that, as MS puts it, “are irrelevant to the day-to-day work being done in your organization.”
After the winnowing process is done, there will be fewer applications to deal with. This is the point at which prioritization occurs, based on the relative importance of the remaining applications within your organization. Often, this means tossing names into buckets that might be labeled:
- Business Critical: essential to ongoing business operations. SLA response
- High Priority: perform vital roles in some departments or across the organization. SLA response
- Important: used frequently but won’t cause work stoppages if it fails. SLA response
- Optional: Approved applications in limited use not directly related to business functions. Not covered by SLA, and receive “best-effort” IT response.
The categorization process also involves identifying applications essential for business or operations to proceed, and for typical job roles to be enacted. Prioritization within buckets requires management buy-in and means tackling items from the top down, once there’s agreement on what’s on top, and how items are ordered from there.
Next comes application testing, which is where you’ll decide which applications can be made to work, and which ones may need to be retired and replaced. Ultimately, the idea is to work toward a collection of software components that get the necessary work done and that also work properly with Vista. More on this in my next blog!
For more ACT resources, check out
Just Released: Application Compatibility Toolkit (ACT)5.0.3
ACT 5.0 Deployment Guide
ACT 5.0 Step by Step Guides
TechNet Webcast: Making Windows Vista Application Compatibility Testing More Predictable
Webcast: Debugging for Application Compatibility Issues with Chris Jackson (interested readers should also check out Jackson’s Blog)
Windows Vista Application Compatibility Training Recordings