MigrationStudio Review

In previous blog posts, I covered using Microsoft’s Application Compatibility Toolkit tool to gather a list of applications in your environment and to rationalize that list. It leaves a lot to be desired! In my experience, I was always better off …

Read more

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