alphaspirit - Fotolia
How to upgrade Windows Server 2008 before support ends
With the end of Windows Server 2008 support drawing closer, administrators must navigate multiple obstacles, from locating old software to ensuring hardware compatibility.
With the Windows Server 2008 end-of-life date looming, it's time for administrators to let go of the old OS and decide to upgrade or move to the cloud.
It's been more than 11 years since Microsoft released Windows Server 2008 and became a staple in data centers. Many organizations still use the 2008 or 2008 R2 OS. After all, if it's not broke, why fix it? But Microsoft ends support for both OSes on Jan. 14, 2020. Organizations have the option to upgrade Windows Server 2008, but Microsoft and other vendors have pushed applications and services to cloud offerings. Administrators must make an informed choice now.
Take inventory of your servers
Understand the scope of your migration. Do you have 50 servers or 500? What do they do? It sounds simple, but it's a critical first step because it informs everything that comes next for each particular workload. Even if you know the answer, this exercise is helpful for new and longtime team members to get a fresh look at the 2008/2008 R2 environment.
Every workload needs to be accounted for -- even if it's going to be retired soon, not be in production or just be a utility server. This also goes for the test and dev servers. This is not an enjoyable exercise but a necessary one because these Windows Server workloads become a security liability when they no longer get updates.
How to determine your migration path
After you take stock of your servers, the role the 2008/2008 R2 servers play will drive your migration options. Function-driven services, such as Active Directory, domain name services or print servers, play a critical role in the data center.
For many server roles, you can deploy a new version of a role alongside the existing one and then migrate users and services. For example, you can bring a Windows Server 2016 print server online alongside the existing 2008 print server and then use a shorter domain name system timeout value for the old server name to point it to the new server. This provides minimal to no interruption to the end user. Identifying servers and roles forces you to clean and remove extra servers. Migrating built-in Microsoft infrastructure roles is easier than moving traditional applications because you know where to find all the software pieces.
Applications cause migration complications
The biggest challenge to upgrade Windows Server 2008 stems from the applications the server OS runs. The application complexity map can range from a single installation point to hundreds of servers.
Can the application be moved or reinstalled? This sounds easy, but it can be a lot more complex than you think. The application could be a decade old and difficult to find. The application should have been upgraded for security and stability several times over the years.
This creates another issue: How do you reinstall something that has several updates? You can't just click through the installation wizard and call it a day. You'll need to find that additional software. If you run into trouble, you may need to find the application developer -- provided they still exist -- for additional help. This introduces even more complexity to the process.
It's doubtful the vendor will want to help migrate an application if there is an upgrade or cloud-based offering. A migration to the cloud probably wasn't your first thought when you started the discussion to upgrade Windows Server 2008 applications. Many applications now have a SaaS offering, which should be part of the discussion. But a SaaS app comes with new operational costs and complications.
Besides the cloud, you have another option. An in-place upgrade can provide a quick fix for most issues listed above, but it comes with its own challenges.
What about the cloud or containers?
With the upcoming end of life for Windows Server 2008 and 2008 R2, many organizations are investigating a move to supported platforms.
While the ideal situation is to upgrade the application and move it from Server 2008, that's not always an option. Some applications have end of life or are customized so heavily that it's not possible to reinstall. You have the choice to upgrade the server OS, but this has fundamental risks with both the upgrade process and application compatibility.
A relatively new option is to move the Windows 2008 workload to a container. For some organizations, this could be ideal because it shifts a legacy application from on premises to the cloud with minimal effort.
There is some risk involved because it requires the application converter to migrate the application to a container with the correct artifacts. This process reminds me of the first physical-to-virtual migrations; there was a lot of fear in the beginning because there were a lot of unknowns, but now, it's almost second nature. The application containerization process might take a few more steps, but it holds a lot of promise by giving you a portable version that can run on any cloud.
The biggest downside to all this isn't the process or the destination, but the dependence on an older application that might have security or performance risks. This migration effort gives you some additional life with those applications, but there should also be a plan to retire them.
How to upgrade Windows Server 2008
Upgrading Windows Server 2008 starts with a check to see if the hardware can support the newer server OSes. Fortunately, Microsoft shows you what hardware it supports for Windows 2016 or 2019. You should avoid using unsupported hardware.
If you run mostly virtualized workloads, then that makes the OS update process easier. Most times, a VM only needs an update to the virtual hardware, as well as the tools or drivers.
With the right hardware in place, the upgrade should be a straightforward process. You can't upgrade Windows Server 2008 to 2016 or 2019 without an upgrade to Windows Server 2012 first. This multistage approach requires more time and effort, which increases the risk something will break. Be sure to have your backups handy, just in case.
