Lacking Source Code From Legacy Applications

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. Key challenges are a lack of knowledge about the application, missing or outdated documentation, or worse, no source code or installation media.

The absence of source code means an inability to recompile the application onto newer architecture. This is a significant barrier that prevents migrating applications from an unsupported Windows OS (2003/2008) and soon Windows 2012 to supported Windows OS, or from 32-bit to 64-bit. 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.

As a Windows Server OS approaches its end of extended support enterprise customers are left scratching their heads on how to remediate or get off. Even if the plan for some of these more complex applications is to stay put on an unsupported Windows OS and pay Microsoft for both Premium Support and a Custom Support Agreement (CSA), the enterprise must still submit a Windows exit strategy to Microsoft to qualify for buying 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?

Why Lack of Installers or Source Code Isn’t A Barrier To Migrating Legacy Applications


The VirtaMove container bypasses the typical installation processing by doing a “stateful” migration. A stateful migration doesn’t recompile the application, as a result, the source code, installers, and other installation media aren’t needed.

We don’t need to recompile the applications because they are already natively supported on 64-bit architectures by leveraging “Windows 32-bit on Windows 64-bit”, commonly referred to as WOW64. Many frameworks such as ASP.NET, Java, Cold Fusion, or PHP will run on a supported Windows OS using WOW64. Unlike its 32-bit predecessor (WOW), WOW64 provides backward compatibility with 32-bit applications.

How VirtaMove Installs Legacy Applications Without Source Code or Installers

The purpose of an up-level, container-based migration tool such as VirtaMove is to automate the process of migrating legacy applications from the source server with an unsupported Windows OS to a destination server with a supported Windows OS. 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 for migrating applications using VirtaMove’s Migration Software.


  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 OS 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.
  7. Once the application’s user acceptance testing (UAT) 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 supported Windows OS destination server with all application artifacts redirected to their appropriate 32-bit file and registry designations. The older unsupported Windows OS server can be decommissioned. This completes the original task of migrating without source code a 32-bit custom or bespoke application from a server with an unsupported Windows OS to a server with a supported Windows OS.

If you’d like to learn more about how VirtaMove can help you migrate and modernize apps, let you exploit your existing app code, and close security exposures on old unsupported operating systems, please contact us. We’d be pleased to have an introductory meeting or demo to show you the VirtaMove solution.