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, you 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 nearly as rosy. I sat down with Greg Lambert, a longtime friend and our CEO, 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 are so much more difficult today than they were only five years ago. Here is what I learned:
Real-World Windows 10 Enterprise Application Compatibility
Two years ago, I remember telling 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, I see that the situation is potentially even worse than only five years ago.
There are two reasons for that: 1) Managing 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. But the vast majority of devices currently sending telemetry data to Microsoft (at the moment) are consumers and small businesses, so it is 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).
As you can see above, in reality, 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, while about one in four (26%) were not compatible, but could possibly be fixed, and 7% were simply not compatible.
After fixing them with Application Readiness, this number changed significantly. On average, 88% were compatible, only 6% still had some issues and another 6% wasn’t compatible. That is not only a difference of 21% of applications ready to go, but for the few remaining programs, you also know which need further intervention and what needs to be done.
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. 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 five years ago!
Greg nicely illustrated the challenge this creates by providing me 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 megabytes.
For example, we recently loaded 7,000 applications into Application Readiness for one particular client. Instead of the 50-150MB size apps, our 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. 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 10. Instead of undergoing this every five years, you will now have to do this every six months as you roll out a new Windows 10 feature update. That is 10 times the frequency!
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 you 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 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, there will still be potential gaps.
So, as responsible IT managers, you have to manage risks!
- The risks of potential business disruption should anything go wrong.
- The risk of testing compatible apps and “wasting time”.
- The risk of carrying applications in my portfolio that will cause issues down the road.
You get the idea.
For a Windows 10 migration, the potential issues you will run into most are related to an application installing, updating, running, and uninstalling. The application might encounter problems with the operating system itself, as well as components or configuration options within that operating system (e.g., drivers or driver components).
You could also face potential problems with security settings and custom actions, which are a custom code on installations that might cause an application to fail to start after installation. Or you may run into issues with little sub-components that run within an application, or that one application depends upon, that may not start correctly due to security, configuration, and compatibility issues.
How Do You Fix It?
When going through an application estate in order to prepare for an IT Transformation event, the number one question you should ask is: “Which applications have a component that will fail to deploy (meaning install, update, uninstall on a client machine) successfully?”
There are roughly 38 classes of problems which may prevent an app from installing, running, updating and uninstalling that Application Readiness has grouped together into a Windows 10 Compatibility Assessment. The outcomes are categorized in three basic categories of red, amber, and green.*
- GREEN (No Issues): An application status is set to ‘Green’ if no issues have been detected and the application is going to deploy just fine.
- AMBER (With Issues): If an application status is set to ‘Amber’, the tool has found something that requires some modifications, or changes need to be made so that the application package will eventually be compatible. This can be done through automated or manual fixes.
- RED (Not Compatible): ‘Red’ means that the tool has found something that can’t really be fixed because the application has a significant issue with credibility or there is an issue in a component that needs an upgrade or a complete change. One really good example is the particular component of a driver that handles the interaction between the computer and a printer — no matter how many changes we make, we can’t make that application work. A software upgrade or a different piece of software will be required.
* Blue is also used to indicate a future supportability issue. For example, if the application has components that are likely to cause compatibility issues in the future or includes something that is expected to change and once it does, that application will need further intervention.
After you have determined which apps are ready to go and where the issues lay for those which aren’t, you can deploy automation to fix the classes of issues. This way you don’t fix app by app, but can prioritize which class of problems causes the majority of apps to not deploy correctly and then fix them — moving several or even dozens of apps into ‘Green’ status.
