Microsoft Workloads on AWS
How to migrate legacy IIS-based applications to new versions of Windows Server without refactoring using AWS EMP
Many organizations have legacy Internet Information Services (IIS) based applications that run on Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2. These versions of Windows Server are no longer supported and customers are looking into ways to migrate these legacy applications onto modern Windows Server and IIS-based versions without having to rewrite the application.
Since October 2020, AWS End-of-Support Migration Program for Windows Server (EMP) has been available as a Windows Server End of Support (EOS) solution for customers to use at no cost. AWS EMP helps customers migrate legacy applications onto modern supported versions of Windows Server operating systems without any code changes.
The AWS EMP tooling is available as a self-service option. As of release 1.4, it provides the necessary tools to migrate an IIS 6.0, 7.0, and 7.5 based application and any other application dependencies the IIS website may have onto a modern, secure, and supported Windows Server version. This migration process decouples the application from legacy OS and its IIS components and ports the application to newer Windows Server version.
In this blog post, I outline why and how one of the largest city governments in the US migrated their web application running on Windows Server 2003 on-premises on IIS v6.0 to Windows Server 2019 on AWS. I will also walk through step by step how to migrate a sample IIS-based application that matches the customer application.
Customer Success using EMP
The AWS EMP team worked with one of the largest city governments in the US to help them re-platform one of their legacy capital budgeting applications. The Web application was running on Windows Server 2003 on-premises on IIS v6.0 and connected to an Oracle database.
With Windows Server 2003 no longer supported by Microsoft as of July 2015, these core business applications were running on an unsecure and unpatched operating system. The customer attempted to install the application on Window Server 2019 using an archived set of installation media. However, the installation failed due to the dependency on the legacy OS. Hence, the customer decided to explore the EMP option to migrate the application to Window Server 2019.
After going through the discovery process, we began by attempting to use the installation media on a clean Windows Server 2003 instance on IIS v6.0 to verify the application installers. The application installed but the resulting configuration in IIS was different to the configuration on the production server.
At this point, the EMP IIS migration feature allowed us to export the configuration from a clone of the production WS2003 server and import the configuration onto IIS v10.0 running on Windows Server 2019. We identified additional dependencies for the web application on the production server and packaged them using the EMP packaging process. The resulting EMP package was also deployed to the Windows Server 2019 instance on AWS.
As the migration of the application onto the Windows 2019 instance was complete, we established a connection to the Oracle database. This allowed the login page of the application to load successfully. We engaged one of the users of the application to perform user acceptance testing (UAT) and confirmed that the application was running as expected.
Overall, within a week of engaging the AWS EMP team, the application was up and running on a newer version of Windows Server.
Sample legacy application migration using AWS EMP
In the following section of the blog, lets dive deeper into how a sample application matching the customer’s legacy application can be migrated using EMP. We will use a sample application called CRSite. This is an IIS based ASP.NET web application that generates a summarized sales report.
Refer to the documentation here to make yourself familiar with how EMP approaches the migration of an IIS-based application. This blog complements these instructions to carry out the migration.
Discovery and Planning: Identifying any application dependencies
On the legacy source server, launching IIS Manager and inspecting the Sites node shows you the IIS website (CRSite) which is part of the CRSite Application Pool that requires migration. The following image shows the sample application that we migrate using AWS EMP.
Figure 1: Legacy IIS Website and Application Pool
During this discovery and planning stage, it is important to understand if the IIS-based application has any application dependencies on the same legacy server. Sometimes this information may be unavailable or unknown. You can find this information using the following two methods.
In the first method, reviewing the web.config file found in C:\inetpub\wwwroot\CRSiteApp shows the crystal report assemblies that the website is dependent on.
If this information cannot be retrieved by inspecting the web configuration files of the website, you can use the second method. This second method captures a log file of the functional usage of the application using Sysinternals Process Monitor (Procmon.exe). Inspecting the resulting log file shows the IIS web server Worker Process (w3wp.exe) accessing Crystal Reports files when the application is in use.
Figure 2: Process monitor output showing crystal report files
Now, we are aware of a third-party application dependency for CRSite. So, we proceed by creating an EMP package for the Crystal Reports application in addition to migrating the web application.
Stage 1: Migrating the CRSite web application
Windows Server 2008 R2 Steps:
On the legacy Windows 2008 R2 Server download and install the AWS EMP Compatibility Package Builder and run the following command in PowerShell:
After the command runs, it creates a folder called EMP-IIS in the C:\Program Files (x86)\AWS\EMP\Tools\IISTools folder as shown in figure 3.
Figure 3: EMP-IIS folder created via the export process
The application files and web configuration are exported as part of this process. As shown in the following screenshot, the application content can be found within the individual website folders that you want to migrate.
Figure 4: Web application files and configuration export
During this process, the command also captures the Windows Features that have been installed on the source server. The Windows Feature information is captured in the Config.xml file found in the root of the EMP-IIS folder.
Windows Server 2019 Instance Steps:
On the modern Windows Server 2019 instance download and install the AWS EMP Compatibility Package Builder and run the following command in PowerShell:
After the command runs, it installs and configures the Windows Features including the IIS components (captured during the previous export process) and sets up the web application and pool successfully as shown below.
Figure 5: Web application successfully set up in modern version of IIS
The web application configuration and content deploys to the native wwwroot location on the modern OS.
Stage 2: Packaging Crystal Reports from the source server
In the Discovery and Planning stage, we identified that the website is dependent on a version of Crystal Reports that is installed on the server. We must ensure that the dependent legacy Crystal Report application is also migrated to the target Windows Server 2019 instance.
Note: This blog assumes that the reader has an existing understanding of the EMP Guided Reverse Packaging process and therefore only covers its high-level stages. Familiarize yourself with this process if you are new to it.
Before running GRP we need to modify the GRPRules.json file found in the GRP installation directory and add the additional runtime processes names we would like to monitor. In this case it will be the w3wp.exe process.
Figure 6: GRPRules.json file
Select the Crystal Reports installation folder located in C:\Program Files (x86)\SAP Business Objects\Crystal Reports for .NET Framework 4.0 when adding the user selected files.
Figure 7: Add installation folder
At Runtime Analysis exercise the application to generate process activity which will be monitored by GRP in order to discover any additional dependencies that need to be added to the package.
The Crystal Reports application does not have any standard entry points such as desktop/start menu shortcuts, services etc. that could be used to exercise the application. In this situation, the web application is loaded and exercised.
Figure 8: Crystal Reports Web Application
During the packaging process EMP identifies application incompatibilities and auto enables an in-built feature called DEPOptOut to ensure that the packaged Crystal Reports application works successfully on a modern operating system.
Stage 3: Deploy the EMP package to the target Windows Server 2019 Instance.
In Stage 1, we installed and configured the website. In this step, we deploy the Crystal Reports EMP package that was created and link it to the website and application pool. To do this:
Follow the Requirements for Deploying an EMP Package section and attach an IAM role to the target Windows Server 2019 instance to enable the Crystal Reports EMP package to be deployed.
Deploy the Crystal Reports EMP package by running the following command using an elevated command prompt:
This command deploys the Crystal Reports EMP package to C:\Programdata. The /DeployAllRegistry switch sets up the relevant registry keys for IIS integration.
As a final step, launch PowerShell with elevated permissions, navigate to the IISTools folder found in C:\Program Files (x86)\AWS\EMP\Tools and run the following command (modifying the package folder name as required):
This sets the relevant integration for the CRSite web application to be able to access and work with the EMP package with Crystal Reports.
The following images of the application being launched on the source Windows Server 2008 and the modern Windows Server 2019 instances. The Process Explorer view shows how the w3wp.exe process that serves the CRSite application runs on the Windows Server 2008 instance compared to when it runs on Windows Server 2019 instance using EMP. On the Windows Server 2019 instance the w3wp.exe process that serves the CRSite application runs as a child process to the EMP compatibility package engine intercepting, redirecting and addresses any inherent compatibilities issue of the application.
Figure 9: Process explorer view shows application running on Windows 2008 R2 source server
Figure 10: Process explorer view shows application running under EMP on the target Windows Server 2019 instance in AWS
Clean-up
We have now successfully migrated the CRSite application to a modern Windows Server. To avoid ongoing charges for resources you should terminate any AWS EC2 instances that were created for EMP Compatibility Package creation (Windows Server 2008 R2), deployment (Windows Server 2019) and any legacy source servers (Windows Server 2008 R2).
Conclusion
Not all legacy Windows Servers can be successfully upgraded to a modern supported operating system. IIS-based applications that run on legacy versions of Windows Server 2003 and 2008 that cannot be upgraded not only pose security issues but also become a blocker to cloud adoption and further modernization efforts. AWS EMP is self-service, and with the 1.4 release, it is now possible to migrate those legacy IIS-based applications and its application dependencies on the server using EMP onto a modern Windows Server instance on AWS.
To gain hands on experience using the tool or if you need support to get started with your EMP journey, please complete this form.
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.