Application Migration Considerations for Hybrid Multiclouds

August 13, 2021 | min

If your organization has a public cloud-first strategy or is considering augmenting on-premises infrastructure with public clouds to create a hybrid multicloud solution, then you are likely trying to establish a simple and efficient application migration plan for your enterprise workloads.

Research carried out by Vanson Bourne for the 2020 Enterprise Cloud Index found that 86% of interviewed customers consider hybrid cloud as their ideal operating model, and they foresee hybrid cloud deployments increasing by more than 37% over the next five years.

1Vanson Bourne Research for the Enterprise Cloud Index, 2020 -

A key reason for this shift in computing models is that hybrid multiclouds provide organizations with choice and the flexibility and simplicity to host applications on the most appropriate infrastructure based on a variety of factors, including location, cost, performance, and resilience, whether on-premises or in a public cloud.

Making The Case for Application Migration

The fast-moving and competitive business world often relies on IT transformation projects to ensure evolving business objectives are met and an efficient, agile technology adoption strategy can reduce risk and cost as well as shorten the time-to-value, (or time-to-cloud in this case), all of which is crucial for success.

Research data from the Bain & Company 2020 CIO Survey shows a 15% to 20% growth in hyperconverged infrastructure (HCI) and hybrid cloud by 2023.

When considering high-impact IT infrastructure projects, application workloads are commonly managed through one or more of the following: rehosting, refactoring, re-architecting and replacing.

Rehosting (a.k.a. Lift-and-Shift and App-Mobility)

Monolithic workloads are typically self-contained, which means their resources (compute and storage) are tightly coupled, typically contained within a virtual machine (VM). This encapsulated architecture enables them to be more easily migrated in their entirety to another platform.

Key requirements of an application rehosting solution should include:

  • Flexibility of source and target platforms
  • Operational simplicity that increases IT administrator efficiencies via automation
  • Minimal workload disruption (outage) with full control over cut-over action

The good, the bad and the ugly

Rehosting provides fast, streamlined and automated migrations direct to cloud for many enterprise and legacy applications, with low project risk and low cost-per-application migration. In addition, as the workload essentially remains the same apart from running on a new platform, it is possible to improve application performance with no changes to existing IT processes, tools, or skill sets.

2Hyperconverged Infrastructure and Hybrid Cloud Are Devouring Market Share, April 2019 -

While there are many advantages to application rehosting, the process is not without its negatives. Everything within a migrated VM container, including OS and app configurations, is carried over as-is during the migration. This means none of the application or OS software versions or configurations are updated as a part of the migration process. If application modernization is the primary project driver, then an alternative process might be a better option.

This workload migration approach was the same process used by countless organizations during the mid-2000s to migrate physical servers into VMs (P2V migrations), and at that time was chosen over other migration paths for the very same highlighted reasons: expediency, cost, and timing.


Where there exists a higher degree of workload and application decoupling, it may be necessary to refactor workloads to take advantage of a cloud. This falls into the category of application modernization, and the degree to which applications will require refactoring may vary considerably depending on the applications and associated configurations.

A common example of when refactoring is used is when the existing application workloads use native (raw) SAN data. Refactoring these to use hyperconverged infrastructure or cloud-native services would be required for the application to function correctly in the cloud.

The downside to refactoring is that multiple strategies might be required based on the underlying reasons. This adds complexity, risk, and time to IT projects. The upside is that once refactored, the application may have access to new cloud-native services and capabilities.

Re-Architecting (including Containerization)

A common key driving factor behind the requirement to re-architect applications is the desire to adopt cloud-native capabilities, migrating away from a legacy monolithic architecture to a scale-out agile one.

Re-architecting an organization’s entire IT application-set can more easily be achieved by younger organizations with less historical IT infrastructure and fewer home-grown applications.

Adopting an agile, devops-orientated architecture can bring significant benefits to the IT organization but can come at increased cost in the short-term due to the requirement for new IT skill sets, tool sets, and procedures. For this reason, some organizations choose to adopt this application model for new applications, only migrating away from legacy applications over time as they become less relevant.


An organization might decide that an entirely new application solution is the desired route, and that as a part of the IT transformation project, a change of more than just the underlying infrastructure is required. This shift can open up new cloud-native solutions including SaaS, which in turn can have different cost-models and feature-sets.

Nutanix Move: Automating the Mundane

It is not uncommon for organizations to employ the use of multiple migration strategies as the most appropriate migration path will often be determined by the specific application type, how application data is managed, source and target infrastructure connectivity, and more.

Databases, for example, are not easily migrated using lift-and-shift methods without incurring a service outage, however, they typically have natively integrated data migration capabilities. Deploying a new database instance on the desired target infrastructure and migrating the data using these native tools may make the most sense, and it can also enable IT teams to update software versions during the same process. It is a similar process for directory services workloads, which natively support data replication and are not suited to lift-and-shift migration.

Lift-and-shift is ideally suited to migrating enterprise application workloads that are monolithic in design rather than ones natively written for a scale-out architecture.

Nutanix Move™ is an application mobility solution designed to manage VM migrations between non-Nutanix and Nutanix infrastructure types. While it can migrate across disparate hardware platforms, hypervisors, and clouds, what does this actually mean to the IT administrator who needs to migrate potentially hundreds or thousands of workloads?

The Move tool has been designed to be compatible with common 3-tier, public cloud, and HCI platforms, include those based on VMware ESXi or Microsoft Hyper-V and native Amazon AWS or Microsoft Azure cloud workloads.

Target infrastructures include Nutanix AHV® or VMware ESXi® hypervisors running on the Nutanix® HCI platform, whether on premises or running in a public cloud on Nutanix Clusters .

The common steps required for Nutanix Move migrations include:

  1. Connect source and target environments to Move appliance VM
  2. Define a migration plan
    1. Select VMs to migrate
    2. Specific source VM account credentials
    3. Map source > target networks
    4. Define a migration schedule
  3. Initiate data seeding
  4. Test VM cutover 5. Cutover

3Nutanix Clusters-on-AWS enables customer-managed Nutanix nodes in the public cloud. Learn more:

Migrations can be carried out one or more at a time, allowing IT administrators to batch VMs by application, service, or even department. This can be particularly helpful streamlining the migration of groups of VMs that make up multi-tiered applications or business units.

When data seeding is underway, source VM data is replicated to the target at defined interval periods. By keeping the target VM periodically up-to-date with the source, the fastest cutover time is assured.

A test cutover feature enables IT administrators to cutover one or more VMs to an isolated test network. The VM(s) are brought up live in the target environment but on the isolated network, therefore not impacting the live production VMs in the source environment. Once tested, VMs are shutdown and discarded automatically and the data seeding from the source resumes again.


The cutover process starts when initiated by an administrator, which can be on one or more migrations. The source VM is quiesced and a final replication of data is taken before shutting it down and bringing up the target VM. The process can be very short, as little as a minute or so depending on how long the source VM takes to shutdown and resulting in a near-zero service outage.

In the three years since Nutanix launched the Move migration tool, Move’s launch, approximately 200,000 VMs have been successfully migrated by Nutanix customers. Move continues to help customers solve their migration requirements, which saw a ~15% growth in migrations between Q4-2020 and Q1-2021.

Take the Next Step...

Nutanix Move is freely available to Nutanix customers and can be used to migrate from any supported source environment (three-tier on VMware ESXi or Microsoft Hyper-V, vSAN, AWS-native, or Azure-native) to a Nutanix on-premises or direct to public cloud instance (Nutanix Clusters on AWS).

If you’ve not yet experienced HCI or the flexibility and simplicity of Nutanix hybrid clouds based on that same industry-leading HCI technology, see how Nutanix Move provides the power to leverage them with seamless app migrations.

Accelerate your cloud migration strategy today with a test drive of Nutanix Clusters.

Resources for further reading...

© 2021 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and all Nutanix product, feature and service names mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. Other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s). This post may contain links to external websites that are not part of Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such a site. Certain information contained in this post may relate to or be based on studies, publications, surveys and other data obtained from third-party sources and our own internal estimates and research. While we believe these third-party studies, publications, surveys and other data are reliable as of the date of this post, they have not independently verified, and we make no representation as to the adequacy, fairness, accuracy, or completeness of any information obtained from third-party sources.

This post may contain express and implied forward-looking statements, which are not historical facts and are instead based on our current expectations, estimates and beliefs. The accuracy of such statements involves risks and uncertainties and depends upon future events, including those that may be beyond our control, and actual results may differ materially and adversely from those anticipated or implied by such statements. Any forward-looking statements included herein speak only as of the date hereof and, except as required by law, we assume no obligation to update or otherwise revise any of such forward-looking statements to reflect subsequent events or circumstance.