Applies to: Windows 8, Windows 8.1, Windows Server 2012, Windows Server 2012 R2
In this article:
“What’s our next project? Test our applications to get ready for Windows 8.1? No problem, boss. We just have about 950 apps that we need to consider…”
How well you conduct the application compatibility portion of your migration project can be the difference between a smooth rollout and a firestorm of help-desk calls, finger pointing, and late nights.
When companies began evaluating Windows Vista a few years back, application compatibility was the issue that stopped some dead in their tracks. Sometimes, critical applications simply were not available for Windows Vista. Other times, organizations did not have the budget or the desire to license the new version designed for Windows Vista. Finally, some had custom developed key apps, and the original developers were no longer around or not available to fix compatibility bugs.
If you are planning to migrate to Windows 8.1, you’ll find the application compatibility process much easier than it was a few years ago. If you are migrating from Windows Vista or Windows 7, most of your applications will work fine with Windows 8.1. If you are migrating from Windows XP, you will find that most independent software vendors (ISVs) have updated their applications to work with modern Windows operating systems, and you probably picked up versions that are compatible in the natural course of software updates. So whether you’re migrating from Windows XP, Windows Vista, or Windows 7, the situation isn’t nearly as tough as it may have been in the past.
That said, getting your application portfolio ready for an operating system migration can be a major undertaking. Taking the right sequence of steps and making smart risk-management choices to reduce the scope of testing can make the task much less daunting.
Back to top
So what changes were made in Windows 8.1 that caused applications designed for earlier versions of Windows to break? To be sure, the engineering teams responsible for Windows 8.1 didn’t take the issue lightly.
The changes to Windows were made to improve security, reliability, performance, and usability, and in some cases to remove legacy components that have simply reached the end of their useful life. We won’t take the time to catalog all of the changes in this article, but those most significant to application compatibility include User Account Control/standard user accounts and version checks.
Ever since Windows XP SP2, security has been a driving force for many of the investments in Windows. But, along the way, the engineering team realized a couple of things. First, all the security investments in the world can’t ultimately be effective if every user, and every app, has the ability to simply disable those features because they have administrator rights! Second, the team heard from organization after organization that it cost less—a lot less—to manage standard user accounts. But, they couldn’t just remove administrator rights and start saving money, because so many apps didn’t work when they did this.
So, during the development of Windows Vista, the engineering team set out to help address the application compatibility issues and empower organizations to deploy their users as standard users if they choose, granting local administrator privileges only to those who truly need them to get their job done, such as developers and IT administrators. These features were grouped together and called User Account Control (UAC). Despite several helpful automatic fixes to software, the process still required some manual fixes, and there remained some applications that required code changes.
If you have been running Windows Vista or Windows 7, most of you have already overcome this obstacle, and now have a software portfolio that can run without admin rights. But, for the minority of organizations who disabled UAC and ran users as administrators, there is reason to consider revisiting this decision now, before migrating to Windows 8.1, as this feature is a prerequisite for Windows 8.1–style immersive applications! Those of you who are migrating from Windows XP are likely to be have most of your users as local administrators, and you are likely looking to reduce the number of users where this is the case.
Apps that were written expecting admin rights are sometimes fixed automatically, but quite a few need to be addressed manually, using the application compatibility shims added as part of UAC. Still others require modifications to the code to break very deep dependencies on admin rights.
The single biggest application compatibility impact, out of all of the changes we made to Windows 8.1, is the fact that we changed the version number. And we didn’t even change the major version number—we still have a major version of 6, which has been true since Windows Vista! After fixing all of the version checks for Windows XP, developers wrote new version checks for Windows Vista. After fixing those, developers wrote new version checks for Windows 7! For some reason, developers just can’t break that habit. We certainly look forward to a day when developers correctly check for “x operating system or later”; until then, it is at least a relatively easy issue to mitigate with application compatibility shims.
Back to top
Like most projects, an app readiness project becomes much easier when you invest the time to break down the challenge into logical, manageable tasks.
You may be accustomed to seeing application compatibility divided into three primary steps: Discovery, Analysis, and Testing/Remediation. However, we would like to add two more steps: Virtualization and Orchestration.
The first step is application discovery, which involves creating a list of applications you consider to be managed apps and which, therefore, 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 prioritization of applications. The ideal state is to be able to place your apps into one of these categories (although you may call them something different, what is important is the behavior these categories drive):
If you are relatively evolved in your SAM capabilities, you may be able to simply query your application database to return the list of managed applications. However, many organizations are not able to do this type of query today. As a result, many organizations must begin the discovery process by manually creating a list of managed apps.
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 that list manually by just asking. (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 this time—it happens. Just don’t forget to make a note of those apps for next time!)
When you determine it makes sense to collect an inventory, fortunately there are a number of tools available that can help automate the process. You can also use Microsoft Application Compatibility Toolkit (ACT), available as a free download. Or, if you already have another inventory mechanism (such as Microsoft System Center Configuration Manager or Microsoft Asset Inventory Service), you can use that as a starting point.
To make the managed apps list most useful downstream, you will 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 has a side benefit of identifying 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.
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—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—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:
The next step is to determine which of your managed apps work correctly on Windows 8.1. 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 support 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 affect user scenarios. The work 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.1, particularly if you are migrating from Windows XP. At this point you have several options:
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. There are 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.1. 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.
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 desk still supports multiple versions of an application, or when the finance department is migrating to a newer version of its accounting software but needs access to the old one to close the fiscal year.
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 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 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.1 deployment!
Back to top
Readying your application portfolio for a migration to Windows 8.1 can be a major undertaking, but fortunately there are a number of tools and an abundance of guidance to make the process more streamlined and manageable. We have just scratched the surface in this article; if you’re ready to dive deeper and get the process rolling, a great next step is to visit the
Windows Application Compatibility top task page on TechNet, download the
Application Compatibility Toolkit, and start building your project plan!
You can also find helpful information and guidance on Chris Jackson’s Blog. You can also learn more about the virtualization technologies mentioned above through the Microsoft Desktop Optimization Pack Resource Zone.
To learn more about Windows 8.1 or any of the Windows Client technologies, please visit the Windows 8.1 TechCenter for the latest information, guidance, and community connections.
Back to top
Chris "The App Compat Guy" Jackson is a Principal Consultant and the worldwide lead for application compatibility at Microsoft, specializing in Windows, Internet Explorer, and Office internals. Jackson is a widely recognized expert in the field of application compatibility, creating technical documentation, training, and service offerings used inside and outside of Microsoft and based on years of real-world experience with enterprise customers and independent software vendors. Author or co-author of numerous technical papers and articles, he is also a featured speaker at major industry conferences around the world and publishes a popular blog.