This chapter covers two fundamental cloud migration strategies: lift-and-shift (rehost) and refactor (rearchitect). Understanding these approaches is critical for the AZ-900 exam, as they represent core decisions in cloud adoption. This topic falls under Domain 1: Cloud Concepts, which makes up 25-30% of the exam. We'll explore what each strategy entails, when to use them, and how they affect cost, performance, and operational overhead.
Jump to a section
Imagine you run a factory that produces widgets using a complex assembly line of old, specialized machines. The factory is in a building you own, and you're considering moving to a new, modern facility. You have two main options: lift-and-shift or refactor.
Lift-and-shift is like packing up every single machine exactly as it is—bolts, belts, and all—and moving them to the new factory floor. You don't change how the machines work, you don't upgrade them, you just relocate them. The advantage is speed: you can be back up and running in days, because you didn't redesign anything. But you're still stuck with the same old machines, the same inefficiencies, and the same maintenance headaches. In Azure, this means taking your on-premises virtual machines and applications and moving them to Azure IaaS without modifications. You get the cloud's infrastructure benefits (elasticity, pay-as-you-go) but your apps don't leverage cloud-native features like auto-scaling or managed databases.
Refactor is different. Instead of moving the old machines, you redesign the assembly line. You throw out the clunky steam-powered press and replace it with a modern, electric one that's faster and uses less energy. You automate the conveyor belts with sensors. The move takes longer because you're rebuilding, but the new factory is more efficient, easier to maintain, and can scale production up or down quickly. In Azure, refactoring means modifying your application code or architecture to use PaaS services like Azure App Service, Azure SQL Database, or Azure Functions. This gives you better performance, lower operational overhead, and automatic scaling. The trade-off is higher upfront effort and cost for the redesign.
The mechanism is about where you invest effort: lift-and-shift invests in migration speed, refactor invests in long-term cloud optimization. Both are valid migration strategies, but the choice depends on your business priorities—time-to-cloud vs. cost and efficiency over the long run.
What Are Lift-and-Shift and Refactor?
Cloud migration is the process of moving digital assets—applications, data, servers, and other IT resources—from on-premises data centers to the cloud. Two common strategies are lift-and-shift (also called rehost) and refactor (also called rearchitect). These are part of the broader 6 R's of cloud migration: Rehost, Refactor, Rearchitect, Rebuild, Replace, and Retire. For AZ-900, you need to understand the differences and trade-offs.
Lift-and-Shift (Rehost) involves moving an application from an on-premises environment to the cloud with minimal or no changes. You take your existing virtual machines, their operating systems, and applications, and run them on Azure Virtual Machines (IaaS). The application code, configuration, and data remain largely the same. The goal is to migrate quickly to start benefiting from cloud infrastructure (e.g., no more hardware maintenance, elastic compute capacity, pay-as-you-go pricing) without investing time in redesigning the application.
Refactor (Rearchitect) involves modifying the application to take advantage of cloud-native features. This could mean breaking a monolithic application into microservices, using a managed database like Azure SQL Database instead of running SQL Server on a VM, or using serverless compute like Azure Functions. The goal is to improve agility, scalability, and cost efficiency by leveraging PaaS or serverless services. This approach requires more upfront effort but often reduces operational overhead and costs over time.
How They Work: Step-by-Step Mechanism
Lift-and-Shift Mechanism: 1. Assessment: You inventory your on-premises servers, including their configurations, dependencies, and performance metrics. Tools like Azure Migrate can help. 2. Replication: You replicate the on-premises VMs to Azure using Azure Site Recovery or Azure Migrate. This creates copies of the VMs in Azure while the original ones continue running. 3. Migration: You fail over to the Azure VMs. The on-premises VMs are decommissioned after validation. 4. Operation: You manage the Azure VMs like you would on-premises—patching, backups, monitoring. You might add some cloud features like Azure Backup or Azure Monitor, but the app itself is unchanged.
Refactor Mechanism: 1. Assessment: Similar to lift-and-shift, but you also analyze the application architecture to identify components that can be modernized. 2. Design: You redesign the application to use cloud-native services. For example, you might replace a custom authentication module with Azure Active Directory, or move a database to Azure Cosmos DB. 3. Development: You modify the code to integrate with the new services. This may involve rewriting parts of the application. 4. Migration: You deploy the new version to Azure, often using a blue-green deployment strategy to minimize downtime. 5. Operation: You benefit from managed services—automatic patching, built-in scaling, high availability—reducing operational burden.
Key Components and Considerations
Lift-and-Shift: - Azure Virtual Machines: The primary compute resource. You choose VM sizes, storage, and networking similar to on-premises. - Azure Migrate: Service that helps discover, assess, and migrate on-premises VMs. - Azure Site Recovery: Orchestrates replication and failover. - Cost Model: You pay for VMs (compute + storage) even when idle. Reserved Instances can reduce costs. - Pros: Fast migration, low risk, no code changes, immediate cloud benefits (elasticity, no hardware maintenance). - Cons: Misses cloud optimization opportunities, may be more expensive in the long run if not rightsized, still requires OS patching and maintenance.
Refactor: - Azure App Service: For web apps, APIs, mobile backends. Provides auto-scaling, built-in load balancing, and security. - Azure SQL Database: Managed relational database with built-in high availability and backups. - Azure Functions: Serverless compute for event-driven workloads. - Azure Kubernetes Service (AKS): For containerized microservices. - Cost Model: Pay only for resources consumed (e.g., per-second billing for Functions, DTU or vCore for SQL Database). Often cheaper for variable workloads. - Pros: Better scalability, lower operational overhead, improved performance, easier to update. - Cons: Higher initial cost and effort, requires development skills, longer migration timeline.
Comparison to On-Premises
On-premises, you own and manage everything: hardware, OS, middleware, application, data. With lift-and-shift, you move the same stack to Azure IaaS, so you still manage the OS and application, but Azure manages the hypervisor, host hardware, and physical network. With refactor, you offload more management to Azure: with PaaS, Azure manages the OS, runtime, and middleware; you only manage the application and data. This reduces operational overhead but gives you less control.
Azure Portal and CLI Touchpoints
Lift-and-Shift via Azure Migrate: - In the Azure portal, go to Azure Migrate > Servers, databases and web apps > Create project. - Use the Azure CLI to start replication:
az site-recovery vault create --name myVault --resource-group myRG --location eastus
az site-recovery fabric create --vault-name myVault --resource-group myRG --name myFabricRefactor via App Service: - In the portal, create an App Service plan and web app. Choose runtime stack (e.g., .NET, Node.js). - Use CLI to create and deploy:
az appservice plan create --name myPlan --resource-group myRG --sku B1 --is-linux
az webapp create --resource-group myRG --plan myPlan --name myApp --runtime "DOTNETCORE|6.0"
az webapp deployment source config-zip --resource-group myRG --name myApp --src myapp.zipBusiness Scenarios
Scenario 1: Rapid Data Center Exit. A company's data center lease is expiring in 6 months. They have hundreds of legacy VMs running critical but stable applications. Lift-and-shift allows them to move everything to Azure quickly, avoiding the cost of a new lease. They use Azure Migrate to migrate VMs in bulk. After migration, they may gradually refactor some apps.
Scenario 2: Startup Scalability. A startup has a monolithic e-commerce app on a single VM. Traffic spikes unpredictably. They refactor the app into microservices using AKS and Azure Functions. This enables auto-scaling, and they only pay for what they use. The initial effort is higher, but they avoid over-provisioning and can release features faster.
Common Mistakes
Lift-and-shift without rightsizing: Moving VMs with the same size as on-premises often leads to over-provisioning and higher costs. Always assess actual usage and downsize.
Refactoring everything: Not all apps benefit from refactoring. Legacy apps with no need to scale may be fine with lift-and-shift. Over-engineering can waste time and money.
Ignoring dependencies: Both strategies require understanding application dependencies. Missing a dependency can break the migration.
Exam Relevance
AZ-900 tests your ability to distinguish between migration strategies. You'll see scenarios describing business requirements (e.g., "minimal changes," "improve scalability") and you must select the appropriate strategy. Know that lift-and-shift is fastest but doesn't optimize for cloud, while refactor is slower but yields better long-term benefits. Also understand that "rehost" is a synonym for lift-and-shift, and "rearchitect" is a synonym for refactor.
Assess Current Environment
Begin by inventorying all on-premises servers, applications, and dependencies. Use Azure Migrate to discover servers, assess readiness, and get cost estimates. For lift-and-shift, you need to know VM sizes, storage, and network config. For refactor, you also need application architecture, code dependencies, and data models. This step is critical to avoid surprises during migration.
Choose Migration Strategy
Based on assessment, decide which apps to lift-and-shift and which to refactor. Criteria include: time constraints, budget for refactoring, need for scalability, and operational overhead tolerance. Document the strategy for each workload. For lift-and-shift, you'll plan replication; for refactor, you'll design new architecture using PaaS services.
Set Up Azure Target Environment
Create the Azure infrastructure. For lift-and-shift, provision a virtual network, subnets, and storage accounts. For refactor, create App Service plans, SQL databases, or AKS clusters. Use Azure Resource Manager templates or CLI for repeatability. Ensure networking (VPN or ExpressRoute) is configured for connectivity during migration.
Execute Migration
For lift-and-shift, use Azure Migrate or Azure Site Recovery to replicate VMs. Perform a test failover to validate. Then cut over by stopping on-premises VMs and starting Azure VMs. For refactor, deploy the modified application code to the new PaaS services. Use blue-green deployment to minimize downtime. Monitor for errors and roll back if needed.
Optimize and Manage Post-Migration
After migration, rightsize resources: for lift-and-shift, resize VMs based on actual usage; for refactor, adjust scaling rules and performance tiers. Implement monitoring with Azure Monitor. Set up backups and disaster recovery. Continuously evaluate if further refactoring is beneficial. For lift-and-shift, plan for eventual modernization to reduce costs and improve agility.
Scenario 1: Enterprise Data Center Migration
A large insurance company has a data center lease expiring in 9 months. They have 500 VMs running legacy .NET applications and SQL Server databases. The business priority is to exit the data center without any application downtime. The team chooses lift-and-shift for all VMs. They use Azure Migrate to assess dependencies and then replicate VMs to Azure using Azure Site Recovery. During the cutover weekend, they fail over 50 VMs at a time. After migration, they notice that many VMs are oversized (e.g., 16 vCPUs but average CPU usage is 10%). They rightsize them, reducing monthly costs by 30%. However, they still manage OS patching and backup manually. Over the next year, they plan to refactor some apps to use Azure SQL Database and App Service to reduce operational overhead.
Scenario 2: E-commerce Platform Scaling
A mid-size e-commerce company experiences traffic spikes during sales events. Their monolithic application runs on a single VM and often crashes under load. They decide to refactor the application into microservices. They break the monolith into separate services: product catalog, user authentication, order processing, and payment. They deploy each service as an Azure App Service web app, use Azure SQL Database for the catalog, and Azure Functions for order processing. They also use Azure Redis Cache for session state. The migration takes 6 months, but after deployment, the platform auto-scales during Black Friday, handling 10x traffic without issue. Operational costs drop because they no longer pay for idle VM capacity, and the development team can deploy updates independently.
Scenario 3: Healthcare Compliance
A healthcare provider needs to move a patient records system to the cloud but must comply with HIPAA. The application is a custom .NET app with a SQL Server database. They initially consider lift-and-shift to minimize changes, but the compliance team requires encryption at rest and in transit, audit logging, and automated backups. Refactoring allows them to use Azure SQL Database with built-in encryption, auditing, and geo-redundant backups. They also use Azure App Service with managed certificates. The refactoring effort is significant, but it ensures compliance without building custom security features. A common mistake would be to lift-and-shift and then try to bolt on security, which could lead to gaps and audit failures.
What AZ-900 Tests on This Objective
This topic falls under Domain 1: Cloud Concepts, objective 1.1 Describe the benefits and considerations of using cloud services. Specifically, the exam expects you to understand the differences between migration strategies like lift-and-shift (rehost) and refactor (rearchitect). You'll be given a scenario and asked which strategy best meets the business requirements.
Common Wrong Answers and Why Candidates Choose Them
"Lift-and-shift always costs less" – Candidates think moving without changes is cheaper. Reality: Lift-and-shift can be more expensive long-term if you don't rightsize, because you pay for idle resources. Refactor often reduces ongoing costs.
"Refactor means no code changes" – Some confuse refactor with lift-and-shift. Refactor requires code modifications to use PaaS services.
"Lift-and-shift provides better scalability" – While Azure VMs can scale, they don't auto-scale as seamlessly as PaaS services. Refactored apps using App Service or Functions scale automatically.
"You can only choose one strategy for the whole company" – Exam scenarios often test that you can mix strategies per workload.
Specific Terms and Values on the Exam
Rehost = lift-and-shift. Rearchitect = refactor. These exact terms appear.
Azure Migrate is the tool for lift-and-shift.
Azure App Service, Azure SQL Database, Azure Functions are common refactor targets.
"Minimal changes" points to lift-and-shift. "Improve scalability" or "reduce operational overhead" points to refactor.
Edge Cases and Tricky Distinctions
Replatform (Lift and Optimize): Sometimes considered a middle ground where you make minor cloud optimizations (e.g., moving to a managed database) without changing code. AZ-900 may not test this deeply, but be aware it exists.
Retire: If an app is no longer needed, the best strategy is to retire it, not migrate.
Replace (SaaS): Using a SaaS solution like Office 365 instead of migrating an on-premises app. This is another option not covered in lift-and-shift vs refactor.
Memory Trick
Use the "Speed vs. Optimization" decision tree: - Speed needed? → Lift-and-shift (fast, no changes) - Long-term optimization? → Refactor (slow, code changes) - Both? → Lift-and-shift first, then refactor later.
Another trick: "Lift = Leave as is; Refactor = Rework for cloud."
Lift-and-shift (rehost) moves applications to Azure VMs with no code changes, prioritizing speed.
Refactor (rearchitect) modifies applications to use PaaS services, improving scalability and reducing overhead.
Azure Migrate is the primary tool for lift-and-shift migrations.
Refactoring targets include Azure App Service, Azure SQL Database, and Azure Functions.
Lift-and-shift can lead to higher costs if VMs are not rightsized post-migration.
The choice between strategies depends on business goals: speed vs. long-term optimization.
Both strategies can be used together for different workloads within the same organization.
These come up on the exam all the time. Here's how to tell them apart.
Lift-and-Shift (Rehost)
No code changes required
Fast migration (weeks to months)
Uses IaaS (Azure VMs)
Higher operational overhead (OS patching, backups)
May be more expensive long-term if oversized
Refactor (Rearchitect)
Code changes required
Slower migration (months to a year)
Uses PaaS (App Service, SQL Database, Functions)
Lower operational overhead (managed services)
Often reduces long-term costs through elasticity
Mistake
Lift-and-shift means you don't need to change anything in Azure.
Correct
While you don't change the application code, you may need to adjust networking, storage, and VM sizes. Also, you must manage the OS and middleware, which is different from on-premises management.
Mistake
Refactoring always reduces costs immediately.
Correct
Refactoring often increases upfront development costs. Cost savings from reduced operational overhead come after migration and may take months to realize.
Mistake
Lift-and-shift is only for legacy apps that can't be changed.
Correct
Lift-and-shift can be used for any app where speed of migration is prioritized. Even modern apps may be lifted first and refactored later.
Mistake
Refactoring requires rewriting the entire application from scratch.
Correct
Refactoring can be incremental. You might change only the data layer (e.g., move to Azure SQL Database) while keeping the frontend code largely the same.
Mistake
You cannot use lift-and-shift for compliance-sensitive workloads.
Correct
You can use lift-and-shift, but you must configure Azure services (e.g., encryption, network isolation) to meet compliance. Refactoring to managed services may simplify compliance but is not required.
Lift-and-shift (rehost) moves your existing applications to Azure VMs without changes, focusing on speed. Refactor (rearchitect) modifies your application code to use Azure PaaS services like App Service or SQL Database, improving scalability and reducing management overhead. The key difference is the amount of change: none vs. significant.
Use lift-and-shift when you need to migrate quickly (e.g., data center lease expiring), your application is stable and doesn't need cloud-native features, or you plan to refactor later. It's also suitable for applications that are hard to change (e.g., third-party apps).
No. Refactoring can involve any PaaS service, not just serverless. Common refactoring targets include Azure App Service (web apps), Azure SQL Database (managed database), and Azure Kubernetes Service (containers). Serverless (Azure Functions) is one option but not the only one.
Yes. Most enterprises use a hybrid approach: they lift-and-shift critical but stable apps to meet deadlines, while refactoring others that need scalability or lower costs. Azure Migrate supports both strategies.
Lift-and-shift has lower upfront cost but can be more expensive long-term because you pay for VMs (compute+storage) even when idle. Refactor has higher upfront development cost but often reduces ongoing costs through better resource utilization and managed services.
Yes. It's one of the six common migration strategies (the 6 R's). It's called 'rehost' in the Azure Cloud Adoption Framework. It's a valid strategy for many organizations.
Azure Migrate is the main tool. It helps discover, assess, and migrate on-premises VMs. Azure Site Recovery can also be used for replication and failover. Both are integrated into the Azure portal.
You've just covered Lift-and-Shift vs Refactor Migration — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?