Windows Server 2003 end of life doesn't have to be the end of the world

One of my favorite idioms is "Change is Constant". No group has had to embrace that motto more than IT Operations, especially in recent years. As if the daily changes weren’t enough, we all have one more big item to deal with, the End-of-Life for Windows Server 2003.

The official End-of-Life date for Windows Server 2003 is July 14, 2015 (that’s Bastille Day for you history buffs). For IT Operations teams large and small, the date looms like a doomsday clock. Why does this particular platform end-of-life and pending migration seem so ominous? The answer, in a single word, is "Applications!"

Modern datacenters run distributed applications, crossing multiple servers and platforms. For larger companies, these applications number in the hundreds or thousands. This migration isn’t about moving programs -- it’s about moving applications. And moving applications is a complex, worrisome task.

Migrating one box from Server 2003 to Server 2012 isn’t necessarily difficult. Migrating all of the distributed applications and all of their dependencies that use Server 2003 in any way can quickly become a nightmare. Often the application topology is poorly understood -- and many times IT Operations teams can’t identify which servers are actually parts of which applications, or which applications involve which servers. Before touching even one machine, the IT organization must answer a few key questions:

1. What distributed applications are running in the datacenter, and how are they performing?

You need to take an inventory and then benchmark performance. Taking an inventory is critical for planning and checking your move: determining what has to move, estimating how long it will take, and confirming that everything actually moved. Benchmarking performance is essential so that you can compare before/after service delivery.

While inventorying the entire datacenter may seem daunting, a good first cut is to focus on the distributed applications (or business services) for which the Ops team is responsible for tracking availability and performance.

2. For each application, which servers make up the application infrastructure?

This is a much more difficult question to answer from either common knowledge within the IT Operations team or from documentation. Remember our change mantra? Even IF an organizations has a static list of servers for each application, chances are it is now out of date. After all, many of the applications that are using Server 2003 have been around longer than a lot of the IT Operations staff!

The only effective way to add this data to the inventory list is through an automated discovery process that can both see AND understand the relationship between servers and applications.

3. For any given server, which applications are using it?

Like Question 2, the answer to this dependency question cannot be trusted to manually created static lists. The same kind of automation is needed, but one that understands how servers can be shared across different applications -- allowing for a many-to-many relationship to be captured and reported.

Once the inventory is complete, the actual migration plan is simple to put together.

1) Automatically map all distributed applications across the datacenter (and through the cloud, if appropriate)

Using an application mapping and discovery tool will actually give you the information you need to answer the above three questions at once. A dynamic automatic tool is better, so that you can be sure of accuracy before the migration and perform a quick check of completeness afterward.

2) Create two dependency books: one for applications and one for servers

Take reports from the mapping tool to add dependency lists with each inventory record -- server dependencies for applications; and application dependencies for servers.

3) Create a baseline of performance for each application at each server

Just getting the migration done is an accomplishment, but the A+ team will take a performance baseline pre-migration and perform a post-move test to ensure equal or better performance.

4) Migrate shared servers first, checking all dependent applications against their baseline

It’s best to start with the most critical servers first (from a shared resource perspective). This allows performance checks to be executed along the way.

5) After shared resources are converted, migrate collections of servers together by application

Proper planning, inventorying and execution can not only make your migration from Windows 2003 go smoothly, but can also result in higher performing distributed applications. Just make sure that before you start the migrations, you have all the information that you’ll need.

Image Credit: Milkovasa/Shutterstock

Vic Nyman is the co-founder and COO of BlueStripe Software. Vic is a successful veteran of multiple ventures in the systems and application management field. Before founding BlueStripe, Vic served as Chairman and CEO of Relicore in the ITSM Discovery and Configuration management market. Vic has also held leadership positions with Wily Technology and IBM.