Five Steps to Windows 8 Application Readiness
In this article:
Streamlining Your Application Analysis and Testing Project
“What’s our next project? Test our applications to get ready for Windows 8? No problem, boss. We just have about 950 apps that we need to consider…”
Why Do Applications Break in Windows 8?
So what changes were made in Windows 8 that caused applications designed for earlier versions of Windows to break? To be sure, the engineering teams responsible for Windows 8 didn’t take the issue lightly.
User Account Control (UAC)/Standard User Accounts
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.
The single biggest application compatibility impact, out of all of the changes we made to Windows 8, 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.
Five Steps to Manage Application Readiness for Windows 8
Like most projects, an app readiness project becomes much easier when you invest the time to break down the challenge into logical, manageable tasks.
Step 1: Application Discovery
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.
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.
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—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.
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.
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. 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.
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!
Readying your application portfolio for a migration to Windows 8 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!
About the Author
Chris 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.