Don't panic as Server 2003 rushes towards end of life
There's still time to act
It is time to upgrade. In about a month Server 2003 will receive its farewell set of patches and reach the end of its officially supported life.
You have been putting off the upgrades. I have been putting off the upgrades. With the weekends left to do this quickly evaporating, what's the checklist?
Making a single checklist for all companies is probably not feasible. Addressing the technical issues related to migration is easy. Addressing the organisation and political issues is hard.
That said, migrations left until this late in the game tend to break down into roughly four categories. There are always a few outliers cropping up to keep life interesting, but not as many as the pessimistic among us tend to think.
Unlike with client operating systems, you don't just shove an upgrade CD into your server. Even if that were possible, it would be sheer lunacy with Server 2003.
The changes between Server 2003 and Server 2008 were so major that the only way to migrate is to build a new system and move the applications, settings and so forth across.
Unless they need 16-bit applications, few companies are using Server 2008 today. The majority are using Server 2008 R2, with Server 2012 and Server 2012 R2 seeing decent uptake and Server 2016 just around the corner.
It is hard to describe just how much things have changed between Server 2003 and Server 2012 R2 without writing a book, but let’s just say it is enough to keep some administrators up at night.
The simplest migrations are those where you migrate a Windows application from Server 2003 to another operating system and the developer of that application has tested and certified it for use on another operating system.
Here the developer will provide ongoing support for the application, and if you run into trouble with it the developer can't cite the new operating system as an excuse not to help you.
This doesn't mean migration will be easy or cheap. Some developers require you upgrade to a newer version of the application – or another application on which it is dependent, like a database – to be fully certified on the new operating system. This typically comes with a price tag attached.
Migrating your data to the new system may or may not be straightforward. In some cases the application administrators know what to do. In others a call to the developer – with a possible support cost involved – might be required.
Either way, the simplest solution from a business standpoint is to throw money at the problem. It can be implemented in a relatively short time with a minimum of fuss and muss. It is the best kind of migration.
Where's the developer?
If your application developer is not ready you have several choices, none of them appealing. If your developer is working on a solution then you could wait and implement the solution when it arrives, but be aware of the potential legal issues that presents – especially if you are a regulated industry, such as a bank.
You could write your own replacement software, though with a month to go before Server 2003 hits end of life I suspect you are a little late to start that project.
You could migrate the application to a new operating system anyway. Chances are quite high that it will work just fine. The downside is that you will need a skilled systems administrator, as there won't be support for migration to an operating system the developer doesn't support.
This could put the systems administrator in a legally compromising position if anything goes wrong, and there may be indemnification or payment considerations.
You can migrate to another application that supports a newer operating system. This is typically a multi-year affair. It is expensive, difficult, and at a minimum will require retraining staff. It probably also involves converting data and re-writing middleware to work with the new application.
File sharing fumble
Some of the applications businesses depend on are part of the Windows operating system. One such is file sharing. Millions upon millions of businesses around the world rely on Windows file sharing to centrally store and access files.
Over the generations, file sharing has evolved. For the most part, it has emphatically evolved for the better: SMB 3.0 is a huge leap from CIFS.
But there are catches too. Newer versions of Windows don't use 40bit encryption, so by default they won't talk to older, out-of-support operating systems.
Many other changes have occurred, not all of them positive for all customers. Consider Distributed File System Replication (DFSR), which has gone through a number of iterations since its introduction in Server 2003 R2.
A server running DFSR on Server 2003 R2 with default settings, for example, could cheerfully share 5TB of files spread across 8M files and still be able to serve those files live to dozens of active users.
Serve those same files on a Server 2012 R2 system with default settings on hardware three times as powerful and watch the whole thing grind to an halt.
Microsoft's vision for DFSR's use cases changed over the years. Instead of being something that would live alongside other features on a server that might run dozens of services, Microsoft now envisions DFSR running on dedicated systems with massively powerful I/O capabilities.
The result is something that, even after tweaking the settings, is too resource hungry to work in a shared environment in the same way as its predecessor.
Research is required. To upgrade from server 2003 to Server 2012 R2 it is not enough to read about Server 2012 R2. You need to read about all the incremental changes to the Windows Server features that you use as they evolved in the intervening operating systems.
Small but important changes may have crept in during previous iterations and are simply not discussed. One such example is Software Restriction Policies. AppLocker replaced Server 2003's Software Restriction Policies when Server 2008 R2 came out. With Server 2012 R2 nobody talks about Applocker as the replacement for Software Restriction Policies: you are just expected to know what it is.
The Windows operating system is hundreds of individual applications
See also Remote Desktop Services replacing Terminal Services, and dozens of other name changes over the years. The Windows operating system is hundreds of individual applications all of which undergo the same sort of evolution as any other Windows application from a third-party vendor.
If you use inbuilt Windows features then you will need to apply the same research and testing as if you were looking to migrate a third-party application.
Be aware also that modern versions of Windows Server contain many new features that will make the lives of Server 2003 administrators easier. From group policy management to printer management, encryption to BranchCache and DirectAccess, Windows Server has added a lot to love over the years.