Windows XP, Time To Say Sayonara
In Part I of this series, I gave a little current recap and history about Windows XP and reminded everyone that we are creeping up on April 8, 2014. That’s the date that support for Windows XP comes to an end. Many companies are going to be providing information about what to do and how to accomplish the migration. I received an email myself this morning from one of our partners, Flexera Software, regarding a webinar that discusses XP Migrations.
Many organizations with Windows XP will not work with a provider to complete the migration, with the belief that it’s a simple upgrade from XP to something else (such as Windows 7). The reality is that you are in an area that has been referred to by Steve Klaynhans in 2012 as the “XP Danger Zone”. Getting to your next platform requires careful planning and execution if you are going to be successful with the migration and mitigate the pain that your organization IS GOING TO FEEL. All migrations are painful, it’s just a matter of how much pain is going to be felt. What I will describe here is what you can do to minimize that pain. Let’s go.
Any enterprise of significant size (and I count that as having more than 1000 endpoints) is going to have to step back and look very hard at how it leverages end user computing when the upgrade project begins. Understanding that proper planning not only leads to a better chance of success, but also leads to a more affordable migration is important before undertaking a project of this type. They key is frontloading the risk. Take the time to do the up front discovery and assessment and you will position yourself for success.
Discovery and Design
A complete assessment and design phase is critical to success when looking at a transformation like this. Make no mistake; moving from Windows XP to Windows 7 is a transformation. Think about it, most enterprises that are still running Windows XP are also running Office 2003. That means that not only are you going to change the desktop, but more importantly, you are now going to now introduce your user population to the ribbon in Office. That is a more intrusive change than moving to Windows 7. Granted after a couple of weeks, it will be a moot discussion, but this is about the level of pain that your organization is willing to handle and trying to minimize that as much as possible. If you are able to complete this migration without an Office upgrade at that same time, you will be ahead of the game. What do you need to think about in the discovery/assessment area of a Windows XP migration?
Applications will be one of the single largest pain points you will have. The question is not whether you really know all of the applications in use in your organization, but rather, how many applications you do NOT know that are in use. In my experience in deployments over the years, I have found the range can be as few as 1 or 2 apps, to organizations that simply allow their groups to purchase and run whatever apps they want. In this case, I would much prefer the former.
- If you have an inventory, you are ahead of the game. You can jump right to the next step.
- If you don’t know have an inventory, you will have to decide how you are going to get that catalog. You can do it via meeting with your business groups or you can do it via automated tools such as SCCM or Lakeside Systrack. Here in EMC Consulting, we help customers identify their application catalog and try to get a handle on it..
- Application compatibility will need to be determined. Today, most applications will be compatible with Windows 7 OR the developer will have a Windows 7 compatible version. If you have a number of very specialized applications (such as manufacturing, medical, or other industry specific ones), you may find that you have no option for compatibility and remediation steps will be required.
- Finally, the applications will need to be packaged. If you’re wondering what that means, typically, applications come as a stand-alone executable or in an .MSI format. If you are ultimately trying to create an environment where you can automate the deployment and minimize hands on the workstation, you need to package as many applications as possible. Packaging applications is a complicated business depending on the complexity of your applications. This is where organizations like Flexera provide tools to assist. Here at EMC we estimate complexity based on a breakdown of Low, Medium, and High as outlined below.
Successfully deploying Windows in a clean and efficient fashion is dependent on you understanding your application landscape and being able to deploy those applications with as few hands on keyboards as possible.
How many different hardware profiles do you have? The fewer, obviously the better, but either way, are you in a position where you know how many different manufacturers and models are out there? This becomes important when considering the building of your final Windows image. Ultimately, you want to have as FEW images as possible (like, one) and simply have the drivers available for the different hardware models. There are a lot of people out there who believe that you still need to have an individual image for each hardware platform. That is SO windows XP timeframe thinking. The reality is that starting with Windows Vista, the Windows Image Format (WIM) made it possible for you to get to a SINGLE IMAGE regardless of the hardware platform you are using. You are no longer technically bound to creating an image per platform. On the contrary, if you have 64 bit capable machines, you can create a single Windows 7 64-bit image and use it for all of those systems (given you do the right up front work). If you don’t have 64-bit hardware everywhere, then alas, you will need to create a 32-bit image, BUT you will only have to create ONE 32-bit image if you do the correct work up front for all of the necessary platforms. So, would it help for you to get your images down so you only had ONE 64-bit image and ONE 32-bit image? How about not only having One image for 64-bit and 32-bit, BUT also being able to manage that image so you simply can apply the patches to the image without having to do hours of patch management, would that be of value? Of course it would. So the tools are out there for System Center Configuration Manager (SCCM) TODAY, right now, but that being said, you still need to have completed the up front discovery of all of the necessary hardware platforms. Without it, you will have trouble getting to the Nirvana that is a single image and you wind up on the red line in our diagram previously mentioned.
Do you have the necessary deployment tools in place? Many customers have software deployment tools today. Perhaps you are using SCCM or LANDesk, or Altiris or one of the other tools out there. That is helpful and will be valuable for the upfront discovery work, but do you have the automated Operating System deployment tools installed as part of that package? With SCCM, it means having the Microsoft Deployment Toolkit (MDT) and the Operating System Deployment (OSD) tools available. If you don’t have that, well, it would be like owning a reciprocating saw and not using the correct blade. You’ll eventually cut through whatever, but it will take a whole lot longer.
I’ve outlined a number of the technical aspects of the deployment that are critical to the success of the project. Now it’s time to look at the non-technical components that are just as critical to the project as the technical components. While the technical team is working hard at consolidating images, applications teams are inventorying applications, checking compatibility and then packaging the application so that they can be layered appropriately on the new consolidated image, the project managers and business analysts are working hard within the environment to understand how teams interdepend on one another. This is important because you need to do the upgrade scheduling as meticulously as you would the testing of your new image. If you forecast that the financial team is going to be deployed during the last 2 weeks of the fiscal year for your organization, that probably becomes a big problem considering their workstations are critical to the final financial reporting of your company. It might make MORE sense to schedule them for the upgrade after the busy time has calmed down. This is an example of the work effort that goes into the proper scheduling of your deployment and why that up front planning is critical.
I’ve spent some time going through some of the thinking that we in EMC Global Services go through when we are in the process of scoping and planning the upgrades for our customers. There are still a number of people with Windows XP that are staring at the April deadline and simply don’t know where to begin. Do not underestimate the effort level you will have to go through. The longer you wait, the harder it will become. If you have any questions, feel free to contact me at Samuel.firstname.lastname@example.org and I’ll be happy to assist.