Windows Server 2008 Has Reached End-of-Support — What Should You Do?

On January 14, 2020, Microsoft ended support for Windows Server 2008 and 2008 R2. That means regular security updates have also ended.

However, there are a lot of customers using legacy versions of Windows. In this post, we will discuss the challenges preventing companies from moving, AWS’ End-of-Support Migration Program (EMP), and two Mission case studies where we leveraged EMP.  

What End of Support means for enterprise customers

EOS operating systems present a variety of issues.

From a security standpoint, an EOS system poses security risks. No security updates means exposure to an increasingly insecure environment.

EOS operating systems pose issues with regards to compliance, as many customers are required to run a currently supported version of an operating system to meet industry regulations such as HIPAA, SOC, or other industry-specific requirements. 

There is also a high operational cost involved with EOS applications. Running EOS operating systems and applications requires an isolated set up and you have to pay the provider extended support costs. This can turn into several thousand dollars per instance and the cost associated with running EoS applications as well. 

Finally, EOS operating systems and applications pose challenges when it comes to cloud adoption, since Most cloud providers are required to pull down the instances of EOS operating systems.

Resolving these types of issues requires upgrading your operating system and moving your applications over to a newer version of Windows. Which begs the question: Why are people not acting?

There are several challenges that organizations typically run into:

1. Lost expertise, code and/or installation media. Some of these applications are so old, and customers lack personnel expertise to upgrade their Windows workloads.
2. High cost and time commitment for refactoring or recoding the application. When you have to refactor or recode these applications for a new version of Windows, it requires significant cost and time commitment. If the application is not something that is impacting the business right away, the motivation to go through that exercise is pretty low.
3. Incompatible applications. There’re also a lot of applications which are just not compatible with new versions of Windows because these are custom, off-the-shelf applications that are not available on new versions of Windows. So that could be another risk associated with moving to a new version of Windows.
4. Dependencies on older runtime versions like Java, .NET, etc. Finally, dependencies that these applications have with runtimes like Java and .NET are just not available in the newer versions of Windows. There might be an incompatibility issue which requires you to go through the refactoring and recoding effort to make sure that the application can run on the new version of Windows.

In response to these challenges, AWS has created tools and services that allow customers to get their applications upgraded to a new version of Windows without requiring any kind of recoding and replatforming. This is known as the EoS Migration Program (EMP) for Windows Server.

End-of-Support Migration Program (EMP) is an offering from AWS which consists of the technology & tools required to get the application upgraded, and also the expertise directly from AWS, or partners such as Mission Cloud, who have the expertise in Windows and EMP. 

A typical 3-step EMP engagement process

1. Application assessment. The first step is to look at what application the customer is looking to upgrade and the dependencies the application has in the environment. We go through this process for application assessment where we do a discovery of the application. We define the testing criteria with the customer in terms of what they would like to test when the application actually gets upgraded over to a new version of Windows. So that’s the first step to setting the stage for a successful deployment.
2. Compatibility packaging. In the second step, we do compatibility packaging. We take the application and we package it up using our EMP compatibility tool with all the underlying dependencies. This will then be moved over to a new version of Windows.
   
   If for some reason the customer doesn’t have access to the media for the application, we have an option to do Reverse Packaging from a production environment. In this case, we let the EMP tool run and monitor the application and all the underlying dependencies that it has, and then we capture all of that in a package.

3. Migration. Once the package is created, we can take the package and move it over to a new version of Windows, 2016 or 2019. Then the package, and the Windows instance with that package running on it, are moved over to an EC2 Windows instance of AWS. So that’s just a regular migration and that can be accomplished using tools such as Amazon Server Migration Service (SMS), or CloudEndure, which is another tool to perform server-level migration for on-premise workloads.
   

EMP Packaging Details

The source is the legacy application and the underlying operating system. 

The target contains the legacy application with the underlying legacy OS dependencies in a self-contained package. This package can then run on a newer version of Windows.

What we’re basically doing is we’re creating a redirection process which intercepts any Windows API calls that are required for the application. Those API calls are served directly from within the package. Most of the time those API calls are calling legacy Windows dependencies, so those are all packaged into the package that we created and are all being served from the local instance in that package.

We are also running things in isolation. The older version of the runtime can only be accessed by the packaged application so that we don’t create any kind of security risk in the rest of the organization. This application isolation is super critical, and is done as part of the packaging process. As part of the packaging process, we’re also resolving any OS incompatibilities that we might run into and addressing those directly from within the package itself.

Why EMP?

EMP is a permanent solution to the EOS problem. Some competing solutions allow you the option of simply extending support on the legacy version of Windows. This is not sustainable though, as you’re basically kicking the can down the road. You might buy extended support today, which will serve you for the next two or three years. But when you run out of that extended support, you basically have the exact same problem again.

EMP is future-proofing your application because we are decoupling the application from the underlying OS dependencies. It allows you to basically get the latest versions of the security updates. Your application, once it’s packaged, runs on a new version of Windows. It reduces your security exposure. It allows you to then be compliant with the industry regulations that you might be subjected to because the application at that point is running within that packaged container in a new version of Windows. Also, you don’t have to pay extra for support.

So this becomes a super cost-effective way to run your application. You don’t have to do any application-level refactoring or re-coding. This is a really big advantage of EMP.

The question that often comes up is, how expensive is this EMP application in terms of resource overhead. This application is super lightweight. In all the testing we have done thus far, the overall CPU head is less than 1%. We’re using roughly 10 MB of additional disk space to run the package itself. The RAM overhead is super-minimum. We’re not installing any agent or client, and there is no additional infrastructure that’s required to run this application. It’s a really lightweight packaging that we do as part of this EMP tooling. So the overhead for the customer is basically nonexistent. They won’t even realize that the application is running in a package on their EC2 instance when it moves over to AWS.

Case Studies: Mission Expertise with Customers on Windows Workloads

 MicroSearch Corporation

MicroSearch Corporation is a digital services company that specializes in providing custom video and document search engine services for clients across the US. When they approached Mission, they had ancient hardware on premise and servers running older versions of Microsoft Windows and Microsoft SQL Server.

Mission was able to consolidate those 36 on-premise servers down to 24 cloud EC2 servers, providing some cost savings as well as reducing maintenance, and ultimately enabling Windows applications to function optimally in AWS. Furthermore, we were able to leverage virtual desktop infrastructure for end users to be able to access sensitive applications and data such as QuickBooks. Mission was able to eliminate about $100,000 of projected CapEx costs compared to what it would have cost MicroSearch to refresh their datacenter.

ATCC

ATCC maintains the largest and most diverse collection of biological materials in the world. After years of using the same provider-hosted servers, ATCC unexpectedly found itself with just weeks to migrate it’s entire Windows-based environment – 8TB of data -  just before the data center of the host shut down. Definitely not a good situation to be in.

Leveraging CloudEndure, Mission proceeded to successfully migrate ATCC’s entire Windows environment to AWS cloud in just one day, Well ahead of the data center’s closure deadline. This directly demonstrates how well we can migrate on very short deadlines. Additionally, we were able to set up a cross-regional disaster recovery environment in AWS also using Cloud Endure. And ATCC experienced no unexpected downtimes or issues during this very complex migration.

Get in Touch

To learn more about how Mission can help you navigate the EMP program and successfully migrate your Windows workloads to AWS, contact us here.