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?
More ReadingThe Great Windows Server 2003 migration: How to plan your tripFire, flood and vomit: Defeating the Great White Whale of FailWin Server 2003 addict? Tick, tock: Your options are running outOut with the old: the end of Microsoft support can be your storage opportunityWhy 1.6 million people will miss Microsoft's Windows Server 2003 date with fate
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.
When the application you need to migrate is a website, things can get pretty complicated. This is usually because there is a lot more to worry about during migration than just the operating system.
Believe it or not, there aren't a whole lot of Win32 or Win64 applications that will give administrators trouble when migrating from Server 2003 to one of the newer operating systems.
Over the 20 or so years I have been a practising systems administrator I have migrated thousands of applications between different versions of Windows. While the 9.X branch was a pain, NT branch migrations tend to be (mostly) smooth.
The same can't be said for web applications, which have all sorts of bizarre dependencies. They can require specific versions of the web server because the application relies on some bit of security no-no that future versions simply won't allow.
Web applications often rely on just-in-time interpreted languages with their own binaries, such as PHP or Python, and these languages change often enough that moving from one version to the next would break the web application, even if the operating system and web server don't change.
Unfortunately, it might not be possible to install older versions of interpreters on newer operating systems. They will have different security restrictions from Server 2003's IIS, creating another source of potential problems.
Post-Server 2003 systems have different approaches to security. File system security defaults are tighter. The user context for applications matters. This can affect IIS modules and applications, but it can also affect Apache.
To migrate your web application successfully first make sure it will work with the version of the language interpreter you plan to install on the new system. Then do a test migration and spend some time working out the security issues. (Usually, getting everything running under the same user context solves everything.) After that, things should be good.
If you use IIS do try to upgrade to Server 2012 R2. It is rather a lot better than its predecessors, and it finally has an FTP server that doesn't suck. Your users will thank you for it.
If you have successfully migrated your applications to a post-Server 2003 operating system there are a few things to consider. The first and most important is training: there is a big gap between Server 2003 and its successors, especially if you are jumping all the way from Server 2003 to Server 2012 R2.
Migrations are stressful. They entail a lot of late nights with caffeinated beverages and levelling up the sysadmin Google-fu. It helps to plan a post-migration refresher course to cement the newly learned skills. You need to ensure that administrators are comfortable not only with the bare bones of running their applications, but with all the features of the new operating system.
The goal is to move beyond good enough towards best practice. Include a full review of backup and disaster recovery plans as many of these involve only backing up application data or configurations, and call for a rebuild of the operating system and application followed by a reinjection of the data and configuration files. Systems administrators should practice this enough to know the procedure cold on the new operating systems.
Documentation is critical. So is an outside eye. Even after a successful migration, if your company is covered by any regulations, or holds any IT-related certifications or compliances (such as HIPPA, PCI and so on) you will need to schedule a new audit. Migrating away from Server 2003 is big enough to invalidate your last audit.
Last but not least: scan your network. Don't let a rogue box rot in the back and risk getting you in trouble with auditors, lawyers or malware. Be 100 per cent sure you have found everything that needs to be migrated, and then check it again.
Spend to defend
We don't all get the option to upgrade business-critical Windows applications. For some companies there are viable ways to defend your ageing estate. The bigger you are, however, the less likely it is that this will apply to you.
If you can't migrate, have IT lock down and defend your unsupported systems. It will cost money to get it done, but not nearly as much as handling the non-IT portions of the equation properly.
Letting operating systems or applications exit support is an issue that probably needs oversight from lawyers, relevant regulators and external auditors who can check that every reasonable measure has been taken.
Most importantly a plan should be in place to get towards a supported state. The more regulated your industry, the more critical this is.
Server 2003 exits support on July 14, 2015. Good luck! ®