How to Migrate Windows Server 2008 R2 Apps in Minutes
Application abstraction is one way to continue working with applications as Windows Server 2008 comes to an end.
Join the DZone community and get the full member experience.Join For Free
With the end of extended support for Windows Server 2008 R2 quickly approaching, many organizations are starting to realize they don’t have a plan for getting their applications off of Windows Server 2008/2008 R2 and that they may have to purchase an extended support agreement. Paying more for technology with declining value never feels like a good business decision.
You may also enjoy: Moving SQL Server 2008/2008 R2 Databases to the Azure Cloud
In addition, extended support agreements don’t eliminate many of the additional problems that come applications running on aging infrastructure, such as:
Production failures due to run-time errors caused by the OS
Patch management and application update challenges
Third-party/COTS applications that are no longer supported
There is an easy way to re-platform applications running on Windows Server 2008 R2 without having to do any rewriting or refactoring: application abstraction. Application abstraction involves separating the application from the underlying operating system and capturing the needed dependencies. This approach not only enables you to move the app off of Windows Server 2008 R2, but also gives you the ability to modernize the way the application is managed and run as part of automated CI/CD pipelines.
Below is an example (recently demoed on the Webinar: Exit Strategies for Windows Server 2008 End-of-Support) on how you can re-platform an application using abstraction. In this example, Chef Habitat is used to migrate an ASP.NET application from Windows Server 2008/R2 to Windows Server 2016 in Azure with no rewriting or retooling. In addition to abstracting the application from the OS, Chef Habitat can also scan the dependency tree of an app and pull together all of the DLLs so they can be recreated in their new home. A key point here is that Habitat does not pull the source code, so you don’t end up with an unmanaged, unversioned copy of the software. Instead, build packages can be deployed behind the source code and then travel along with the application.
Using the Chef Windows IIS Site Migration Accelerator, I was recently able to migrate 75 applications for a major US company in less than one day. 74 of the applications were captured by the tool automatically, with the last one captured in a new iteration of the tool. The applications were pipelined through Azure DevOps automatically, and last-mile remediations took 60 minutes or less per app.
Below is a brief overview of how the accelerator works.
Step 1. Connect and Run the IIS Windows Server Site Migration Accelerator
After the IIS accelerator connects to the Windows 2008 R2 server it captures all of the dependencies and binds as they exist on the source server. This eliminates dependency incompatibilities like DLL conflicts that can happen when you move an application across different versions of Windows. This also makes Chef Habitat an ideal solution for applications you no longer can compile.
The app is captured in minutes and a zip file is created.
Step 2. Upload Results to Azure and Review
A script is then run to upload the captured file into Azure DevOps and trigger a build. A detailed log is returned that includes all of the applications and application dependencies running the site.
In addition, capturing all of the related dependencies, Chef Habitat automatically parametrizes common Web.config settings like:
The database connection strings
If we have an instance of the site that runs in a development environment that connects to one database and another instance that runs in production on a production database, we can easily modify which database the deployed package connects to by updating the configuration settings.
Chef Habitat is capable of generating different types of files for various targets and CI/CD pipelines. A key point being that you’re not just solving the Windows Server 2008/R2 issue, but also wrapping modern DevOps practices around the old IIS site.
Some additional bells and whistles are included from Chef when loading to Azure, which makes it an attractive option, these include:
The capability to automatically enroll in builds in Azure DevOps
The ability to leverage additional DevOps capabilities built into Azure for managing the application moving forward
Step 3. Optimize Automated Build Processes
Take a look at this Azure YAML pipeline file. We can generate this file for you so that you can instantly run your application package build for testing and validation on systems. Once you’re ready, you can deploy those packages anywhere you’ve got a Windows VM or container.
So regardless of the origin of an application, it can be placed in a new location wherever it will run best. The packages can be run in VMs or containers just as easily. Changing the destination is as easy as saying you want to export the package differently.
As we move forward into an increasingly complex, ever-evolving technological world, we need a way to manage the applications that continue to support our businesses, despite no longer being worked on. Many of us can’t afford to spend the time to reverse-engineer our deployments by hand for every little application running in a legacy world in our systems. We need a way to automatically capture and package these applications so they can be re-homed to safer, more modern operating systems. This solution allows you to do just that, and we’re working on supporting other types of applications as well.
For those of you interested in getting a deeper look at how Chef Habitat works, the Chef online learning curriculum has free, in-depth learning resources to help you understand how to use Chef Habitat, as well as how to use Chef to manage Microsoft Azure resources. The online learning portal, “Learn Chef Rally,” is available at learn.chef.io.
Opinions expressed by DZone contributors are their own.