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:
- Managing customer expectations and
- 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:— Saher Ahwal (@SaherAhwal) August 10, 2018
-what're you doing with that 2KB of RAM?
-sending people to the moon
-what're you doing with that 1.5GB of RAM?
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.
For a Windows 10 or Windows 10 to 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 piece of 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, which 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?"
Because Juriba is often helping to manage the application readiness conundrum, it is good to know what causes application compatibility issues. Application Readiness has identified 38 classes of problems which may prevent an app from installing, running, updating and uninstalling. 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.
*Please note that Application Readiness uses the same traffic light color-coding as Juriba Dashworks does, but it has a slightly different meaning and should not be confused. Application Readiness also uses 'Blue' to indicate the 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.
Of course, knowing which applications will work on the latest OS is a critical step in your rollout, but further identifying which users can now be scheduled based on this information is where the Juriba Dashworks toolkit brings organizational value. If you are interested, Juriba offers an organizational application assessment service through partners such as DXC that can tell you exactly what will and won't work moving forwards, and what impact that analysis has on your end users.
In a future post, we will take a closer look at this process and show you how you can work smart, not hard on getting through this as fast and efficiently as possible. So, stay tuned.