Why Windows 10 Enterprise Application Compatibility Is A Bigger Problem Now Than 5 Years Ago

It is easy to get caught up in Microsoft's marketing message that tells us application compatibility with Windows 10 isn't an issue any more. In fact, Microsoft claims that 99% of all Windows 7 applications run on Windows 10 — based on its extensive telemetry data. As an IT manager responsible for migrating tens or even hundreds of thousands of users to Windows 10, we want to believe it because it would make our life so much easier. We all drank the Kool-Aid.

But unfortunately, the real world doesn't look quite as rosy for our enterprise organizations. I sat down with Greg Lambert, a long time friend and the CEO of our long-time partners Application Readiness, to take a look at some numbers around real-world app compatibility issues that enterprises and other large organizations are facing both with Windows 10 transformation and Windows 10 Servicing, and why they could be so much more difficult today than they were only five years ago. Here is what we found:

Real-World Windows 10 Enterprise Application Compatibility

Two years ago, I remember a discussion with Greg that desktop management could lose its importance with the adoption of Windows 10 and that Microsoft believes he has it all backwards by focusing on application compatibility. But today, looking at real world data, I see that the situation is potentially much more complicated than only five years ago.

There are two reasons for that:

1. Managing customer expectations and
2. The skyrocketing complexity of our application landscape. 

Microsoft wants us to believe that we are all going to be just fine once we are on Windows 10, and that may indeed be the case. Since the inception of Microsoft Windows Analytics, millions of consumer, small business and enterprise devices have been sending application telemetry data to Microsoft. 

This has enabled an important baseline to be established on application compatibility, but for enterprises it is still not always an appropriate indication for an organization that has thousands of applications — many of them niche business applications and in-house written software. In reality, while the number of application compatibility issues is rapidly decreasing compared to what we faced migrating from XP to Windows 7 (primarily because the shift from 32-bit to 64-bit apps has happened), the complexity of our increasingly hybrid IT environments is skyrocketing — making the application compatibility requirement at least as complex as your Windows 7 migration has been (see below).

By adding in the mix of potential target platforms like fat client, VDI, MDM and Microsoft hosted desktop, application compatibility is arguably generating more work than ever before. In later posts we will look at application compatibility on some of those other platforms, but for now, we decided to look at our own real-world experience on application package compatibility for Windows 7 to 10.

As you can see above, application compatibility in enterprises preparing to go from Windows 7 to Windows 10 looks a far cry from Microsoft's 99% are ready-to-go scenario. We have found that, out-of-the-box, just over two-thirds (67%) of a typical enterprise application estate are compatible right away, one in four (26%) had potential issues that could possibly be fixed, and 7% were simply not compatible.

By using tooling (in this case applicationreadiness.com), it is possible to change this situation for the better. After a fix routine, an average, 88% were compatible, only 6% still had some potential issues and 6% still were not compatible. That is not only a huge difference in applications ready to go, but for the few remaining programs, the tooling can tell you what needs to be done for those that need further intervention.

Contrary To Common Beliefs, Application Complexity Skyrockets

The biggest issue IT managers face is the explosion of complexity that has happened in the past five years or so. This might surprise you — we were, too! Contrary to what the press has been saying about webification and simplification, we have seen a massive increase in application complexity that is bigger than what we were dealing with during XP to 7!

Greg nicely illustrated the challenge this creates by providing us with some real-world numbers: Three to five years ago, each individual application package would have contained, on average, 150 files, 1,000 registry settings, a couple of shortcuts, one or two mini-files, and the OMDB database connection settings. That would be a file size of 50 to 100 meg. 

As a current example, we reviewed a load of 7,000 applications for one particular client. Instead of the 50-150MB size apps, his team found that, across the board, the apps averaged more like 250MB. Some were even 2-3GB and a few even larger than 7GB, including over 20,000 registry settings, individual settings and configuration options for each app that installs on the user component before the machine component allows it to run correctly.

Although this refers to the run time of an application, the tweet of a Microsoft employee visualizes this problem nicely:

1969:
-what're you doing with that 2KB of RAM?
-sending people to the moon

2017:
-what're you doing with that 1.5GB of RAM?
-running Slack

— Saher Ahwal (@SaherAhwal) August 10, 2018

In the past decades, you were able to run through this application compatibility process every OS migration (with the odd exception for Service Pack checks). That was a doable job, albeit a painful one. But now, you have more complex applications, thousands of settings, and gigabytes of files to deal with. Now, the volume of application compatibility testing has multiplied by 5. Instead of undergoing this every five years, you will now have to do this every twelve months (or every 6 if you take every feature release) as you roll out a new Windows 10 feature update.

Fixing Compatibility Is A Crucial Risk Management Exercise

Nothing is perfect. Most organizations have a manual application compatibility testing process, often managed with the businesses. This is prone to human error and time heavy, but ensures as IT we get the appropriate sign off. Then there are the tools to identify within the application code those components which are either not compatible or could cause issues. Of course, some of these components might not even be in use (false-positives), but the offending code has never been deprecated.

These tools can often also 'fix' certain issues by providing a SHIM. Finally, there are new tools coming out that will perform application functionality smoke or fully scripted tests (a bit like Selenium) that will ensure the specific clicks and result outcomes can be tested. However, whether you will use one or a hybrid of these approaches, our job is to carefully manage the potential gaps. 

So, as responsible IT managers, we have to manage risks, for example, the risk to:

• Potential business disruption should anything go wrong
• Testing compatible apps and "wasting time"
• Carrying applications in your portfolio that will cause issues down the road
• Application remediation efforts being pushed into the business
• Running outdated Windows 10 versions due to application compatibility issues

You get the idea.