Windows 7 is widely believed to be a significant upgrade over XP and most users have experienced it at home, so why hasn't IT upgraded the organization to it already? There are five main reasons we've learned at 1E from direct experience helping thousands of companies migrate efficiently. I detail the final two of these five factors in Part II of the series. Click here to view Part I.
4. Proliferating Complexity
If you have experienced a migration project before, I have one question for you - was it a part of a larger project which also replaced all the hardware, upgraded servers and Active Directory, deployed one or two new organization-wide applications and a performed a general spring clean? If I got even half of these right then the project was simply too complex. OS migrations can be discrete BAU projects, without all these interdependencies which multiply complexity in terms of technology, process and the people involved.
There were good reasons for combining several projects into one but they are not relevant any longer. To upgrade to a new OS, new PC hardware was generally required. Then you had to consider that Microsoft tended to sync PC OS, Server OS, infrastructure services and applications. System management tools provided fairly basic distribution and deployment functionality, so automation choices were limited and if a large manual exercise touching all the hardware was happening anyway, then it made sense to make all the changes at one time. Finally, a full refresh every three or four years made sure a spring clean of the Active Directory, security, names et cetera could also be performed.
None of these are valid reasons today. New OS's tend not to require faster hardware (unless it is very old), tools are available to fully automate the migration independently of other projects, and there is much greater flexibility with Microsoft's back end infrastructure like AD, so spring cleans are not required or can be performed BAU.
Finally, if you can keep the complexity of each IT project in check so the elapsed time is minimized, it is also likely to be successful. The longer the project duration, the more change you have to contend with; from hardware all the way up the stack to applications, priorities keep shifting, and people move on. The simple answer is thus to keep the scope as narrow as possible and focus on speed through full automation.
5. Lack of Skills and Tools to Achieve Automation Benefits
Why are we so worried about computer viruses? Discounting the actual damage each may cause, is it their ability to spread to all unprotected computers and at computer speed? A computer is simply better and faster at affecting change on other computers than a human. Computer programs are faster, can multitask and be rigorous, conversely, they do not get bored, require breaks or be reminded to work systematically.
I am stating the patently obvious, so please forgive me, but there is a point here. Most organizations simply do not use computers to do what they are best at - IT change, like fully automated OS migrations. While IT still has to send an engineer to every desk, migrations and other large IT rollout projects will remain complex, consume significantly more time and resource than required, and risk failure.
The user, not IT, should initiate the process and everything after that should be automatic. If this can be achieved then there is another tantalizing prize, the one of genuine IT agility. If you can fully automate a complex task like migration then you can do the same with pretty much every other distributed management task. Change can thus be implemented across the organization much faster than ever before, which is the key to agility.
There is a catch of course, or everyone would have done it by now. The skills and tools required to achieve this highly agile state are still very specialized and most organizations do not possess them. Furthermore, many of the largest IT companies are not entirely motivated in providing these solutions as they make a lot of money from the status quo; the large costly IT project is indeed a pot of gold.
We advise our clients to begin with defining a couple of automation goals: the user initiates the migration; and an engineer is not required desk side for 90%+ of PCs. Even when new hardware has to be deployed, it should be delivered to desk, switched on and from then on everything is automated, so a skilled engineer is still not required desk side. We can then look at tools and skills, each is a topic which deserves its own article but I will summarize some of our learning below.
Most current systems management tools have OS migration capability but none that I know of have automated the migration from end to end. The missing automation means the compromise of the desk side visit and thus we are not much better off than where we started from. The problem is that the systems management tools vendors are in a constant feature battle with each other and will check box a feature so they remain in competitive contention. Even though OS migration is one of many capabilities a systems management solution will list, it is complex and requires significant investment rather than just enough to list as another feature.
We, at 1E, build automation technologies leveraging Microsoft's own systems management tools to facilitate the main goals I have discussed. This means we (just) have to develop functionality to provide user driven end-to-end automation. The concern of course for every client is whether they are prepared to sign up yet another vendor for the benefits of automation and this is a choice they need to make. Some choose to write such functionality themselves. Whatever an organization decides, I just recommend they do not compromise on automation.
The right skills and process are just as important as tools. The disadvantage most organizations have is that they only do migrations once every few years so at best their skills are not current. Technology changes all the time, so the team will need to solve issues that they have not encountered before and have no way of predicting. What is assumed to be a well planned and managed project will start to overrun and then fail to deliver on even its basic promises. Many of the largest IT vendors do not want to solve the problem as genuine automation means no large project this time or in the future. Specialist vendors like us can help with this migration but what about next time?
Having spent time talking to some of the largest organizations, there is an overwhelming need for enduring value from investments in IT itself. If this is established as a goal, then the technologies, skills and processes developed for OS migration can be applied to achieve a constant state of readiness; a state in which virtually any change can be implemented across the Windows estate rapidly and with minimal cost. That way the next time the business wants change, IT is not holding it back.