I am currently sitting at my third Windows 7 related conference of the week. This one is slightly different, it's a real world look at how organisations can get to Windows 7 deployment in the fastest, most economical time by utilising Microsoft tools across the board. It's an interesting journey through the different facets that make a successful migration from the infrastructure and application management, right through to the building and deploying of machines. Like many of these sessions, the technical methodology is taking precedence over the end user migration logistics, but it's an interesting pitch.

What's impressed me the most about this week has been the general buzz and sheer amount of people trying to find out more information about Windows 7. Microsoft's marketing has been right on the nail, partners such as ourselves have been havily involved and informed of the progress, and we have a wealth of material to help push forward. I also think there is a state of mind thing going on here. Certainly in the UK, IT departments have been scaling back, investment budgets have been cut, and generally, those still employed have been asked to do more and more with less resources. Maybe Windows 7 is that new, exciting project that is going to turn this negativity around. April 2014 sees Windows XP go end of life, so there's a clear timeline and directive to get it done. Virtualisation of applications and desktops is an effective reality. We've all got proper strategic decisions to make. What a great time! We'll have to take on more staff to deliver it, we'll have money to spend and we can finally spend money to remediate some of the old stuff. No wonder everyone is talking.

So once we've all been 'wowed' by the technology, what next? Now we have decisions to make - why, what, when and how? First the why? Well that's easy - if we don't do it, we won't be able to buy new machines because there won't be any drivers, we'll have to pay Microsoft for extended support, there are cost savings we'll be missing through Direct Access and Bitlocker and we can introduce additional productivity tools to make our workforce more effective. Job done.

Now what? What infrastructure are we going to utilise, what will be our application delivery method, what platform(s) are we going to be using, what is our build method, what is our business case, what is our budget, what is our governance process, what information do we need, what tools are available to help us save time? All these are critical questions to ask. Failure to answer them will inevitably involve a longer, drawn out, more expensive migration project than the CIO expects.

So we've answered those critical questions, let's look at when? When will our infrastructure be ready, when will our build be complete, when do we plan to deploy, when do we plan to finish, when do we engage the business, when will our applications be available, when will our information data-mart be usable, when do we engage suppliers and when do we need our resources. A word of warning ... I guarantee that the timeline you set will be too short. If you take what you plan and add at least 50% you'll be closer to the reality of your migration. There are a lot of components here - don't underestimate how long it will take to get you ready to build everything you need.

And last, but by no means least, the oft forgotten 'how'? I've sat through many planning meetings where all the effort was front-loaded into the product build phase that nobody really thought about how the project was going to be delivered until it was too late. If you're not thinking about this now, your project will go over budget - no question. Technical rollout is the easy bit - don't let anyone fool you. Technology is so advanced these days that I can kick off a full Windows 7 build + applications from a single command line. But it's not about the technical build, now it's about the end user. How do we identify the 'ready' users, how do we execute the deployment (rebuild/refresh), how do we manage the project, how do we engage the business, how do we report, how do we govern, how do we identify hardware/application incompatibility, how do we prioritise and target applications, how do we get service delivery teams more involved, how do we track progress, how do we hit timelines, how do we support the new environment, how do we do this more intelligently! I've not even started - this is by far the longest section and typically gets the least focus. Don't fall into that trap. Don't be blinded by the easy of the technology delivery. Don't go over budget. Don't forget to figure out 'how'. Don't fail.

"IT hated the business, and the business hated IT" - that was the prognosis on the last major Windows migration in a tier one organisation we've been talking to. It's a common perception of Windows migrations - no matter how good a job we as IT do, any Windows migration is going to be a relatively major distraction for the business versus their primary goal, creating revenue or providing service.

Of course, the same used to be said about virus and patch management. Not any more. Those items have, in the main, been dealt with by a combination of technology and process focus. It's rare to hear these days that a company spends the inordinate amount of time that we used to on such activities.

Let's wind back the clock. The slammer virus has just hit. It's a brand new virus, never seen in the wild and it's spreading. Corporate machines are getting hit by the millions per second. Our first answer as IT - turn all the machines off, stop the spread. Next, figure out a way to patch and update all the machines without further spreading the problem. It was a common problem, and it required focus. Why did it happen? What could we have done to stop it? How do we improve our processes to reduce the risk in the future?

With a combination of senior focus from IT directors, software vendors and businesses who put the cost into $billions, the problem got pretty much fixed. Tools can now put out an update in a matter of minutes across hundreds of thousands of PCs, anti-virus companies have improved their speed to market for definition updates, IT have put in fast, slick processes to get the patch testing done to reduce the vulnerability window and most importantly, Microsoft sorted out their patch release process and made it regular and automated.

There's an argument out there to state we that we haven't been applying the same levels of focus to Windows migrations, even though the risk and cost are potentially greater. Typically, the lessons learnt from past rollouts are forgotten, and we spend months re-inventing the process wheel. The people involved in those efforts have long since moved up the management chain, and a whole raft of new resources are bought in to make the same mistakes as their counterparts all those years ago.

It's a common story we at Juriba hear time and time again. My only conclusion is that because the projects are generally such distinct, funded pieces of work, the people involved in them generally are not given, or more likely, don't want the responsibility to put in place more strategic tools and processes. Sure, the projects get delivered, but the legacy never remains. Therefore, we seem to live forever in the boom bust cycles, where each new migration is a mass of new resource, technology, process and cost.

So how do we begin to fix this problem? Well, in my experience, the project team will clearly identify all those issues we've been living with in BAU, the process challenges, the system challenges and the efficiencies that could be bought with new tools and processes. What now needs to happen is for senior management to take those issues and assign them to the BAU teams to implement, maybe even using some migration project funding to implement them. After all, if you can improve the processes and tools during the project, that will surely make the project more efficient and save critical expense.

But here's the key piece. We know that Microsoft are committed to a new desktop OS release every 3 years. So even if organisations skip the odd operating system, we're destined for a cycle of 3 year migration, 3 year steady state in the largest corporates. We don't need the project team in the steady state years, but if we can implement consistent tools and processes in BAU that take the pain away from the migration planning, when we do need them, we shouldn't be asking them to reinvent the process wheel. This is the key to future migration success and the beginning of what we'd like to see as a new cultural way of thinking about migrations within BAU, something I'll be covering more shortly...