Compare on-premises migration to cloud server migration

Server-to-server migration overview

Server-to-server migrations can be physical to physical (P2P), where a traditional non-virtualized -- or bare metal -- application is moved to another non-virtualized server. This amounts to a reinstallation of the application on the target server. Tools such as PlateSpin Migrate can reduce the time it takes to execute these migrations. If local data accompanies the workload, the data files can be copied to the target server, and the migrated application can be configured to find any migrated data.

Physical-to-virtual (P2V) migrations involve similar considerations. The bare metal application can be reinstalled on a VM and provisioned in advance. PlateSpin Migrate and other tools, such as VMware Converter, can also support faster P2V migrations.

P2P and P2V migrations impose some downtime to execute the move and any workload reconfiguration on the target server, so plan accordingly.

A closer look at local V2V migration

Virtual-to-virtual (V2V) migrations are the most common means of on-premises -- and cloud -- workload migration. Hypervisors, such as Hyper-V and vSphere, readily support live migrations. These tools automatically move a working VM from a source server to a target server without the need to quiesce or stop the VM during the move. The result is little to no downtime.

A data migration is largely a matter of copying files from one server to another. This can be accomplished before or during the live migration. However, it takes substantial time to move large data sets, even across a LAN, so some workload quiesce time may still be required.

Let's look at the overall process for a typical local V2V migration.

Planning. Be clear about the reason for your migration from the outset. Perhaps you're facing a tactical troubleshooting issue, where a server fault causes a VM problem, and you must move the VM to another server so you can fix the underlying hardware issue.

You might also have strategic reasons for a migration. For example, you want to retire an aging server and move its VMs to a new server. Or you might want to improve performance, so you move VMs around to better distribute the overall computing workload across multiple target systems.

Preparation. Identify the VMs and data sets that you have to move and record each VM's configuration. Then select the appropriate target server for the migration. There are tools available in modern virtualization platforms that streamline and automate this preparatory work, but it's still important to recognize the steps that are taking place in the background.

Execution. Modern tools make short work of the actual migration process. With Hyper-V Manager, for example, administrators select and connect to a source server, select the VMs to move, and then use the Move Wizard to select the type of move, the destination server and more. When the administrator has finished with the Move Wizard, the migration is executed automatically.

Although live migrations are intended to impose little downtime, it's still best to execute them during periods of light application use. This way, any problems with the migration will impact the fewest number of users. If you need to quiesce the application for any reason, downtime should be planned.

Testing. When the V2V migration is complete, validate the application to be sure it functions as expected. Migrations of mission-critical workloads should include recovery strategies so you can revert the migration if serious problems occur.

If the original workload employed monitoring tools, update those tools to follow the migrated VM. Otherwise, application monitoring could cease and leave organizations without vital performance metrics.

Follow up. Ultimately, the source server can be repaired, upgraded, repurposed or retired as needed.

Local-server-to-public-cloud migration overview

The cloud has become a common companion to the local data center, since most organizations want to move at least some workloads to the cloud. A migration from a local data center to a public cloud follows the same fundamental process as a local P2V or V2V migration, but migrations to the cloud require at least two additional considerations.

First, you typically move the data, in addition to the applications. This also happens in local server migrations if the associated data is on the same server as the application, but shared storage implementations make local data migrations a rarity.

When you move a VM to the cloud, it can still use data that's on a local server or storage subsystem. However, accessing local data from the cloud can be problematic due to potential internet congestion and disruption. There are also substantial egress fees if data is frequently transferred back to your local data center. Workload performance typically improves if the data and the application are in the same place.

Second, infrastructure monitoring and analytics, while helpful on premises, are essential for cloud workloads and data. They're the only practical way to understand resource utilization, costs and performance. Services such as Amazon CloudWatch or Azure Monitor gather metrics to monitor application performance and health while reporting on cloud resource utilization. Any move from on premises to the cloud should factor in how these types of services will be utilized.

To better understand cloud V2V migrations, here's a rundown of the overall process:

Planning. Cloud environments have vastly different infrastructure than local data centers, so cloud migrations are not implemented as tactical responses to existing conditions. Instead, they are often seen as a strategic way to limit local infrastructure investment and maintenance.

For example, the highly scalable, on-demand nature of the cloud is preferable for workloads with highly variable or unpredictable traffic or resource demands. Similarly, copying a workload and data to a cloud region far from your local data center can bring the workload closer to users without having to build a dedicated data center in that area.

Preparation. A cloud migration takes more thought and preparation than just picking a target server. Public clouds provide a large array of target server instance types, storage services, load balancers, scaling services and so on. An IT team must build the infrastructure from a cloud's available virtual resources so the workload has an actual destination.

Ideally, this preparation is as simple as provisioning a suitable compute and storage instance. Indeed, this might be all that's needed for some basic tasks. However, to migrate a production workload, you might need to configure numerous compute and storage instances, scaling services, load balancing services, database services and more. Preparing for a complex cloud migration may require the talents of a cloud architect.

Execution. Cloud migrations are rarely a single-step process. The data is typically migrated only after you've provisioned suitable resources or a complete cloud infrastructure. Data sets can be massive, easily measuring into the terabytes or even petabytes. These are far too big to move over a traditional internet connection in a timely manner. Instead, use a dedicated connection or ship the data on physical devices through services such as AWS Snowball or Google's Transfer Appliance.

After the data is moved, it must be kept in-sync with local data, since the local workload is still running and data is changing. Services such as AWS DataSync and Azure File Sync can help to handle large moves and maintain data synchronization.

Once the data is ready, it's time to execute the actual server moves and migrate local VMs to the compute VMs, or instances, provisioned in the cloud. Administrators can readily copy and run local VM files to cloud compute instances, but such manual efforts are suited for just a few migrations. Cloud providers readily offer tools, such as Google's Migrate for Compute Engine and Azure Migrate, designed to manage a huge number of migrations to the cloud.

Testing. When the migration is complete, you can restart the workloads, data and supporting services. Leave the local workload and data in place and maintain data synchronization until the cloud deployment has been thoroughly validated. In many cases, administrators will inform users of the impending migration, notify them when the migration is completed, and ask them to report any feedback or issues for remediation.

Follow up. This discussion assumes that the source servers will be repurposed or decommissioned once the cloud migration is fully validated. However, some cloud migration projects may leave the local server and data set running in tandem with the cloud workload and data set. The objective here is usually scale and resiliency.

The goals of on-premises and cloud server migrations are basically identical -- take a workload running in one place and make it run in another place. While the intention is straightforward, the driving factors can diverge.

Server migrations are often more tactical or occur as needed to address an issue. Cloud migrations are usually more strategic to offer long-term solutions to business problems. Both migration types can coexist, enabling businesses to continue local migrations while using migration processes to help with public cloud adoption for suitable applications.