Thought Leadership

forrester_SM_1204_blog_002

Subscribe to our blog

Your email:

Connect with Ness

Software Engineering Services Blog

Current Articles | RSS Feed RSS Feed

How to migrate Windows without killing your CTO

  
  
  

by Madhan Gopalan
Ness AVP, Financial Services

canstockphoto0907862A large Financial Institution’s CTO once asked a gathering ‘Do you know how long it takes to transform an IT organization like ours?’ As you would have imagined, the responses varied from one-year to several years. Once the responses stopped, he softly said ‘Two and half CTOs’. The crowd burst into laughter.

Operating System migrations, especially in large firms, may not be as dramatic as this CTO indicated, but it sure has a lot of challenges and 18 to 36 months’ time frame, depending on the size of the organization, to migrate to a modern desktop. Here are a few things to consider while migrating from XP to Windows 7 or 8 if you are running the technology for a large firm

The right governance, participation and communication

The right Governance may sound a little dull, but it is a primary requirement, without which your migration program is bound to fail. To start with, identify the project team and set expectations with different groups, regions and business departments within the organization. Also, a change of this size, to be successful, requires participation at all levels. Hence, involve people at all levels – strategic, tactical, functional and technical. Appoint champions and liaisons who can take your cause and message down to the last employee. Administrative Assistants fit this bill really well. To start with, set up monthly steering committee meetings at the strategic level and bi-weekly or weekly meetings at the tactical level. Communicate frequently and copiously the status of the program and the results to all the stakeholders.  Also, keep the process transparent.

Testing, testing and more testing

I cannot emphasize enough the need for testing your key and critical software platforms, applications, and models before migrating to the latest version of Windows. Microsoft provides a list of all the market applications that are certified for Windows. 

But that does not mean you are good to go just because you see your application on that list. For instance, as you would expect, Excel is certified for Windows. But that doesn’t mean the model you built on Excel with underlying programming (say Macros and VB Code) will work automatically just because Excel is on the approved application list.  You may have to do little tweaks and in-some cases rebuild these models. Testing assumes even greater importance in firms that have home-grown solutions. 

Here are a few things to keep in mind when testing your apps:

  1. Applications are best tested using spare test machines that are exact replicas of the existing machine but with latest software. However setting up test machines can be a logical nightmare especially in large organization with multiple locations. In this instance, you can use a Virtual Desktop Instance (VDI) that has the latest operating system and application software. 
  2. Before starting the testing process, take the inventory of all the applications that are typically used by the employees. The Systems Management Server application should help you to get the inventory at the user level. However, access to websites and select plug-ins and tools downloaded from third-party software providers’ websites may not show up in the application. Watch out for them. 
  3. If a given application is used by more than 10 people, the best practice is to package it and test it thoroughly before being pushed into a given computer in an automated fashion. That way manual installs can be avoided.

Setting expectations and handling apprehensions

The personal computer, as the name suggests, is indeed personal to the individual using it. Consequently, you are likely to face a certain degree of resistance when you try to change something that is close to them. After all they have been using it all these years without much ado so why make a change. 

Here are the few things that you can do to set and manage expectations and keep the apprehensions under control:

  1. Tell them that Microsoft typically stops supporting earlier versions after a certain period of time. For instance, Microsoft plans to stop supporting Windows XP and Office 2003 by April 2014. Also, demonstrate the benefits and the cool user interface.
  2. Communicate regularly through emails, blog posts and on the company intranet about the imminent change -- and the do’s and the don’ts as well.
  3. Before migrating, back up all the data and ask the users to move all the data, if any, in the desktop to a network location.  That will provide the assurance to the employees that they should get their data back after the migration is complete.
  4. Most employees freak out if they find something is missing. Hence, once you are done migrating the machine, ensure that their settings (especially bookmarks), applications, data files are properly reinstated.
  5. Keep a well-trained team and if possible a dedicated phone line to answer queries about accessing the new system.  I also would recommend a Microsoft Office trainer to be part of the team who could periodically run training classes for those who chose to attend.

Rolling out and getting feedback

Before rolling out in a large scale, do several pilots. This will provide you a sense of all the dependencies involved and the level of user readiness. Also, the most common mistake is excluding a specific group of people from the pilots. Involve all the groups – functional, technical, legal, finance, sales, marketing and general administration – to actively participate in these pilots. Also, obtain feedback from them through surveys and other means so that you can constantly refine your migration process 

If you follow this advice, you should have a smoother transition from one version of Windows to another -- and just maybe you can do it faster, more efficiently, with fewer headaches. And maybe that CTO at the party can survive to do his job another day.

The author, Madhan Gopalan, based out of Hackensack, NJ, is an Associate Vice President with Ness Technologies. The views expressed here are his own and not necessarily that of his employer. He can be reached at madhan.gopalan@ness.com

Photo Credit: (c) Can Stock Photo 

blog comments powered by Disqus