Our recent blog, Cloud Migration: What is Lift and Shift focused on the basics of Lift and Shift – what it is, when to use it, and the benefits and drawbacks of this cloud migration technique. Now, we will get into the details of how you can implement a lift and shift migration for your organization.
A lift and shift migration typically involves several key stages: assessment, planning, migration, and optimization.
The Assessment Phase
The assessment phase involves evaluating which applications and workloads are viable candidates for a lift and shift move. Not every application is suitable - some may have dependencies or requirements that are difficult to replicate in the cloud. Compatibility is a key consideration. For example, a .NET application running on Windows Server 2012 R2 should be able to run on an Azure VM with the same OS.
However, an application that requires specific hardware or network configurations may face compatibility issues. Consider an application that relies on a specific USB hardware key for licensing. Replicating this in Azure could be challenging and may require changes to the application, making it a poor candidate for lift and shift. Performance requirements, security and compliance regulations, and licensing are additional factors to assess. Applications with strict latency requirements or that handle sensitive regulated data may not be ideal for lift and shift.
The Planning Stage
Once suitable applications are identified, the next stage is planning the actual migration. This involves tasks like:
- Mapping the on-premises environment and dependencies
- Selecting the appropriate Azure VM sizes and storage options
- Designing the Azure virtual network
- Developing a step-by-step migration plan and timeline
- Preparing the Azure environment
For instance, when migrating a SQL Server database to Azure SQL Database, planning tasks would include sizing the Azure SQL DB instance, designing the data migration process, and determining the cutover strategy. Here's an example Azure CLI script for provisioning an Azure SQL Database:
```bash
# Create a resource group
az group create --name myResourceGroup --location eastus
# Create a server
az sql server create --name myserver --resource-group myResourceGroup --location eastus --admin-user myadmin --admin-password xxxxxxxx
# Configure a server firewall rule
az sql server firewall-rule create --resource-group myResourceGroup --server myserver -n AllowYourIp --start-ip-address 192.168.0.1 --end-ip-address 192.168.0.1
# Create a database
az sql db create --resource-group myResourceGroup --server myserver --name mydatabase --service-objective S0
```
Thorough planning is critical to reduce risk and ensure a smooth transition to Azure.
The Migration Phase
With the planning complete, the actual migration process can begin. This involves transferring all the application components - code, configurations, libraries, and associated data - to Azure. For a typical lift and shift, Azure Site Recovery can be used to replicate on-premises VMs to Azure VMs. Here's an example of how to enable replication for a VMware VM using Azure PowerShell:
```powershell
# Set the vault context
Set-AzRecoveryServicesAsrVaultContext -Vault $vault
# Get the protection container
$protectionContainer = Get-AzRecoveryServicesAsrProtectionContainer -Fabric $fabric -Name "myProtectionContainer"
# Get the replicatable items
$replicateableItems = Get-AzRecoveryServicesAsrReplicationProtectedItem -ProtectionContainer $protectionContainer
# Start replication
$jobResult = New-AzRecoveryServicesAsrReplicationProtectedItem -VMwareToAzure -ProtectableItem $replicateableItems[0] -Name "myVM" -RecoveryVMName "myVM" -RecoveryResourceGroupId $targetResourceGroup.ResourceId
# Track job status to completion
while (($jobResult.State -eq "InProgress") -or ($jobResult.State -eq "NotStarted")){
sleep 10;
$jobResult = Get-AzRecoveryServicesAsrJob -Job $jobResult
}
$jobResult.State
```
The Optimization Phase
After the application is moved, extensive testing is necessary to validate that it functions as expected in Azure. This includes verifying integrations, performance under load, security controls, and end-to-end business processes. Any issues uncovered during testing must be resolved before the application goes live in Azure.
Following the move to Azure, there are often opportunities for optimization. This could involve tweaking configurations, right-sizing Azure resources, or integrating some Azure PaaS services.
For example, after lifting and shifting a web application to Azure VMs, a company might rightsize the VM instances based on actual CPU and memory usage. They could also introduce Azure Autoscale to dynamically adjust the number of VM instances based on traffic. Here's an example of setting up autoscale for a VM scale set using Azure CLI:
```bash
# Create a scale set
az vmss create \
--resource-group myResourceGroup \
--name myScaleSet \
--image UbuntuLTS \
--upgrade-policy-mode automatic \
--admin-username azureuser \
--generate-ssh-keys
# Define an autoscale profile
az monitor autoscale create \
--resource-group myResourceGroup \
--resource myScaleSet \
--resource-type Microsoft.Compute/virtualMachineScaleSets \
--name autoscale \
--min-count 2 \
--max-count 10 \
--count 2
```
Further, they might offload static content to Azure Blob Storage and deliver it via Azure CDN for improved performance and reduced hosting costs.
While the lift-and-shift approach moves applications "as-is," some modifications are usually necessary for the applications to run optimally in Azure. Over time, there may be potential for further refactoring or re-architecting to leverage additional Azure capabilities.
Lift and Shift Techniques
Executing a successful lift and shift migration involves several key techniques:
Server replication
Using server replication tools to create an exact copy of an on-premises server in the cloud. This could involve creating a VM image of the on-premises server and using it to spin up a cloud VM with the same configuration.
Example:
```
# Create a VM image
sudo dd if=/dev/sda of=server_image.img
# Upload the image to the cloud
cloud_provider upload server_image.img
# Create a VM from the image
cloud_provider create_vm --image server_image.img --instance_type large
```
Database migration
Migrating databases to the cloud using database backup and restore techniques or database migration services provided by the cloud vendor.
Example:
```sql
-- Take a backup of the on-premises database
BACKUP DATABASE mydb TO DISK = 'mydb.bak';
-- Restore the backup in the cloud
RESTORE DATABASE mydb FROM DISK = 'mydb.bak';
```
Network migration
Configuring cloud networks to mirror or extend on-premises networks. This could involve setting up a VPN connection between the on-premises network and the cloud network or configuring cloud network settings to match on-premises.
Example:
```
# Create a virtual network
cloud_provider create_network --cidr 10.0.0.0/16
# Create a VPN gateway
cloud_provider create_vpn_gateway --network my_network
# Configure on-premises VPN device to connect to cloud VPN
on_premises_vpn_device config --peer cloud_vpn_gateway
```
Storage migration
Moving application data to cloud storage services. This could involve syncing files to cloud storage, migrating blob data, or setting up file shares in the cloud.
Example:
```
# Sync files to cloud storage
cloud_provider sync /path/to/files storage://my_bucket/files
# Migrate blob data
for blob in $(on_premises_blob_store list); do
on_premises_blob_store get $blob | cloud_provider storage put mycontainer/$blob
done
```
Testing and validation
Verifying that the migrated application functions as expected in the cloud. This involves thorough testing of application functionality, performance, integrations, and security.
Example:
```
# Perform a load test
load_test --url http://migrated-app.cloud --users 1000 --duration 1h
# Validate application output
actual_output=$(curl http://migrated-app.cloud/api/test)
expected_output="Hello, World!"
if [[ "$actual_output" != "$expected_output" ]]; then
echo "Validation failed: expected '$expected_output', got '$actual_output'"
exit 1
fi
```
Cutover strategies
Techniques for directing user traffic from the on-premises application to the cloud application. This could involve updating DNS records, configuring load balancers, or using a traffic management service.
Example:
```
# Update DNS to point to cloud application
dns_provider update_record --name myapp --type A --value cloud_app_ip
# Configure load balancer
cloud_provider create_load_balancer --name myapp_lb --vms vm1,vm2,vm3
```
Rollback planning
Preparing a plan to revert back to the on-premises application if issues are encountered during the migration. This might involve keeping the on-premises application running in read-only mode during the migration or having a process to sync data back from the cloud to on-premises.
Example:
```
# Sync data back from cloud to on-premises
cloud_provider storage get mycontainer/data | on_premises_data_store write data
# Repoint DNS to on-premises application
dns_provider update_record --name myapp --type A --value on_premises_app_ip
```
You May Also Like: What is the Microsoft Cloud Adoption Framework and Why is it Important?
Conclusion
These are just some examples of the techniques involved in a lift and shift migration. The specific tools and commands will vary based on the source environment, target cloud platform, and application architecture. The key is to have a well-planned and tested process for each stage of the migration. If you need help with your lift and shift cloud migration, please contact our team at Emergent Software and we will be happy to help!
Frequently Asked Questions
What is lift and shift in AWS? Lift and shift in AWS involves migrating applications and workloads from an on-premises environment to AWS without making any changes to the applications themselves. This approach typically uses AWS services like Amazon EC2 for compute, Amazon S3 for storage, and AWS Direct Connect or VPN for networking.
What is the opposite of lift and shift? The opposite of lift and shift is a full re-architecture or refactoring of applications. This involves redesigning and rewriting applications to take full advantage of cloud-native features and services, often resulting in significant changes to the application's architecture.
What is the difference between lift and shift and SaaS? Lift and shift involves moving existing applications to the cloud with minimal changes, essentially replicating the on-premises environment in the cloud. SaaS (Software as a Service) involves using third-party cloud-based applications that are fully managed by the provider, eliminating the need for managing infrastructure or application maintenance.
What are the benefits of the lift and shift approach? The lift and shift approach offers several benefits, including:
- Speed: Quickly move applications to the cloud without extensive modifications.
- Cost Savings: Reduce costs associated with maintaining on-premises hardware and infrastructure.
- Scalability: Leverage cloud resources to scale applications up or down based on demand.
- Disaster Recovery: Utilize cloud-based backup and recovery options to enhance disaster recovery capabilities.
What is lift and shift? Lift and shift, also known as rehosting, is a cloud migration strategy where applications and workloads are moved from an on-premises environment to the cloud with little to no modification. This approach aims to replicate the existing environment in the cloud, preserving the application's architecture and functionality.
What is lift and shift vs refactor? Lift and shift, or rehosting, involves moving applications to the cloud with minimal changes, replicating the on-premises setup. Refactoring, on the other hand, involves modifying and optimizing the application to leverage cloud-native features and services, which may include redesigning the application's architecture for better performance, scalability, and cost-efficiency.
