When we look back on 2014 in IT, there are going to be a couple of things that dominate our thinking and my guess is it won’t be BYOD or Big Data. In reality, a much more mundane yet critical event will be at the forefront. That is the end of extended support status for key workhorse applications Windows XP, Exchange 2003 and Windows Server 2003.  I’ve written before about the level of effort needed to migrate from Windows XP and the bottom line is, if you haven’t started that data migration, you aren’t going to make it.  On the other hand, for Windows Server 2003 you have until July 14, 2015 giving you just enough time to put your strategic plan in place for dealing with your server footprint.   If you don’t know where to begin or have already started, consider these suggestions on designing a plan so you can “beat the clock” and avoid the pain.

Addressing the Risk – It begins with understanding your footprint

Now that we have agreed that addressing the risk up front makes the most sense, how do we address that risk?  In my experience, we start by understanding the problem.  You need to migrate off of Windows Server 2003 before July 14, 2015.  Therefore, you are going to need a complete inventory of all servers running Windows Server 2003 and ultimately all applications that are running on those servers.  This includes any “commercial off the shelf” (COTS) applications you may have (such as antivirus, firewall, management software, printer drivers, etc) as well as any custom applications or more importantly, any BUSINESS CRITICAL applications that are running on that server.

Hopefully, your organization has a management process in place that uses tools and agents to be able to track the servers that are active in your environment.  Even if it doesn’t give application inventory information, knowing which servers in your environment are running Windows Server 2003 is better than having nothing to start with.  The servers themselves aren’t where the risk is.  Being able to understand what applications run on those servers and their relationship to the business is what is important.  Another consideration is the compatibility of your applications with Windows Server 2012. There are tools to help with this issue but I don’t have space to address it here. Feel free to drop me a line if you have any questions.

Next, you need to identify the owners of those applications.  This could become challenging since if you are running custom applications on Windows Server 2003. What if the developers are not in your organization any longer or the company you bought the app from no longer exists. In any case, someone needs to be responsible for the app or you should consider retiring it.

Other technical considerations that might be of interest are the architecture of the servers and version of Windows Server installed.  Windows Server 2003 is a 32-bit flavor (remember those?) and Windows Server 2012 comes only in 64-bit.  Windows Server 2008 was the last 32-bit OS Microsoft produced.  Be sure to note the OS flavor and whether it’s a physical server or a virtual server.  The more info you can capture, the better your design considerations and ultimately, the smoother the transition.

Now what?

Now that you have your server and application inventory, you will be in a better position to begin determining what you will do with these servers and applications.  Will you take them to a public cloud (AWS, Azure), put them in a private cloud or perhaps try to do a like for like migration to other physical hardware.  Regardless of which path you choose, there is a lot to consider and whether you have a strategy or not, there are ways for you to do the planning to determine what the best course of action will be for those applications.

It’s important to keep in mind that one size may not always fit all your applications so consider your options.  If you already have a strategy worked out, perhaps you are taking your entire physical inventory and moving it to a converged infrastructure, then you are ahead of the game.  It is worth noting though that since you have applications running on Windows Server 2003, those applications may not be suitable for virtualization on your converged environment.

Remember, when reviewing your application portfolio, it is important to understand what kind of downtime can be accepted as part of the migration effort.  If you have production critical business apps, you may have to put a strategy in place to migrate carefully to minimize or eliminate downtime.  Working with the application owners to understand these hot points needs to be a part of your risk mitigation process.

Performing this due-diligence is the Design Phase of our curve and by going through this process, you have put yourself on the green path above to frontloading your risk.  As you can see from the curve, if you get the risk taken care of first the rest of the process is downhill.

Getting the rest of the way

Once you are able to the Construction Phase, you are getting to the more mechanical processes of the project.  The way you migrate the applications and the servers becomes a more mechanical process that you can leverage tools to complete.  Tools such as Flexera’s Admin Studio, AppZero and RiverMeadow are available for assisting in testing compatibility and assisting in the migration of your workloads to the target environment.  It would be worth investing in experts in the tool so you aren’t learning as you go, but you may decide that your team can perform the migration of the less critical applications in house and leverage assistance for the more critical applications.  Understanding your limitations and ensuring that you have budget for possible assistance, not just for tools, will be important to your planning.

Conclusion

Windows Server 2003 represents a significant install base of servers out in enterprises today.  IT shops need to turn their attentions to this looming giant of a task so they can limit risk and ensure success.  Take my advice. Following the green path is the secret to sleeping better at night through this process.