Application Compatibility – Who?, What?, Why?, How? – Part 1

In the last few weeks I have been involved in many meetings around Windows 7. I am currently a part of my 7th Windows 7 migration and was also on a team assisting with a Windows Vista migration. During my time with my previous employer I was also a member of an exclusive team of Techs who travelled around to other countries to perform Windows 7 Application Compatibility and MDOP launchpad workshops. I feel at this stage of my career I have had a significant exposure to the Migration process. Even in the early Beta versions of Windows 7,  I was working on investigating changes to Windows Installer, NTFS Permissions, ACT, AppLocker and a whole host of changes to Windows Operating System landscape.

Across all of the projects I have worked on, one thing is all too common. Teams, People, Customers were all intimidated by the application compatibility aspect of the OS migration and that is understandable. It is my opinion and quite frankly, I believe a fact that your applications are the most important part of your IT tool belt. Creating a Windows 7 image is relatively simple, more info which is helpful for that can be found HERE and HERE The OS Deployment is also relatively simple, more info for an example of how to do that can be found HERE with more useful info in Part 6 of this series. Data Migration is pretty challenging but once you’ve got it set up and going it can be a case of set it and forget it. The applications are the most important component. You can give your users a nice flashy Windows 7 desktop with your company branding on it and all of their files and user settings carried over from their previous system, but if they don’t have the applications to open these files or the applications to actually perform their daily work then your Windows 7 desktop isn’t worth a damn. Applications drive productivity and are critical to your business.

With all that stated, application compatibility does not have to intimidate you. With the correct planning and the correct tools it can actually be a very logical step by step process with less pain points than you might think. I will cover the common process adapted for migrations in the coming parts of this series of blogs and add my own insight from the variations I have seen adopted on projects over the course of my career. Before moving onto the process though, let’s get an understanding of Application Compatibility and what you need to know.

Microsoft state that it is not their intention to break applications when releasing a new operating system. To their credit they do provide vast amounts of documentation in advance of a new OS coming to the market. In my experience in-house developers do not seem to adhere to this documentation and so that introduces challenges. If you are just migrating OS, right now. You are unfortunate because you are likely under great pressure to complete the migration within a very tight deadline but you are also fortunate in a way. The bulk of applications in an environment tend to be purchased from third party vendors, as they are in the job or providing applications they tend to revise applications for newer OS’s to keep them in line with changes in the IT landscape. For early adopters of an Operating System this is often not quick enough as they find themselves being unable to get a compatible version of their software to use. But this being 2013 and Windows 7 coming out in 2009, it means vendors have had a lot of time to bring their applications up to par and so it’s likely that the majority of your third party applications in your environment will likely already work out of the box for Windows 7. Not so fast though, Don’t forget about those applications developed in-house, you still need to analyze these and remediate accordingly. Also another consideration, with hardware advancing, many companies are not just moving to Windows 7 or Windows 8, they are also moving to a 64-bit architecture. In my opinion this impacts on your application compatibility more now in 2013 than moving to Windows 7 itself. Your applications over the years have become Windows 7 certified simply by proxy, through your maintenance plans and progression of moving to the latest and greatest. Hell, even if you aren’t bleeding edge, it’s quite likely a lot of your applications have been upgraded since 2009. Unfortunately if you did not have 64-bit systems out in your environment all of your apps are currently 32-bit.

Read more