In This Article
- Why Cloud Migration Is a Strategy Decision, Not an IT Project
- The 6R Framework: One Decision Per Application
- Application Portfolio Assessment: Scoring 200+ Applications
- Wave Planning: Sequencing Migration for Minimum Risk
- Rehost (Lift-and-Shift): When Speed Beats Optimization
- Replatform: The Middle Path With Maximum ROI
- Refactor: Cloud-Native for Strategic Applications
- Cost Management: Avoiding the Cloud Cost Surprise
- Execution Playbook: From Assessment to Production
- Go Deeper
Why Cloud Migration Is a Strategy Decision, Not an IT Project
A manufacturing company migrates 150 applications to Azure over 18 months. The CIO declares success — everything is "in the cloud." Then the bills arrive: cloud spend is 40% higher than the on-premises infrastructure it replaced. Why? 60% of applications were lift-and-shifted without right-sizing — they're running on cloud VMs provisioned to match their on-premises specifications (oversized for peak capacity that occurs 2 days per month). 15% of applications could have been retired (nobody uses them, but nobody decommissioned them either). 10% should have been replaced by SaaS (the company pays for custom-hosted software when the vendor offers a cloud-native version). And 8 applications that should have been refactored for cloud-native architecture are running as monoliths on expensive VMs — getting none of the elasticity, resilience, or operational benefits that justified the migration.
The migration succeeded technically (everything runs) and failed strategically (no business benefit, higher cost). The missing step: a structured assessment that determines the right migration strategy for each application, based on business value, technical complexity, and cloud readiness — not a blanket "move everything as-is."
The 6R Framework: One Decision Per Application
| Strategy | What It Means | When to Use | Effort | Cloud Benefit Realized |
|---|---|---|---|---|
| Rehost | Move as-is to cloud VMs | Quick wins, datacenter exit deadlines, low-value apps | Low | 10-20% (infrastructure only) |
| Replatform | Minor modifications for cloud services | Databases to managed services, containers, PaaS | Medium | 40-60% (managed services + elasticity) |
| Refactor | Redesign for cloud-native architecture | Strategic applications, high-scale, competitive advantage | High | 80-100% (full cloud-native benefits) |
| Repurchase | Replace with SaaS | Commodity applications (CRM, HRMS, email) | Medium | Variable (vendor-dependent) |
| Retire | Decommission | Unused, redundant, or replaced applications | Low | 100% (eliminate cost entirely) |
| Retain | Keep on-premises | Regulatory, latency, or dependency constraints | None | 0% (not migrated) |
Application Portfolio Assessment: Scoring 200+ Applications
The assessment scores each application across 6 dimensions to determine the appropriate 6R strategy.
| Dimension | What It Measures | Score 1 | Score 5 |
|---|---|---|---|
| Business Value | Revenue impact, user count, strategic importance | Used by <10 people, could be retired | Revenue-generating, 1000+ users, core process |
| Technical Complexity | Architecture, dependencies, customization | Standalone, standard config, no integrations | Monolith, 20+ integrations, heavy customization |
| Cloud Readiness | Architecture compatibility with cloud services | Mainframe, proprietary OS, hardware-dependent | Containerized, API-based, stateless |
| Data Sensitivity | Regulatory and compliance requirements | Public data, no compliance | PII, HIPAA, financial data, data residency |
| Operational Cost | Current annual operating cost (infra + support) | <$10K/year | >$500K/year |
| Modernization Benefit | Value gained from cloud-native capabilities | No benefit from elasticity, DevOps, managed services | Massive benefit from auto-scaling, global reach |
Score-to-strategy mapping: Low value + low complexity = Retire or Rehost. High value + low complexity = Replatform. High value + high complexity + high modernization benefit = Refactor. Commodity application with SaaS available = Repurchase. Regulatory constraint = Retain (for now).
Wave Planning: Sequencing Migration for Minimum Risk
Wave 0: Foundation (Month 1-2)
Set up the cloud landing zone: network architecture (VNet, subnets, peering), identity integration (Entra ID / AD Connect), security baseline (Azure Policy, Defender for Cloud), monitoring (Azure Monitor, Log Analytics), and cost management (budgets, alerts, tagging strategy). The landing zone is the foundation every subsequent wave deploys into.
Wave 1: Quick Wins (Month 2-4)
Migrate 5-10 low-risk, low-complexity applications. Purpose: validate the migration process, train the team, and prove the landing zone works. Select: applications with no external dependencies, low user count, and clear rollback path. Wave 1 is about building muscle, not moving critical workloads.
Wave 2-4: Core Migration (Month 4-10)
Migrate 30-50 applications per wave, grouped by dependency cluster (applications that integrate with each other migrate together). Each wave follows: assess → plan → migrate → test → cutover → optimize. Azure Migrate handles discovery, assessment, and orchestration for rehost/replatform workloads.
Wave 5+: Optimization (Month 10+)
Post-migration optimization: right-size VMs (most are over-provisioned initially), implement auto-scaling for variable workloads, convert rehosted applications to containers or PaaS where beneficial, and decommission on-premises infrastructure. Optimization typically reduces cloud spend by 25-40% compared to the initial rehosted state.
Rehost (Lift-and-Shift): When Speed Beats Optimization
Rehost moves the application to cloud VMs with minimal changes. The application doesn't know it moved — same OS, same configuration, same architecture, different datacenter. Use rehost when: datacenter lease expires (deadline-driven), application has short remaining lifecycle (will be retired in 12-18 months), or the application's business value doesn't justify replatforming investment. Rehost captures infrastructure benefits (no hardware management, datacenter costs eliminated) but misses cloud-native benefits (elasticity, managed services, DevOps). It's the right strategy for 30-40% of enterprise portfolios — not 100%.
Replatform: The Middle Path With Maximum ROI
Replatform makes targeted modifications to use cloud-managed services without redesigning the application. Common replatforming moves: SQL Server on VMs → Azure SQL Managed Instance (managed database, automated patching, built-in HA), IIS on VMs → Azure App Service (managed hosting, auto-scaling, deployment slots), file shares → Azure Files or Blob Storage (managed storage, geo-redundancy), and scheduled jobs → Azure Functions (serverless, pay-per-execution). Each move eliminates operational burden (no OS patching, no HA configuration, no capacity planning) while preserving the application's logic and architecture. Replatforming typically delivers 40-60% of cloud-native benefits at 30% of refactoring effort — the highest ROI per engineering hour for most applications.
Refactor: Cloud-Native for Strategic Applications
Refactor redesigns the application for cloud-native architecture — microservices, Kubernetes, serverless, event-driven, API-first. Refactoring captures full cloud benefits: auto-scaling (handle 10x traffic spikes without provisioning), resilience (failure of one component doesn't crash the application), continuous deployment (deploy features multiple times per day), and global distribution (deploy to multiple regions with traffic routing). Reserve refactoring for: applications where cloud-native capabilities create competitive advantage (customer-facing platforms, high-scale services), applications with 5+ year lifecycle, and applications where current architecture prevents business agility.
Cost Management: Avoiding the Cloud Cost Surprise
The #1 post-migration complaint: "cloud costs more than on-premises." It does — when migration is lift-and-shift without optimization. Cost management practices that prevent the surprise:
Right-sizing: The on-premises VM had 32GB RAM because "we might need it." Cloud VMs should be sized to actual utilization — which is typically 15-30% of provisioned capacity. Right-sizing after migration reduces compute costs by 30-50%. Azure Advisor and AWS Cost Explorer provide right-sizing recommendations based on actual utilization.
Reserved instances: For steady-state workloads that run 24/7, reserved instances (1-year or 3-year commitment) reduce costs by 40-72% compared to on-demand pricing. The commitment should cover baseline load; on-demand handles burst capacity. Typical enterprise cloud bills: 60% reserved (baseline) + 40% on-demand (variable).
Auto-scaling and scheduling: Development environments don't need to run 24/7. Auto-shutdown during off-hours saves 65% on dev/test costs. Production workloads with variable demand should auto-scale — scale up during business hours, scale down overnight. Infrastructure automation enforces these patterns.
Tagging and chargeback: Every cloud resource tagged with: application, environment (prod/dev/test), owner, cost center, and project. Tags enable: cost allocation (which application costs what?), waste identification (untagged resources are orphaned — investigate and delete), and department chargeback (each business unit sees and manages their own cloud spend).
Cloud should cost 20-30% less than on-premises when properly managed. If it costs more, the likely causes: over-provisioned VMs (right-size), no reserved instances (commit for baseline), dev environments running 24/7 (schedule shutdown), and orphaned resources (tag and clean). Address these four issues before concluding that "cloud is expensive."
Execution Playbook: From Assessment to Production
Weeks 1-4: Assessment
Inventory all applications (Azure Migrate Discovery for automated scanning). Score each application across 6 dimensions. Assign 6R strategy. Estimate migration effort and cost per application. Produce the migration business case.
Weeks 5-8: Landing Zone + Wave 1
Build the cloud landing zone (network, identity, security, monitoring, governance). Migrate Wave 1 (5-10 quick-win applications). Validate the process, train the team, document runbooks.
Months 3-10: Core Migration Waves
Execute Waves 2-4 following the dependency-grouped plan. Each wave: migrate, test, cutover, verify, optimize. Parallel streams: rehost (fastest), replatform (medium), and refactor (longest — separate project timeline).
Months 10-12: Optimization + Decommission
Right-size all rehosted workloads. Implement reserved instances for steady-state. Deploy auto-scaling for variable workloads. Decommission on-premises infrastructure. Produce the post-migration cost analysis.
Hybrid Cloud: When Full Migration Isn't the Answer
Not every workload should migrate. The "Retain" strategy in the 6R framework acknowledges that some applications are better served on-premises — or in a hybrid architecture where some components run in the cloud and others stay on-premises. Common retain scenarios: latency-sensitive manufacturing systems (real-time control systems that can't tolerate 20ms network round-trips to the cloud), data residency constraints (regulations requiring data to stay within specific physical locations), mainframe applications (legacy systems with no practical migration path — modernize gradually, don't force-migrate), and edge computing workloads (IoT processing that must happen at the factory/store/device level). Hybrid architecture connects retained on-premises workloads with cloud services through: Azure Arc (manage on-premises resources from Azure portal), Azure ExpressRoute (dedicated high-speed connection), and Azure Stack HCI (Azure services running on-premises hardware). The goal isn't 100% cloud — it's each workload running where it performs best.
Migration Governance and Risk Management
Enterprise migration requires governance that controls risk without blocking progress. The governance framework covers: migration approval gates (each application passes readiness review before migration), rollback procedures (every migrated application must have a tested rollback plan — if the cloud deployment fails, the on-premises environment is restored within the defined RTO), change management (users are trained, support teams are prepared, and communication covers the migration timeline and any expected disruption), and compliance verification (post-migration validation that the cloud deployment meets the same compliance requirements as the on-premises deployment — especially for HIPAA, PCI-DSS, and SOX-regulated applications).
The Xylity Approach
We execute cloud migration with the 6R assessment-first approach — scoring every application before moving anything. Our cloud architects, Azure engineers, and DevOps engineers build the landing zone, execute wave-based migration, and optimize post-migration — transferring the operational capability so your team manages the cloud environment independently.
Go Deeper
Continue building your understanding with these related resources from our consulting practice.
Migrate With Strategy, Not Just Speed
6R assessment, wave planning, cost optimization — cloud migration that reduces costs by 20-30% instead of increasing them by 40%.
Start Your Cloud Migration Assessment →