Digital Transformation
Showing results for 
Search instead for 
Did you mean: 

Navigating the tricky upgrade path from Windows 2003


HP20140825348.jpgBy Ken O'Hagan


As we have seen in the press, Microsoft is drawing a line under Windows 2003’s chapter in history. As of early 2015, it will no longer be a mainstream supported platform.


The clock is ticking


The challenge this presents is not one of value add. This is a necessary activity to keep the show on the road. We could argue that it is a risk mitigation need the same as any other but I would counter that this is on a whole different level. Another main challenge is that of time. Organisations large and small have had the egg timer turned over on them and they are now against the clock.


One size does not fit all


Looking around at the kind of organisations we work with at HP, we see that most of them have a large number of machines that are affected by this upgrade requirement. The complexity arises when we start to look at where they fit into the infrastructure eco-system, what services rely on them and then, more importantly, what is the optimal corrective action to take.


If we look at a typical server running a component of a production service, we need to think long and hard about how the mechanics of an actual migration would work. Simply put, one size most definitely does not fit all. Considerations include:


  1. What upgrade path do we take? There is no single step upgrade to Windows 2012 from 2003 so do we upgrade to 2008 then face the need to do it again in a few years when 2008 comes to the end of its life? Or do we go through pain to get to 2012 now?
  2. Apart from the operating system, what else will change? What other third-party and in-house applications are going to need remediation as a result of this?
  3. Can your applications even run on the later version of Windows or will they require upgrades too? If so, what does this mean for the services running on them? Are there deprecated functionsthat would lead to the rewriting of code? Are there issues of third-party apps that are no longer available?
  4. How do you do the migration? Will you migrate in place? Will you build fresh and decommission old instances? Will you build fresh, cut over and then recycle the old equipment to seed future migrations? Or worse, are you trapped and have to define a contingency plan for keeping them?
  5. Even if compatibility is not a concern, what performance impacts will you face due to the changing resource consumption profile of different Windows versions?
  6. Would you even look to move the instances onto future platforming strategies, taking physical servers or virtualised servers and moving them into an internal or external cloud, taking the opportunity to refresh hardware while you are at it?
  7. Could we just do nothing and continue to pay for custom support? This is an option but over time this will cease to be an option as we have seen with Windows XP. This therefore merely delays the inevitable. Or do we wait until 2008 reaches the end of its life then attempt to cover them all at once?

What we are seeing here is that the magnitude of this impact is far-reaching and it fast becomes clear: This is not a “click next, next, finish” gig, it is a full on transformation exercise that has to be addressed accordingly. The problem is that there simply isn’t enough time to do it all without incurring large customer support fees to tide us over. We don’t want to be paying these for very long though as they are expensive.


Understanding the scale of the upgrade


So we need to take a look at our IT management software and look at what we have available that can help us. We need to look at discovery technology to help us understand the scale and shape of the problem, we need to use our ITSM tooling to provide the critical governance, Automation to help mitigate the risk of and accelerate the actual migrations and ADM to ensure that requisite changes are checked before being deployed into the new live environment.

We need to implement a programme of work that addresses core project building blocks:

  1. Understand scale, scope and considerations
  2. Develop, Test and Deploy
  3. Close Down and future operating model

Within each of these areas there is a myriad of challenges and “gotchas” to be navigated. The reassurance however, is that we have been here before and we know how to make best use of the tools in our toolkit to help ensure a successful outcome.


Over the coming weeks, I will explore three areas of focus needed in any migration:

  1. The applications and gaining insight into the scale of the challenge ahead.
  2. Why best practices in DevOps and ALM are critical in an activity like this,
  3. Dealing with the enduring state after the completion of the migration and ways to protect any remaining assets.


I would welcome your views and any feedback you have around your own challenges when addressing this end of life in the comments section below.


For more IT strategy tips, subscribe to the Discover Performance newsletter:

0 Kudos
About the Author


This account is for guest bloggers. The blog post will identify the blogger.

Jan 30-31, 2018
Expert Days - 2018
Visit this forum and get the schedules for online HPE Expert Days where you can talk to HPE product experts, R&D and support team members and get answ...
Read more
See posts for dates
HPE Webinars - 2018
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all