From time to time we’re asked whether we can help move legacy workloads to the cloud. Most customers want to move older applications to AWS, Azure, or Google’s GCP platform.

Of course, the answer is Yes. Cloud onboarding of legacy Windows Server applications is a primary use of V-Monitor and V-Migrate.

Other blogs and white papers have addressed how VirtaMove monitors and migrates applications to a cloud OS. This blog focuses on why customers use automation tools to onboard legacy workloads vs. other approaches.

How do customers move legacy workloads to cloud platforms today?

Customers essentially have three options to onboard legacy workloads:

  • Reinstall the legacy applications by hand, move all the data, reconfigure applications, and retest the application on a greenfield Cloud-hosted OS.
  • Use a P2V tool to disk mirror a server or VM, replicating the entire OS and all the applications, data, and clutter to an identical image on the cloud. Then, test and reconfigure applications and the OS as needed.
  • Use intelligent application monitoring and migration tools to dynamically size and reinstall applications on a greenfield, modern cloud OS instance (i.e., use V-Monitor and V-Migrate).

Without repeating the material covered in previous blogs, we’ll briefly outline some of the challenges of using options 1 and 2, and the advantages that come with automated approaches such as option 3.

Option 1 challenges: reinstalling legacy applications by hand on the cloud

Moving legacy application by hand to the cloud involves many steps: reinstalling applications on the new Cloud OS (with or without original install scripts), complex reconfiguration; data migration; testing; and production cut-over.

If install scripts are missing, installation on the cloud (which is likely running a different OS version) can be a near impossible task. Hand migrations can take months of effort to plan, execute, and test. Perhaps that’s why so little legacy workload is moved to cloud providers?

The first challenge is determining which applications to move. The answer might seem obvious: just move all the apps. But that rarely works because applications get installed on servers over an extended period, some are used, some are rarely used, others are never used, some may have never worked, some are replaced by new capabilities of a modern OS. Not all the applications on a server are well behaved and show up neatly on the Add/Remove programs list. Who knows the difference? Rarely IT, and often not the application owner.

The objective is not to move the clutter and chaos of all legacy applications on an old server to the cloud. Rather, it’s to move the applications and workloads that people still need and care about. Even if you know what to move, you also need to know how much compute resources you’ll need to provision on the cloud.

Often, many applications have been installed on a server and distributed across the directory structure in a complex way. Without current documentation, it’s difficult to know exactly which EXEs, DLLs, COM components, user data, drivers, files, and artifacts belong to a specific application and need to move. Making applications run on a cloud via trial and error troubleshooting is painstaking.

Moving applications to the cloud and making them work means reconfiguration. You need to reconfigure IP addresses, network connections, drive mappings, and database connections. You likely need to modify or replace peripheral drivers to support physical hardware. Server names will change, the number and types of network interface controllers (NICs) often change. Application licensing might be tied to a hardware ID and will need to be resolved. User profiles and privileges will need to move. As well, stack components like databases and web servers will likely need to be upgraded.

You need time to test the results of the move and then cut over production to the cloud. Reconfiguration and other rework involved in cloud hand migrations can make it a challenge to sync original production servers during an available maintenance window.

In short, hand onboarding just isn’t easy.

Option 2 challenges: using P2V for Windows Server cloud onboarding

In previous blogs we’ve covered many of the problems inherent in using Physical to Virtual (P2V) and V2V tools to move legacy works and old OS versions to the cloud.

A short list of P2V problems include:

  • Excessive bandwidth is needed to onboard to the cloud because the entire legacy OS, disk clutter, and unnecessary logs and applications are also onboarded.
  • Excessive, ongoing consumption and cost of cloud resources (especially storage and memory).
  • Maintenance of legacy OS instances, which means security exposures, the need for ongoing OS patches, and the inability to use modern cloud management and monitoring tools. Often, older OS versions like WS2003 aren’t supported by cloud vendors, which means that P2V for a legacy OS just isn’t an option.
  • Inability to perform workload consolidation or split workloads, because block replication requires the cloud destination and source server to be near identical.
  • Significant and complex cloud reconfiguration, entailing challenges with cutting over.

P2V cloud onboarding isn’t easy either.

Option 3: why automation can help with onboarding legacy workloads to the cloud

Using automated tools to migrate legacy workloads to the cloud helps solve many of the problems associated with hand and P2V onboarding. Some of the many benefits include the ability to:

  • Move workloads to a modern, standard cloud OS on the vendor of your choice (any cloud can be targeted: AWS, Azure, or GCP), which can be pre-configured, managed, and monitored with advanced cloud orchestration and management tools.
  • Monitor production application usage in advance to discover application dependencies, build migration templates, green light applications for migration, and size the compute resources needed on the cloud
  • Reconfigure applications on-the-fly, change server names, IP address, move users and permissions, so applications run seamlessly on the cloud.
  • Migrate applications to a more modern OS instance to close security exposures and to upgrade stack components such as web servers or databases.
  • Consolidate workload and applications from many source servers to single cloud OS, or split workload on a server to multiple cloud OS instances. Storage and resources on the source server and cloud instance do not need to be identical because disk mirroring is not used.
  • Save significantly on storage and other cloud fees, because the fresh uncluttered install of only required workloads saves bandwidth and processing overheads.
  • Easily move workloads from cloud to cloud or back to in house servers, while avoiding cloud lock-in.
  • Easily test and verify applications in a cloud sandbox before cut-over.

Automated tools really do make cloud onboarding of legacy applications easy.

 

If you need to move legacy Windows Server workloads to the cloud (and you’re not alone if you do) and you’d like to learn more about how VirtaMove can help, give us a call, register for a free demo, or send us an e-mail. We’d love to show you what we’ve done and what we can do for you.