Skip to main content

Getting Started with Application Compatibility in a Windows Deployment

This article explains how to begin the process of evaluating the impact of application compatibility in your deployment project. You will learn how to make an inventory, prioritize applications, and identify which applications are to be included in a specific role-based deployment image.

In this article:


Getting Started with Application Compatibility in a Windows Deployment

If you have worked on an operating system deployment project in the past, you might remember application compatibility (app compat) as the source of many of the greatest challenges you came across. It can require the most effort, take the most time, and generate some of the most serious blocking issues. If you are working on an operating system deployment project for the first time, you might have heard horror stories about app compat; or perhaps you have heard nothing, and the scope of the work might be a complete surprise. Whatever your situation is, with proper planning, the project can become significantly more predictable and manageable.

The important thing to keep in mind is that app compat is, fundamentally, a risk-management activity. The higher percentage of applications that are (statistically speaking) likely to fail, the more work you should invest in proactive testing to help ensure that a critical application is not one of those applications. As this percentage decreases, the number of applications for which exhaustive testing is worthwhile shrinks. That means that if you are migrating from Windows XP with users who are primarily local administrators, you should expect a reasonable percentage of your applications to potentially fail, and plan accordingly to invest more to manage that risk. If you have already done the work to migrate to Windows 7, you should expect that very few applications are likely to fail, and plan to invest less since there is less risk. (Of course, as always, you should trust but verify.)

Managing that application risk, however, begins with understanding precisely what that risk entails—and that means understanding what applications you have. This all begins with building or updating your Managed Application Portfolio. If you don’t have one of these, you are certainly not alone, but now is the perfect time to build one. Ideally, you will continue to maintain this list after the deployment project is complete in order to enhance your agility. It is this list that represents what you are going to take accountability for in order to help ensure the functionality of your environment as that environment changes. You are issuing insurance policies for those applications, so understanding how much risk you are insuring is really the only sensible approach!

This document helps you understand the steps you should take to prepare for your app compat testing and evaluation during a Windows 8 deployment project. In many cases, however, the principles described here are universal and apply to migrations of any platform. After you read this, you should have a clear idea of where to start evaluating the impact of app compat on your deployment project, as well as some of the specific skills and techniques you will need to get started and be more effective.

Back to top


Understanding the Application Compatibility Challenge

At the core of the application compatibility challenge is the law of large numbers. Organizations can have tens of thousands, or even hundreds of thousands of desktops. Each endpoint can have dozens of apps installed, and you might not even be aware of what is installed (particularly if users are local administrators). So, by the time you consider each of these desktops, it is possible to have hundreds, thousands, or even tens of thousands of unique apps installed across all of your desktops. And that is just Windows apps! When you consider web applications, you then have to account for every unique website in the world, because it’s plausible that quite a few web apps from various locations inside and outside of the organization have worked themselves into a productive workflow somewhere within the company. The numbers really start to explode, and if you’re not careful you can end up absolutely paralyzed with fear because of the massive number of moving parts involved!

That’s why you have to be pragmatic. And why what you are offering is an insurance policy. As the environment and the world change, you are insuring that some of the software people are using will continue to run. But it’s not terribly fair to you to expand what you insure to include any application any user manages to install, or any website that user manages to find and navigate to, regardless of quality or durability. Rather, you need to define some categories. What software are you going to ensure works immediately, regardless of change? This software costs you more to guarantee, since you have to execute a structured verification process, but is necessary for your most critical applications.

Next, what software are you going to ensure works, and if it fails you’ll take the call and fix it? There is still a cost when things fail, but you only end up paying against those apps that fail, rather than paying for everything (even when the majority are likely to work). Next are those apps for which you make no guarantees—users are free to use them, but if these apps fail users are on their own. Finally, you have the category of apps you’d really prefer users didn’t use at all, and you might, in fact, take some steps to help prevent them from doing so.

outline of steps>

As soon as you start applying this framework, it begins to change your mindset. You might be willing to insure one version of an application, but are you willing to insure every version that anyone happens to be running, with the highest service level agreement? In most cases, no. And this is what you want to execute: a process that determines which applications you should be investing more in, performing that investment to manage your risk, and then migrating to the newer platform.

The risk you are hoping to manage is that of business stoppage as a result of application failure. Many of the applications you are running will be compatible with Windows 8 (particularly if you are already running Windows 7). Some, however, might have issues, which can vary in severity – anything from an app "just not looking right" to a menu option not working at all to an application crash.

So, where do you start? Our most successful customers use this approach:

  1. Discover the applications you choose to care about: start with the applications you are already centrally managing, and add any additional applications that you are not yet centrally managing.
  2. Rationalize the applications to insure that the managed app portfolio hasn’t grown so large as to become unmanageable, and to categorize and prioritize to drive your app compat project.
  3. Test the applications to validate that the business functionality you require still functions correctly on the new platform.
  4. Remediate any issues you discover, which might include using built-in compatibility features of the platform, changing a policy to allow the failing behavior, upgrading or replacing an app, and sometimes even retiring the app.

This article focuses on the first two steps: discovery and rationalization. At the end of this process, you can generate your budget and plan to move forward with the project, so it’s very important to execute these steps well.

Back to top


Application Discovery

In the past, "Application Discovery" has been called "Application Inventory": the shift to using the phrase "Application Discovery" is very intentional. We found that the word "Inventory" drove customers to believe that they had to find absolutely everything that was running in the environment, and feed that complete list into a rationalization process. And you know what? You could kind of get away with that for installed Windows applications. (The largest inventory of installed Windows applications we are personally aware of is 130,000 applications. That’s too big, to be sure, but it’s not so big that rationalization isn’t possible.) However, a platform migration to a new version of Windows also normally includes a new version of Internet Explorer. How big is the list of unique URLs navigated to by everyone across an organization? Huge! Many customers also upgrade the version of Microsoft Office they are using during the migration (Chris Jackson discusses the mathematics of doing a complete inventory and rationalization of Office documents in his TechNet Magazine article " Microsoft Office: The Mathematics of Office Compatibility." As you can see, it really often doesn’t make sense to find everything. At the same time, you do want to discover those items that represent genuine business risk during the migration!

The process of discovery depends on many factors, including:

Managed or Unmanaged environment: Managed environments are much easier to perform discovery on because you generally control which applications are installed on managed computers and, therefore, you are already aware of them. You begin with a list of supported and approved applications, as well as details on how many computers they are installed on (and perhaps even how much they are used). An unmanaged environment is more challenging, as you often begin the project unaware of what applications are being used, particularly those that users have installed (and sometimes even created) on their own. Most organizations fall somewhere in the middle: they have some centrally managed and supported applications, and a number of applications that are treated as exceptions (and many they are not even aware of).

Centralized or Autonomous IT: Organizations with a centralized IT infrastructure have an advantage in application discovery because they are already aware of, and in contact with, all the departments within the organization. Decentralized IT infrastructures offer more local agility, but executing the discovery task requires more coordination as you consolidate information and strategy across organizational, cost center, and geographic boundaries.

Available Managed Asset Inventory Tools: Organizations with a managed environment often already have a software asset management tool, such as the Microsoft Asset Inventory Service (a tool available through Microsoft Desktop Optimization Pack for Software Assurance) or Microsoft System Center Configuration Manager. This tool might already contain the list of software that is actively managed. Some customers choose to maintain a separate list of managed and supported software, such as Microsoft SharePoint or Microsoft Excel. Those who are currently unaware of which software is running, or who fear that their managed software inventory might be incomplete, often look to additional tools to create or supplement that list. A straightforward way to inventory is simply to ask business units; but in some organizations, doing additional legwork before asking can greatly increase compliance from business units. Microsoft Application Compatibility Toolkit provides an inventory collection tool for installed Windows applications (as well as web add-ins) for this very reason.

Scope: The number of computers within an organization is certainly a factor when doing application discovery, but it is not the only factor. The number of unique roles also determines the variability in software used, and might increase the amount of work required to help insure that all business functionality will still work after the migration. With highly autonomous users who are able to install their own software, there might even be significant variations within a role; determining which of these variations is essential to the organization, versus which variations merely add unnecessary complexity, can be a challenge.

Performing manual discovery

In an ideal world, business units should be coming to you. After all, they are the ones asking you to insure these applications against failure in a rapidly moving technology environment. So, doesn’t it make sense that they at least tell you what they would like for you to insure? Chances are, though, that’s not happening (yet), so you’ll have some work to do.

For very small organizations, it might be more expedient to speak with users individually, and perhaps spend some time looking at their Start menus to see what they have installed and talk about which apps are critical and which ones are "just there."

For most organizations, however, visiting every user is completely impractical. A popular approach in this situation is to choose a representative from each department or role to do the job of reporting on the software required to do that job. This role goes by many names—for example, Department Technical Coordinator— but it must be someone who understands not only the business, but also what software drives it. You can work with this person (or people) to build the list of applications required to perform that aspect of the business.

After doing any work to complete this list, you might also consider building formal processes to add, review, and retire applications from this master list—and building these processes to be as friction free as possible to encourage business participation in your software asset management efforts.

Automating the discovery process

Since application discovery involves matching software against business value, it’s a process that can’t typically be completely automated. However, in many environments, business users and department coordinators might not be aware of everything that is driving the business. If you are taking your first steps toward software asset management practices within your organization, then managing the risk of missing something is a sign of a healthy partnership between business and technology.

If you have a managed environment, you might be able to obtain an up-to-date list of installed applications for the organization and for each department. This list can serve as a great starting point for these conversations.

If your application portfolio isn’t centrally managed, however, you might be looking for tools that can help you build this list and facilitate that conversation. Many customers choose to use the Application Compatibility Toolkit, which provides this functionality as a free download from Microsoft. The Application Compatibility Manager tool (among the other tools that are helpful in troubleshooting and remediating applications) can collect application inventory from either a subset of your organization or your whole organization.

Back to top


Rationalizing Applications

As you collaborate with the business to determine which applications should be classified as managed applications or supported applications (managed applications are specifically regression tested prior to change; supported applications do not have regression testing, but they do have support provided should they happen to fail in the new environment), you will need to make some hard decisions to determine which applications belong on which list.

The first review of your discovered applications is fairly straightforward:

Application version: Your organization has multiple versions of an application, including outdated and unsupported versions. Again, while some organizations will support more than one version in some circumstances, most actively manage only one—typically a recent version, if not the most current version. By selecting a single standard version, you might also be able to reduce your support costs.

Application redundancy: Your organization has more than one application performing the same task—most organizations might choose to support more than one in some circumstances, but actively manage only one. By selecting a single standard application, you might be able not only to reduce your per-license cost with higher volume discounts, but also to reduce your support costs by only maintaining one support contract.

Application necessity: Your organization has applications that are irrelevant to the day-to-day work being done in your organization. This is often a result of past changes to organizational strategy after which these applications were never retired. Most organizations simply retire these applications, and only occasionally choose to support them (though not actively manage them) in exceptional circumstances.

Not an application: If you are starting your rationalization process from an automatically generated list, you’ll likely find that many of the "applications" discovered aren’t applications at all—at least, they are not applications that you care about. Many software driver packages leave installation evidence in places most inventory tools look, such as the Add/Remove Programs list. You’ll want to clear these out of your list before you begin your conversations. You might also spot applications you’re never going to care about and don’t need to bring to the discussion with the business folks you are rationalizing with; these could include games or online gambling applications that many customers find users have installed.

With this list trimmed by removing the obvious candidates, you are now ready to begin having productive conversations with the business. In these conversations, you want to validate that the list is complete and ensure that you are applying an appropriate amount of risk management toward these applications by understanding the criticality of each application. Although the individual terminology might vary, here are some commonly used priority levels to consider:

Business Critical: An application that stops a department, role, or even your entire organization completely if it fails. This is a very high bar to meet, and only a few applications for each customer fall into this category! Business-critical applications often have service level agreements (SLAs) that state that support staff must respond to a failure within 15 minutes or less. Business-critical applications always fall into the "managed" category, and require structured testing prior to a migration.

High Priority: An application that performs a vital role in a department or across an organization. A failure in a high-priority application might disable a department or a single business function in the organization. If a high-priority application fails, the organization can continue doing business, but one or more departments might be seriously hindered. A typical SLA for a high-priority application is measured in hours. High-priority applications typically fall into the "managed" category, and require structured testing prior to a migration.

Important: An application that is used frequently, but will not cause a stoppage of work if it fails. SLAs for important applications are typically measured in days. Important applications typically fall into the "supported" category, and rely more on organic testing and pilot testing than formal testing except in exceptional cases.

Optional: An application that is approved, but limited in use and not directly related to a core business function. Applications in this category are usually not covered by an SLA, and support would be considered "best effort." Optional applications fall, at most, into the "supported" category, relying on organic testing and pilot testing rather than formal testing to identify failure.

Assigning priority levels to applications is often a subjective process, and as such might need periodic revision. We encourage formal software asset management practices, which maintain a team or committee to monitor the application portfolio even between operating system deployments.

Improving your software asset management proficiency can have other benefits as well. For example, many customers find that they are better able to optimize their licensing costs and reduce the risk of penalty for running unlicensed software. They also find that they can optimize their existing investments, and do more with what they already have.

Identifying business-critical applications

Some business-critical applications are easy to identify and some are not. If your organization does business through an Internet presence, word processing, image manipulation, and page-coding applications might be considered business critical. Business-critical categorization will vary by job role, too. To a call center, an application that monitors server stability might be considered critical, while other departments would place no value on it.

If your organization has a disaster recovery plan (DRP) or a business continuance plan (BCP) in place, the business-critical applications should already be identified in those plans.

Some criteria for identifying business-critical applications include:

  • The application represents a primary function of the organization (such word processing or design software to a publishing company).
  • The organization will suffer a significant financial impact if the application fails.
  • If the application fails during off hours, someone’s pager will go off within minutes.

Identifying high-priority applications

High priority applications might be easy to identify in your own department, but difficult to identify in other departments. Sometimes you can identify a high-priority application by the percentage of computers it is installed on, though this can be misleading. For example, an application that was developed internally to monitor the amount of toner in the company’s laser printers might be deployed to every computer but actually used (or considered essential) by very few people. If your organization has a DRP or a BCP in place, the high-priority applications might already be identified in those plans.

Some criteria for identifying high-priority applications include:

  • The application is used the majority of the work shift.
  • The application is used by a large percentage of users within the organization.
  • Without the application, it would be difficult for the organization or department to conduct business normally.
  • Without the application, daily operations would be affected and there could be a measurable financial impact.

Back to top


Mapping Applications to Roles

The concept of user roles can be instrumental in determining an optimal operating system deployment plan. Users within a given role tend to use much of the same software, and being able to begin deployment after completing the app compat work just for that role, rather than waiting until you have completed work on all of your organization’s software, can not only fuel the morale of the team (who now have a success metric to be proud of), but also drive important learning into subsequent roles that otherwise might not have benefited from the deployment.

Commonly defined roles/teams include:

  • Human resources
  • Information worker
  • IT support desk
  • Marketing
  • Developer
  • Executive

There are, of course, applications that are standard across all roles. Examples might include email and antivirus applications.

Deployment roles can also be prioritized to lower the effort required for testing application compatibility. Role-based configurations for critical operations should receive the most testing, and lower priority roles can receive lower amounts of testing—driving the concept of investing smartly in risk management based on the actual risk rather than an expensive, and ultimately unachievable, drive for perfection.

Back to top


Next Steps

The process outlined in this document should produce an application catalog for your organization that is prioritized in terms of testing required, specific user roles, and which applications will be deployed with Windows 8. This catalog gives you the raw information needed to progress to the next steps in the process. Using the information in your application catalog, your next steps should include:

  • Building the team: After you understand the scope of work involved in your organization, you will need to build the team to work through the technical and business decisions that need to be made. The size and scope of this team depends on the size and scope of your deployment. It might be that you are the project manager, test lead, and general go-to resource. Larger organizations will need a more formal team with well-defined roles. Guidance for putting together a team can be found in the Microsoft Deployment Toolkit.
  • Creating a test plan: The managed applications that you will be formally testing will require a structured plan for how to perform that testing. How much work will the technical team perform to discover compatibility issues? How will you administer user acceptance tests? These factors have a significant impact on velocity and cost.
  • Creating a test environment: Managed applications will require an environment in which to perform application compatibility testing against. Very often, this will be the same lab used to perform testing on the deployment images. Consider using virtualization software such as Microsoft Hyper-V as an alternative to dedicated computers for the bulk of application testing; this will help reduce hardware costs and simplify environment resets for the next application.
  • Remediating: Identify applications that have compatibility issues and find the correct remediation. Test the remediation to ensure that the issues are actually corrected. The Application Compatibility Toolkit contains information on compatibility issue remediation in its documentation.
  • Piloting: Identify members of your pilot deployment test group. You should pick people who represent each major role within your organization so that you can get valuable feedback on applications, particularly those applications that are supported (but not managed) and therefore weren’t formally tested prior to the pilot. Consider the place of upper management in the pilot group. Some executives who are technically savvy might elect to dedicate a computer to pilot testing.
  • Signing off on applications: As managed applications are validated through user acceptance testing, record each sign-off. Once all of the applications used by a role are certified, pilot deployments can begin, and can be gradually expanded until the entire deployment is complete.
  • Deploying: Once all managed applications are certified, then the process becomes mechanical – continue the deployment until you have reached all of the computers in the organization.

There might be other tasks involved as well, depending on your organization’s needs and culture. The decisions you make regarding the priority of applications and testing might also be affected by the structure of your organization. For example, you might want to include a step to reevaluate the list of applications to be deployed with the operating system to see if there are new applications that should be added.

These further steps are discussed in greater depth in other documentation, such as the Microsoft Deployment Toolkit.

Back to top

Top Tasks

About the Author

Chris Jackson photoChris Jackson, aka " The App Compat Guy," is a Principal Consultant and the Technical Lead of the Windows Application Experience SWAT Team. A widely recognized expert in the field of Windows application compatibility, Chris has created technical documentation, training, and service offerings used inside and outside of Microsoft based on years of real-world experience with enterprise customers and independent software vendors.

Chris is the author or co-author of numerous technical papers and articles on the subject of application compatibility, and a contributor to TechNet Magazine. He is also a featured speaker at major industry conferences around the world, including TechEd, IT Forum, and the Microsoft Management Summit.

Related Resources

Stay Informed