How to upgrade your legacy Windows applications to new versions of Windows Server without refactoring

By Baris Furtinalar – Sr. Microsoft Specialist SA
Serdar Nevruzoglu – Solutions Architect

Windows Server 2003 has been End of Support (EOS) since July 2015 and Windows Server 2008 has been EOS since January 2020. However, many customers still find themselves struggling to upgrade applications running on these EOS operating systems. The primary reason for this is that these legacy applications are often not supported on newer versions of the operating systems, which requires these applications to be refactored. Refactoring is expensive, and customers often find that the expertise or code needed to refactor applications is no longer available.

An application running on EOS operating system carries risks. First, no security updates means exposure to future vulnerabilities and compliance issues. Second, paying for extended support does not resolve the incompatibility problem, it just delays dealing with it. Third, because these applications often have to be run in isolation behind firewalls or other security software means higher operational costs. Finally, because EOS operating systems are no longer available in the cloud, these become a blocker for cloud adoption.

Customers told us that they want a long-term solution that enables them to easily manage and move their legacy applications to cloud. We listened to your feedback and released the End-of-Support Migration Program for Windows Server (EMP) at re:Invent 2019. AWS EMP for Windows Server helps customers migrate legacy Windows Server applications to the latest, supported versions of Windows Server on AWS, without any code changes. As of Oct 15^th, 2020, the solution is available in a self-service motion for customers.

In this blog, I demonstrate how the EMP self-service capability works. I will also walk through a tutorial showing how to migrate your legacy applications.

How EMP works

1. Download the EMP Compatibility Package Builder from this link.
2. Install the package builder to the packaging machine. In this example, packaging machine is a server running Windows Server 2003 R2.
3. Package the legacy application. You have two distinct options:
4. Standard packaging: If the installation media is available for the legacy application, you can use this media during the EMP packaging process.
5. Reverse packaging: If the installation media is not available for the legacy application, you can still migrate this application through a process called reversed packaging. You need a server that already has the legacy application installed in addition to the packaging machine.

A packaging machine is a server instance of the Windows operating system version which is supported by the application to be packaged. In this blog, I used a Windows Server 2003 R2 as my packaging machine.

4. After you create the package, copy it to the destination server. In this example, I used a Windows Server 2019.
5. Attach the IAM role to the Amazon Elastic Compute Cloud (Amazon EC2) instance required for deployment.
6. Deploy the package to a supported Windows Server.

Demo: Migrating Oracle11g with installation media (Standard Packaging)

Step 1: Download the AWS Package Builder

The Package Builder is provided in an MSI installer which can be installed on the packaging machine. The AWS Package Builder is the primary tool used to create EMP compatibility packages. These packages let you deploy legacy Windows applications that are otherwise incompatible with modern supported Windows versions.

Step 2: Install AWS Package Builder

EMP is licensed solely for the purposes of migrating Windows applications of AWS customers to Amazon EC2. Accept the defaults or modify as you desire to install the AWS Compatibility Packager.

Step 3: Creating Packages with the AWS Package Builder

1. Launch the AWS Package Builder from the desktop shortcut or double click Compatibility.Package.Builder.exe on the installation folder.

2. On the Select Package Folder page, click Select Folder, select a Package Folder to define where the Package will be created, then click OK.
3. Click Next to start capture process. The package builder starts a capture that takes a snapshot of the Windows Server 2003 R2 source machine. This snapshot determines changes made by the installation process.

4. Install the legacy application you want to migrate, as prompted by the compatibility package builder. This means that the tool is in listening mode and captures all of the changes on the source machine.

5. Exit the packaging process on the Install Application screen.
6. Click the setup.exe to start the installation of the legacy application. In this blog, I selected Oracle 11g to demonstrate the process.

7. After installation process is completed, I validated the application by logging into Oracle database using sqlplus.

8. On the Run Installed Applications page, select the shortcuts created by the installation. In this step, the tool is monitoring what processes and system-level APIs are called, so it creates a mapping of the application’s dependencies.

9. On the Capture Files page, review the files captured by the packager during the installation and at runtime.

The “Captured Files” page shows all of the files created/changed by the monitored application. Check and confirm that these files and folders are indeed part of the application installation process. The left side pane called “Files in package” can be used to view or remove files and add redirections for files captured in the package by the install capture step. The right pane shows the files requested at runtime. You can add these files and folders to the final package by right-clicking and selecting the “Include in package” option.

10. Click Next once any required changes have been made to the registry keys. Clicking Next displays the “Captured Registry Keys” page that allows the user to view and manage registry keys in the same way as files. Again, the right-hand side pane shows the registry keys requested at runtime and these can be included in the package if necessary.

11. Name the package.

This package includes all the legacy application files, run times, components and deployment tools. It also includes the engine that redirects the API calls from the packaged application. This resolves the dependencies and decouples the application from the underlying OS. The end result of running the compatibility package builder is a folder.

Step 4: Copy the package over to the destination server

1. Move the package from the packaging machine (Windows Server 2003 R2) to the destination machine (Windows Server 2019).

Step 5: Attach the IAM role to the destination server (Windows Server 2019)

1. From within the AWS Management Console go to the IAM page and click Create role.
2. Choose AWS service, choose EC2 and click Next.

3. On the Attach permissions policies page click Create policy and then click JSON tab.
4. Copy and paste the below IAM policy JSON.

{

"Version": "2012-10-17",

"Statement": [{"Effect": "Allow", "Action": "execute-api:Invoke", "Resource":"*" }]

}

5. Click Review.
6. Give a name to the policy and click Create policy.

7. Navigate to the IAM role creation page and click the refresh button.
8. Use the Filter policies dialog box to find the newly created IAM policy.

9. Optionally assign the tags and click Next. Give a name to the IAM role, click Create role.

10. Attach the newly-created IAM role to the destination machine before starting the deployment of the legacy application.

11. Attach the IAM role to the EC2 instance and click Save.

Step 6: Deploy legacy application to destination server (Windows Server 2019)

1. Navigate back to the destination machine and create a folder named oracle11. This is the deployment directory.

2. On the destination machine open the command prompt, and run the following command:

Compatibility.Package.Deployment.exe /AcceptEula /DeployDir C:\oracle11

Now that I deployed the packaged application to Windows Server 2019, the legacy application is running on a server it was previously incompatible with.

Additional considerations for using AWS EMP for Windows Server 

AWS EMP can only be used to migrate Windows applications. EMP does not support migrating 16-bit applications, kernel mode drivers, applications with shell extensions and low level applications such as anti-virus, firewall and VPN applications.

Conclusion

If you have legacy applications that run only on unsupported versions of Windows Server, you may face security issues, compliance issues, and additional costs to buy extended support. Earlier versions of Windows Server can also prevent you from innovating and moving to cloud-native technologies.

Upgrading to a newer version of Windows Server is your best option, but this is not always possible because some legacy applications dictate or restrict the upgrade options. In this case, customers are limited to using an end-of-support operating system.

Now, with the release of self-service capability for the End-of-Support Migration Program (EMP) for Windows Server, customers can migrate their legacy applications to AWS on their own. As a reminder, EMP should only be used if upgrading an existing system to a supported OS version is not possible.

If you want to get started with migrating your legacy Windows applications on to AWS, head over to the AWS End-of-Support Migration Program (EMP) for Windows Server, where you can download the AWS Compatibility Package Builder and start your migration journey.

AWS can help you assess how your company can get the most out of cloud. Join the millions of AWS customers that trust us to migrate and modernize their most important applications in the cloud. To learn more on modernizing Windows Server or SQL Server, visit Windows on AWS. Contact us to start your migration journey today.