One of the most complex application migration scenarios is also one of the most common ones faced by enterprises today: how to migrate custom or bespoke applications. These applications not only represent a large portion of the portfolio but also tend to be pushed to the back of the line in terms of prioritization for remediation. Key reasons are a lack of knowledge about the application, missing or outdated documentation, or worse, no source code.

The absence of source code means an inability to recompile the application onto newer architecture. Migrating the application from Windows 2003 to Windows 2012 or from 32-bit to 64-bit becomes a major hurdle. Without being able to recompile and reinstall onto a newer operation system, the application is destined to be orphaned on its legacy Windows 2003 instance.

With less than 100 days away from the end of extended support for Windows 2003, enterprise customers are left scratching their heads on how to remediate or get off Windows 2003. Even if the plan for some of these more complicated applications is to stay put on Windows 2003 and pay Microsoft for both Premium Support and a Custom Support Agreement (CSA), the enterprise must still submit a Windows 2003 exit strategy to Microsoft in order to qualify to buy a CSA. Creating a plan to migrate an application that can’t easily be migrated, paying a CSA and submitting a plan to Microsoft to migrate applications that can’t easily be migrated… The complexity of the scenario is clear, but what’s the solution?

The first step is to assess the importance of these applications in order to determine if they will continue to satisfy the needs of the business. If the answer is yes, the next step is to understand the framework in which they were built, such as ASP.NET, Java, Cold Fusion, or PHP. Fortunately, many of these frameworks run on Windows 2012 by leveraging Windows on Windows commonly referred to as WOW64. Unlike its 32-bit predecessor (WOW), WOW64 provides backwards compatibility to 32-bit applications but does not address 16-bit applications. This means that the last stop for 16-bit applications in their journey is Windows 2008 x86. Most instances of applications with 16-bit dependencies are 10+ years old and were likely left over from the days of Windows 2000. These custom apps are more than likely 32-bit and can be migrated onto the latest release of Windows 2012 R2. Now the challenge remains – how to get them there?

The purpose of an up-level, container-based migration tool such as VirtaMove is to automate the process of migrating these applications from the existing Windows 2003 server instances onto Windows 2012. This is accomplished by rehosting, redirecting, and reinstalling the application onto the new destination server whether it’s physical, virtual, on-premises, or cloud. These migration maneuvers are all performed at the same time, and therefore, dramatically accelerate the migration timeline as well as remove human error often associated with manual transposition.

Here are the basic steps:

1. VirtaMove is installed onto the new target server, and a connection, known as a “tether,” is made from the destination server to the source server.

2. Rehosting options are presented via the Config-on-the-fly (COTF) setting, which includes the ability to rehost the application using the new NetBIOS name of the destination server or maintain the original NetBIOS name of the source.

3. VirtaMove inventories the source server and presents a list of applications to be migrated. The user selects the applications in-scope for the migration or invokes VirtaMove’s Predictive Application Component Extraction (PACE) to automate this process.

4. VirtaMove creates a container, known as the Virtual Application Appliance (VAA) on the destination server, walks the dependency tree for the selected applications, and pre-copies all known application artifacts into the container. During copy operations, all artifacts are redirected to the appropriate Windows 2012 file path and/or registry hive. Using the VirtaMove Tether Monitor, users can actually see files redirected to places like: WindowsWinSXS and registry keys to HKLMSoftwareWow6432Node in real time.

5. The VAA is docked or mounted to the destination server. At this stage, Windows sees application services, program groups, and application paths.

6. Applications are started and application owners or SMEs run through test cases such as authentication and/or posting a transaction, etc. During this activity, VirtaMove intercepts any application call and copies the required files, folders, and registry strings to the destination VAA.

Once user acceptance testing (UAT) of the application is complete, the VAA is “dissolved” or installed onto the destination operating system, removing any dependency on the VAA or VirtaMove software. The applications are presented to Add/Remove programs on the destination in the same manner as the source machine, which allows for modification, patches, or in-place upgrades to the application as required during its lifecycle.

Now the application has been migrated and rehosted onto the new Windows 2012 destination server with all application artifacts redirected to their appropriate 32-bit file and registry designations. The older Windows 2003 server can be decommissioned.

This completes the original task of migrating a 32-bit custom or bespoke application from Windows 2003 to Windows 2012 without access to the source code, but there are a few more things that can be done with that VAA, if required. Remember it contains the entire application and has gone through UAT, so our ability to repurpose the VAA can lend itself to several other opportunities, such as:

  • Compression of the VAA into a single flat file to ship across long distance / high latency WAN connections or cloud onboarding / application to anywhere.
  • Rapid instantiation of the VAA to any number of destination servers – build out a Web Farm while rehosting the application each time to a new destination server. This allows for scale out of the web tier from a gold master source VAA.
  • Promote across environments – deploy the same VAA to Development, QA, Staging, Production, and DR as required to mitigate configuration drift that can exist in the environments over time.
  • Application level backup – storing the VAA in a repository allows for a point in time application backup. The VAA can be used to deploy the applications on the destination server quickly.

Bottom line: there is a modern way to migrate applications even if the source code is missing. These applications can be migrated quickly and efficiently to on-premise or cloud infrastructure. Once the application is containerized in the VAA, there is increased flexibility to reuse VAAs if required. This same exercise can then be carried out for additional applications running on Windows 2003 servers as a faster and more reliable exit strategy.