Application Compatibility – Rationalization – Part 2

As I stated in Part 1. Proper Planning for your Windows 7 Application Migration is critical and this begins with Rationalization. Some companies are reluctant to rationalize their list of applications and will simply go to their Distribution Share, create a list of the applications contained within and then throw money at getting each and every app migrated. This is foolish. Migrating to a new platform is not cheap but it introduces a great opportunity to achieve long term cost savings as well as improved efficiency in your processes. This can start with rationalization.

To do this you will need an accurate account of what applications are currently in use in your environment. There’s numerous tools which can aide with this. From Asset Inventory Tools which are standalone, AIS tools which are a part of Distribution tools such as SCCM to free tools such as Microsofts ACT (Application Compatibility Toolkit) and other great third party tools such as Lakeside SysTrack. SCCM used alongside ACT can provide valuable information. You really should trial some of these tools in your environment as some can have a large overhead when in use. For more information on LakeSide SysTrack you can read my post about it HERE I don’t want to go into too much detail about all the different options on this post but I will highlight Microsofts ACT simply due to the fact it’s cost effective.

First you need to plan your criteria for rationalizing your application list. A rule of thumb that I have tried to use, is to eliminate a lot of Middleware like Java. You will likely find many different versions in your environment. With Version 1.6 and 1.7, backwards compatibility has been more robust than in previous versions so the need for multiple versions at once is a dying need. You could eliminate all but the latest version and then simply deploy an older version when an application is found to have a definite need for this. You will increase security in your environment by removing legacy applications from systems and save on re-packaging effort.

IT Techs are pretty bad offenders for duplication of resources. Many different departments and possibly even users have their own preference for tools such as FTP tools, CD\DVD burning software, ISO Mounting Software, Network Monitoring Tools etc. Whilst it’s possible each may serve a certain purpose that the other tool might not you should attempt to standardize on the tools in use and you will likely find cost savings from a license perspective in the long run and also less resources spent on packaging and maintaing these duplicate packages. Users in different departments may also have duplicate software tools for doing tasks such as converting PDF files, Media players, Browsers etc. Is there a need? Can two or three browser choices be enough? YES, duh! Just because someone uses Opera or Safari at home doesn’t mean you need to spend company resources on providing them on company assets. Converting PDF’s you say? Did you know you can save documents as PDF in Office 2o10 and 2013, what exactly are they doing with the PDF’s? Signing them? Find out what and maybe you’ll find they don’t need that licensed software any more. Next on the chopping block. Multiple versions of the same application in use within one department or multiple departments. Is there a business requirement? If not, cut that mess! Are there applications in your environment that are not even in use any more? Almost guaranteed, are you continuing to pay for licenses for these without a need? Quite possibly, depends on how messed up your license control is 🙂

Something that should be apparent with the above paragraph is that rationalizing the list of applications will require input from multiple sources or possibly one gutsy individual. If you have defined Application Owners this can actual be very easy and with a little help from somebody in a position of power sending a strongly worded communication for immediate co-operation this can actually be a quick process to complete. Without Application Owners you may need to collaborate with Department leads\Managers to get the answers you require. Failing that, you may need to go with your gut and wait until someone screams. But hey, that’s what pilot phases are for 🙂

Read more

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