Cloud Migration Patterns: Lift-and-Shift vs Re-Architecture Decision Framework

The 6 R's of Cloud Migration

Application Assessment

Score each application on two dimensions: strategic value (how important is this application to the business? Revenue-generating apps score high. Internal tools, legacy reporting systems score low). Technical readiness (how cloud-ready is the application? 12-factor apps, containerized services score high. Monoliths with hardcoded configs, local file dependencies score low). The scoring matrix: high strategic + high readiness → re-architect. High strategic + low readiness → replatform (improve incrementally, plan re-architecture later). Low strategic + any readiness → rehost or retain. End-of-life → retire or repurchase.

Lift-and-Shift

Lift-and-shift migrates the application to a cloud VM with no code changes. When it's right: datacenter exit deadline (the lease expires in 6 months — no time to re-architect), non-strategic applications (the legacy HR reporting tool — investing $200K in re-architecture for $5K/year value makes no sense. Lift-and-shift costs $10K and takes 2 weeks), and interim strategy (rehost now to exit the datacenter, re-architect later). Limitations: the application runs on a VM — you're paying for cloud infrastructure without leveraging cloud services. No auto-scaling, no managed services. The cloud bill may be higher than on-premises for always-on VMs. Lift-and-shift is a migration strategy — not a cloud strategy.

Replatform: The Middle Ground

Replatform makes targeted changes: database migration (on-prem SQL Server → Azure SQL Database. The application connects to the managed database — automated backups, patching, HA without code changes), storage migration (local file storage → cloud object storage — unlimited storage, built-in redundancy), caching (in-memory cache → managed Redis — shared cache, auto-failover), and load balancing (hardware LB → cloud LB — auto-scaling, health checks). Each replatform change: 1-2 weeks, minimal code changes, measurable cloud benefit. Total replatform effort: 4-8 weeks, delivering 50-70% of re-architecture benefits at 30% of the cost.

Re-Architecture

Re-architecture redesigns for cloud-native patterns: containerization (Docker containers on Kubernetes — auto-scaling, rolling deployments, IaC), microservices decomposition (split the monolith — independent scaling, independent releases), serverless (event-driven functions that scale to zero — pay-per-execution), and managed services (replace custom components with cloud services). When justified: the application is strategic and growing (5+ year horizon). The current architecture limits business agility. The cloud cost of the un-optimized application exceeds the re-architecture investment within 18 months. Re-architecture timeline: 3-6 months for a medium-complexity application. The investment is justified by: reduced operational cost (managed services), improved agility (faster releases), and improved resilience (auto-healing, multi-region capability).

Data Migration in Cloud Transitions

Application migration includes data migration: database migration (schema migration → data migration → ongoing synchronization until cutover. Tools: Azure Database Migration Service, AWS DMS), file migration (file shares → cloud storage. Considerations: permissions mapping, file path references, large volume transfer — Azure Data Box for 10TB+), and data synchronization during transition (during parallel operation, CDC patterns keep the target current until cutover — see CDC implementation). Data migration is often the longest phase — plan 4-8 weeks. The application migration may take 2 weeks; the data migration takes 8 weeks. Plan accordingly and start data migration early.

Portfolio Migration Planning

For 50+ applications: wave planning (group into waves of 5-10. Wave 1: low-risk, well-understood apps — build migration muscle. Final waves: most complex and critical), dependency mapping (Application A depends on Database B used by Application C — all three migrate together or the integration breaks. Map dependencies before creating waves), landing zone readiness (cloud landing zone must be ready before migration: networking, security, identity, monitoring, governance — configured and validated), and cost modeling (estimate cloud cost per application. Compare to on-premises. Flag apps where cloud cost exceeds on-prem — these need replatform/re-architecture or may be retain candidates).

Cost Modeling and Optimization

The cloud cost advantage comes from: right-sizing (most on-prem servers are over-provisioned by 60-70%), auto-scaling (pay for peak only when you need peak), managed services (eliminate the 2-3 FTEs managing databases, patching, and backups), and elimination of capital expenditure (no hardware purchases, no datacenter lease, no refresh cycles). Rehost alone often doesn't achieve cost savings — replatform is the minimum for measurable cost reduction. Re-architecture achieves the most savings but requires the most investment. The optimal portfolio strategy: rehost 30% (non-strategic), replatform 40% (moderate strategic value), re-architect 20% (high strategic value), retire/repurchase 10%.

Cloud Migration Risk Assessment

Risk assessment produces a risk register that's reviewed weekly during active migration. Each risk has: probability (high/medium/low), impact (high/medium/low), owner (who's responsible for mitigation), and status (open/mitigating/closed). The risk register drives: migration wave sequencing (high-risk applications in later waves after the team gains experience), contingency planning (rollback procedures for high-impact risks), and resource allocation (additional testing for high-risk migrations).

Cloud Landing Zone Prerequisites

Before migrating any workload, the cloud landing zone must be configured: identity and access (Azure AD / Entra ID connected to corporate directory; role-based access control configured; conditional access policies for cloud resources), networking (hub-and-spoke VNet topology; ExpressRoute or VPN to on-premises; DNS configuration for hybrid resolution; network security groups for traffic control), security (Azure Defender / Security Center enabled; Azure Policy for compliance enforcement; Key Vault for secrets management; logging to centralized SIEM), governance (management group hierarchy matching organizational structure; subscription design for workload isolation; tagging policy for cost attribution; naming conventions documented and enforced), and monitoring (Azure Monitor configured; Log Analytics workspace deployed; alerting for security events and resource health; dashboard for migration progress tracking). Landing zone deployment: 4-8 weeks for a greenfield environment; 2-4 weeks to augment an existing cloud presence. The landing zone is the foundation — migrating workloads into an un-governed cloud environment creates security, compliance, and cost risks that are expensive to remediate after the fact.

Post-Migration Optimization

Migration is phase 1. Optimization is phase 2 — often delivering more value than the migration itself: right-sizing (after 30 days of production metrics: resize VMs based on actual CPU/memory utilization. Typical finding: 60-70% of migrated VMs are over-provisioned. Right-sizing saves 30-50% on compute), reserved instances (for workloads that run 24/7: purchase 1-year or 3-year reserved capacity. Savings: 30-60% vs pay-as-you-go. Wait 30 days post-migration to confirm usage patterns before committing), auto-scaling (for workloads with variable load: configure auto-scaling based on CPU/memory/request metrics. Savings: 40-60% vs always-on peak capacity), storage tiering (move infrequently accessed data to cool/archive tiers. Savings: 50-90% on storage for data accessed less than once per month), and managed service migration (migrate from IaaS to PaaS where possible: SQL on VM → Azure SQL Database, custom Redis → Azure Cache for Redis. Savings: operational overhead eliminated + typically 20-30% infrastructure cost reduction). Post-migration optimization typically reduces cloud cost by 30-50% within 6 months — making the cloud migration cost-neutral or cost-positive compared to on-premises.

Migration Success Metrics

Multi-Cloud Migration Considerations

Organizations migrating to multiple cloud providers face additional complexity: workload placement (which workloads go to which cloud? Decision factors: existing cloud investments, vendor relationships, data residency requirements, service availability, and team expertise. Common pattern: primary cloud for 80% of workloads + secondary cloud for specific use cases), network architecture (cross-cloud networking: Azure ExpressRoute ↔ AWS Direct Connect via colocation facility or cloud interconnect services. Latency between clouds: 5-20ms typically — acceptable for async communication but not for synchronous API calls), identity federation (single identity provider (Azure AD/Entra ID) federated across clouds — users authenticate once, access resources on both clouds. Avoid: separate identity systems per cloud — creates user management overhead and security gaps), data gravity (data tends to stay where it's created — moving data between clouds is expensive and slow. Design: compute moves to where data lives, not the reverse. If 10TB of data lives in Azure, process it in Azure — don't copy it to AWS for processing), and operational consistency (use cloud-agnostic tools where possible: Terraform for infrastructure, Kubernetes for compute, Prometheus/Grafana for monitoring — reducing the operational learning curve across clouds). Multi-cloud adds 30-50% operational complexity — adopt it deliberately for specific business reasons, not as a default strategy.

Application-Level Migration Checklist

Per-application checklist before migration: dependency inventory (what does this application depend on? databases, file shares, APIs, message queues, scheduled jobs, certificates, DNS entries, shared libraries, and configuration files — each dependency must be migrated or reconfigured), configuration externalization (hardcoded connection strings, file paths, and environment-specific settings must be externalized to: environment variables, configuration files, or Key Vault — before migration), authentication review (how does the application authenticate to dependencies? Service accounts, certificates, managed identities, API keys — each must be recreated or mapped in the cloud), performance baseline (document current performance: response times, throughput, error rates — the baseline for post-migration comparison. Without a baseline, you can't prove the migration maintained performance), and compliance review (data classification: does this application process PII, PHI, PCI, or other regulated data? If yes: the target cloud environment must meet the regulatory requirements before data migrates).

Go Deeper

Continue building your understanding with these related resources from our consulting practice.