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 🙂
ACT offers you a dynamic solution for polling the software in use in your environment. You deploy collectors to a sample of your companies machines. For a how to, on deploying the collectors you can read my post. You should take a good sample of users. Perhaps 4 users from each department. Deploy the Collectors to their machines using GPO or a Software Distribution Tool. You should leave this in your environment for 2 weeks, you could alert the users and ask them to make an effort to test open and use all of their applications to ensure the tool captures that they are installed on the machine. The ACT tool reads the C:\Windows\Installer Folder, Uninstall Registry Hive, Processes and Add\Remove Programs to detect the applications in use by your users. For information on how to deploy the collectors to users machines in order to collect the information you can read instructions HERE
The data is written back to a central database which allows you to view and customize the list as you please. You should beware that this tool will capture all applications. Not just what you deployed to your users so there’s the added benefit of finding out if users are installing unauthorized applications on their desktops.
ACT, in my opinion is quite a clunky tool. It does give you a fair representation of the applications in your environment and also will list the count of machines an application appears on so you can easily identify the most common and thus possibly the most critical applications in your environment. ACT has a column with a check mark for applications that have been identified as compatible, however use at your own risk as this information is sourced via the Online Community and so it’s about as reliable as Wikipedia, which is reliable in most cases but sometimes you can use it’s info when trying to convey your street knowledge only to later be shown up as the asshole you are, when the app doesn’t work. However to actually rationalize and filter through the list is a very manual task. If you find an application which meets your pre-defined criteria for cutting you can’t simply delete it from the list. You will need to create categories and have a category for Removing and move the applications to that category. You can then create subsequent groups which make sense to you. For example Each Department or perhaps by Application Type. You can also then export your results into an excel sheet for a friendlier feeling.
LakeSide SysTrack is one of the most powerful inventory tools I have ever seen but be warned with great power, comes great responsibility. Yeah, Yeah..I know. Anywho! Really with that power you get a lot of detail and frankly at times it seems like too much information. It is overwhelming. You really need to get your head around what it is you want to accomplish by using the tool. This tool similarly to ACT can be deployed via GPO or Distribution tool to a sample group of users or possibly your entire user base. It will also report back into a database but the big difference here is that this tool provides extra information regarding user activity and machine compacity. It can report on IOPs, Network Usage, Log-in Times, Applications and more. It really is a great tool.
Once you have your list vetted you can use the info to help shape your deployment schedule which is mentioned in Part 6 of this series. It can also highlight what apps to focus on with priority. An obvious one would be your Disk Encryption software as this will be critical for security on your migrated systems. When you have your application list ready, you are ready to move onto Compatibility Analysis.
For more, read on in Part 3
