It seems almost a forgone conclusion to most home pc users that Windows 7 is in their homes and Windows XP is just a tale to tell the grandkids. But for many corporate and IT environments Windows XP is still alive and kicking….at least for now. Windows has set a date to end support for Windows XP on April 8th 2014. It’s a big deal to switch from one OS to another the corporate world, and expensive too. One of the most important and stressful parts of that migration to a new OS is application compatibility. Applications have come a long way in the past couple decades…and believe it or not companies are still using applications that are sometimes older than the tech support team trying to support them. Back when Windows XP first came out software companies kind of did their own kind of thing when it came to designing how their applications were installed and functioned on a computer. They didn’t care about playing nice with the OS or the other applications that may get installed on the same machine. What resulted was a very messy bunch of hacked registry files and system files that caused more blue screens of death to be funny. So when Microsoft design Windows 7 they decided to firm up what software was allowed to do to the OS. There is a limit to what changes can be made and which files can be accessed by applications being installed on a pc. For software that was designed before Windows 7 this can lead to complete failure…so what do you do? If you are the system administrator or application manager for an organization where do you start?

The above graphic shows the compatibility process an application must go through when getting ready for Windows 7 from XP or from a 32bit OS to a 64bit OS. Both types of migrations bring along with it compatibility concerns that could potentially bring a company’s productivity to a screeching halt. Lets dive a little deeper into each step of the process to understand what is really involved. We will use a Windows 7 migration as our example in the following information, however the steps for compatibility from 32bit to 64bit OS or to Windows 8, etc are the same.

INVENTORY

I cannot….I repeat cannot stress how important a proper inventory is. If you don’t do a complete discovery of the applications in your environment you will might be able to get off the ground running but you will end up flat on your face. When doing a discovery you should not only be looking for the major application products that you think your organization uses, but also the ones that your users take for granted. This can be small programs like 7zip or VLC player. Since they are free these tools can sometimes be overlooked. Even more overlooked however is the dependencies for all of your programs. Usually you dont notice them because they install automatically with your main applications, but some of them don’t even show up in your programs and features(add and remove programs from XP). If you don’t test not only your primary applications but your dependency applications as well you will be in a world of hurt. Additionally, if you don’t discover as many as these little buggers as you can early on you will not budget your time or money for your migration project correctly. It’s the difference between you think you have 150 applications and 400. So if you don’t want to start a project telling your bosses that its one price only to get started and discover it will cost you triple, its important to do a proper discover of ALL the applications in your environment. Microsoft provides a tool to help you discover your applications as well as some more information about your environment called (MAP) or (Microsoft Assessment Planning) Toolkit. For information on that tool please see the information available on Microsoft’s product page.

ANALYZE

Now here comes the tricky part. There are a couple of ways of analyzing your applications for compatibility issues. You can hire programmers to debug you applications one by one on your new Windows 7 image to find the issues and try to remediate(fix or put a band-aid on) them. This would be a possible option but not probable, considering the man hours and cost involved of taking this approach. You can use Microsoft’s compatibility toolkit otherwise known as (ACT) or (Application Compatibility Toolkit).  You can have a team of employees who know what the applications are used for analyzing the applications to see if anything errors out or doesn’t function correctly. This method could be cheap but leaves you with no guarantees of what will really work and what might or might not break when in production. There are also a few third-party compatibility analization tools out on the market. The top two being Citrix’s AppDNA and Quest Software’s Changebase. These two products will give you a RAG status and a report as to what compatibility issues it has found. They each have different modules and versions based on what you want to analyze and pricing to match. (From personal experience at the time of writing this blog my opinion is that AppDNA gives more detailed reporting than Changebase, but you will want to check out what the current features are to make sure which tool is best for you if you decide to use one.) No matter how you analyze your applications you will want to be able to sort them into three main categories. These categories are usually referred to by their compatibility status of Red, Amber, or Green. Red applications are ones that have serious compatibility issues resulting in application failure or malfunction. Generally if you application falls under this category is considered high unlikely to work well on Windows 7. Amber applications are ones that have some compatibility issues but are generally able to be fixed to work properly in a windows 7 environment. Green applications are either free from compatibility issues or if they have any issues at all they do not impact the functionality of the app.

TESTING

Once you have sorted out the compatibility status of your applications you can spend some time testing them on your environment and remediate any issues you can through repackaging, scripting, virtualization, or some other means depending on what the issues are and how your IT team would like to approach fixing them. (It is not uncommon for some IT departments to make their own rules about which compatibility issues they are going to try resolve and which they will ignore assuming they will not impact functionality to their users by ignoring them.) If you have done your discovery and analyzing properly you should have a good idea before starting testing and remediation which applications will need work, which applications can do to the next phase of the process, and which applications will need to be mitigated. It is also recommended at this phase to do a UAT test or a User Acceptance Test. This is a chance for someone in your organization who uses the application you are testing on a regular basis to try the app if you have made changes or not and see if the user experience of the application installed on your new OS environment will work correctly and function as needed for production use.

MITIGATE

So what do you do if you applications wont work on your new environment and can’t be remediated? You mitigate! As it shows in the graphic above there are few options to look into when trying to figure out what you can do with applications that are absolutely not compatible with your new OS environment. You can check with the software vendor for new versions, you can have a programmer recode your application with the fixes you need. You can try desktop or application virtualization, so when it comes down to it if you really can’t live without that application you got when you where still running Windows 98 you might still be able to get it up and running on your new OS environment. Microsoft has also provided a toolkit for doing some forms of mitigation as well called the (MDOP) or (Microsoft Desktop Optimization Pack).

So now are you ready to begin your application compatibility journey????? Well if you are looking for more detailed information to any and all of what was covered above look for more posts from softwaresushi.net. If there is something specific about compatibility testing or other topic you would like to see featured here send us an email or connect to us on Facebook or Twitter.

Happy AppCompat Testing!