Managing Application Readiness for Windows 8

Step 1: Application Discovery

Application discovery involves creating a list of applications you consider to be managed apps; apps which you need to validate on the new platform prior to deployment. As you continue to evolve your Software Asset Management (SAM) capabilities, the dimension that has the biggest impact on an application compatibility project is the prioritization of applications. The ideal state is to be able to place your apps into one of the following categories. (Although you may call them something different, what is important is the behavior each category drives.)

Managed Apps: These apps are considered business critical, and therefore require proactive testing to manage the risk when the environment is changed, and more testing is required in response to higher risk migrations. You should discover all managed apps before beginning the migration.
Supported Apps: These apps are important to the business, but they can be addressed during the pilot phase. While you may be aware of many of these supported apps, it's not critical that you have discovered every one prior to beginning a pilot.
Unsupported Apps: These apps aren't supported by IT, and therefore you don't need to be aware of them. You won't necessarily go out of your way to remove them, but users are responsible for their own support of these apps.
Banned Apps: These apps are ones that you will actively try to remove from the environment. New technologies, such as AppLocker, can help enforce bans against these apps. While you may need to be aware of these apps to implement a ban, you don't need to discover them through the application compatibility project.

In some cases, it makes sense to start this discovery process with an inventory of applications, ensuring that you have discovered everything that ought to be managed. In other cases, it's more sensible to build a list manually by just asking users. (This is particularly true in the case of platforms for which the apps list is sufficiently large to make rationalizing that inventory impractical, such as web URLs where a true inventory of unique URLs visited can often reach the tens or even hundreds of millions.) It's not imperative to discover every app that anyone has installed or used; "leave no stone unturned" is not the approach you want to take. However, it is important to discover all (or nearly all) of the applications that ought to be managed. (It's okay if you miss a few—it happens. Just don't forget to make a note of those apps for next time!)

Fortunately, there are a number of tools available that can help automate the process of collecting an application inventory. You can use Microsoft's free Application Compatibility Toolkit (ACT) or, another inventory mechanism such as Microsoft System Center Configuration Manager or Microsoft Asset Inventory Service. To make your managed apps list most useful downstream, you should ideally capture more than just the application name. Information about who is using an application, what the user's role is, and how important that application is to the user can be very useful both for this migration and for ongoing SAM activities.

The discovery process can also help you identify widely used applications you may not currently manage. You'll want to get these into your orbit so you can ensure they are properly managed, on the approved version, and have the required software updates.

Step 2: Analyze Your Applications

How many applications do you currently support that have been replaced or have otherwise fallen out of favor with business users? If you're like most organizations, a sizable number of them or, in some cases, most of them. Once you have completed your application discovery and have a good "lay of the land," the next step is to scrub your list of managed apps and filter them down before you undertake the time-consuming—and costly—the process of regression testing. Some applications should be demoted to supported apps and not proactively tested, while others may be promoted and now merit additional scrutiny during your migration. Set appropriate goals for your application portfolio. How many total apps do you want to manage, and how many are you able to support? At what point should an application be elevated to managed status?

After you set your goals, it's time to find the low-hanging fruit and narrow down the applications that need testing:

Eliminate redundant and unused applications. You'll undoubtedly find that you have several applications that perform the same function. Now is a good time to standardize on a single application per function, and eliminate those that have been made obsolete. One tip here is to try and map application dependencies, as you may need to support a legacy version of one application to keep another one supported by the ISV. And you'll want to drop those that are rarely or never used. You will make testing easier, and you might save on licensing expenses as well.
Remove multiple versions of the same application and standardize on the most current. In almost all cases, the newest version performs best and is the most secure and reliable. Again, watch for application-to-application dependencies.
Collect information from business users to help prioritize apps that are business-critical, and determine which departments are using which apps. This will be useful when you sequence your testing process; you'll want to align the timing of your testing to your staged rollout of the new desktop image.

Step 3: Assess Incompatibilities and Mitigation Options

The next step is to determine which of your managed apps work correctly on Windows 8. It's important to map out your process for performing this testing.

If an application requires vendor support, make sure your first step is to research the current state of support. You certainly don't want to pay for the rest of the process on an app you would never be willing to run! If you require support but the version you currently have is unsupported, then your next step is obtaining an updated version that is supported. Some people also choose to research vendor support even on apps for which support isn't required. If the applications are commonly used, you can usually find enough support statements to make this a worthwhile activity—and a supporting statement is a great prediction of whether the app works or not. Some customers choose to perform smoke testing by technical staff, static analysis using compatibility tools, and sometimes both. This technical testing can be very helpful in determining the compatibility of the packages and the applications.

The final arbiter of compatibility is always user acceptance testing (UAT). The user is the most important factor in determining that no bugs exist that effect user scenarios. The work is done before UAT is, in many ways, designed to simplify the process of UAT for the user, who is typically a volunteer whose cooperation is not assured.

Along the way, you may find applications that need some work to get them ready for Windows 8, particularly if you are migrating from Windows XP. At this point you have several options:

Replace the non-compatible application with a new version. This is certainly the most reliable method, but unfortunately, it is also the most expensive. If the application is business-critical or otherwise strategic to operations, this is the way you'll want to go.
Create shims for your existing applications. Shims are an application compatibility feature first introduced in Windows 2000 that allows you to modify calls to the underlying operating system. For example, there are shims that allow you to simulate an older version of the operating system, and shims that allow you to redirect file reads and writes to alternate locations. There is a small amount of management overhead since you'll need to maintain a shim database, but this approach is very powerful and can remedy many compatibility bugs. This is often the more cost-effective route and might be the only option if the application vendor is no longer around. One caveat: many vendors will not support shimmed applications. (Of course, if the application is supported, then you can just call the vendor and request an update—you don't need shims!)
Use Group Policy to change the offending behavior of the application. Modifying the system configuration using Group Policy can often take care of compatibility bugs, but doing so has some downsides. Essentially this approach uses policy to disable a particular feature or function that is causing the application to falter. Unfortunately, in many cases these functions involve the security of the underlying system, so the trade-off is significant. Likewise, the application must have Group Policy settings to enable this manageability.

For custom or in-house developed applications, you can modify the code. This isn't always an option, but if it is, there are great resources to help. Application compatibility cookbooks outlining the changes made between Windows XP and Windows Vista, between Windows Vista and Windows 7, and between Windows 7 and Windows 8. These cookbooks are available as free guides to help developers understand the changes to the operating systems in order to fix the bugs that are affecting compatibility.

Step 4: Prepare for the Operating System Deployment and New Application Delivery Options

The beginning of an operating system migration project is a great time to rethink how you package and deliver applications to your end-users. Application virtualization technologies have improved significantly and opened up options that may not have been available the last time you decided on a packaging standard; you should consider different models for application packaging and delivery before beginning the testing process. You might find that the savings in application packaging costs, along with savings in testing and readiness, more than offsets the cost of implementing a virtualized environment—while providing a more flexible and easier-to-manage application environment.

Virtualizing your application portfolio provides a number of benefits for manageability and flexibility, but one key advantage is that you minimize application-to-application conflicts. These conflicts arise when you need to run two versions of the same application simultaneously—for example, when the help the desk still supports multiple versions of an application, or when the finance the department is migrating to a newer version of its accounting software but needs access to the old one to close the fiscal year.

Step 5: Sequence Your Testing, Piloting, and Deployment Efforts

In Step 1, we talked about gathering additional information about your apps to help out later in the process. One really great way to take advantage of this data is to support a deployment process that allows you to build momentum and see success earlier in the process!

One of the most successful deployment methodologies we have seen is to deploy by role. Of course, deployment tends to wait until application compatibility is finished, so if you can identify which applications are used by which roles, you can focus on making all of the apps used within that role compatible first, and you can then begin deploying to those people. But which roles should you choose first? Considerations for making this choice often include how many apps are used by people who perform that role (so you can hit roles with a small number of apps first and see some early wins), or roles where a failure is more tolerable (so you can work in a less risky environment while you are learning your way).

Once you have tested the applications for a particular role, you can start a pilot testing within that role. You may encounter additional application issues along the way from your supported apps (hopefully not your managed apps, but if you do, you can always leverage your fallback plan), but as long as your help desk has the capacity to support those apps you can continue to expand the pilot until it eventually becomes a complete deployment. Role by role, you can make your way through the organization, working closely with the folks responsible for operating system image deployment to coordinate and continue to build momentum. Before you know it, you will have reached all of the seats you are targeting for Windows 8 deployment!