70% of cloud migration projects exceed budget or miss their deadline. The failure mode is consistent: organizations begin migrations before completing the assessment phase, underestimate application interdependencies, and attempt to migrate all workloads simultaneously. The technical complexity of cloud migration is manageable. The project management failures are not.
This guide covers the 6R cloud migration framework, the five migration phases from assessment to optimization, risk management by category, cost modeling for migrations of different scales, and the KPI frameworks that distinguish successful cloud migrations from expensive infrastructure relocations. By the end, you will have a structured approach to cloud migration planning that avoids the most common failure patterns.
Cloud Migration Strategy: Why the 6R Framework Matters
AWS introduced the 6R migration strategy framework (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) as a classification system for application migration decisions. The framework matters because it prevents the default mistake: treating every application as a Rehost (lift-and-shift) candidate regardless of whether that approach delivers cloud value.
Each application in your portfolio has different characteristics — age, business criticality, technical debt, compliance requirements, and interdependencies. The 6R framework provides a consistent vocabulary for categorizing migration decisions and communicating them across technical and business stakeholders.
Rehost: Lift-and-Shift
Rehost moves applications to cloud infrastructure without code changes. The application continues to run on virtual machines; only the hosting environment changes from physical data center to cloud VMs.
Rehost is appropriate for: legacy applications where code modification is expensive or risky, stable systems with predictable resource consumption, applications with no near-term modernization roadmap. The primary benefit is infrastructure cost reduction from eliminating data center overhead.
Expected outcomes: 3–4 month migration timeline for small-to-medium system portfolios; 25–40% operational cost reduction within 18 months from elimination of hardware amortization, power, and data center facilities costs. Cloud-native features (auto-scaling, managed backups, snapshots) become available without code changes.
Limit: Rehost does not improve application architecture. A monolithic application that is slow to deploy remains slow to deploy in cloud VMs. It captures infrastructure economics without cloud-native agility.
Replatform: Lift-Tinker-and-Shift
Replatform makes targeted infrastructure substitutions without changing application architecture. The most common example: migrating a self-managed database server to a managed database service (AWS RDS, Azure Database for PostgreSQL).
Replatform captures managed service benefits — automated backups, OS patching, storage auto-scaling, built-in high availability — without the cost or timeline of application refactoring. Database replatforming typically improves performance (SSD storage, optimized instance types) and reduces operational overhead significantly.
For each replatform candidate, evaluate: migration complexity (schema differences between source and target), validation requirements (data integrity verification), and the operational savings from managed service substitution. The ROI calculation for database replatforming is usually straightforward: staff time saved on backups, patching, and replication setup versus migration effort.
Refactor: Re-architect for Cloud Native
Refactor reimagines the application architecture for cloud-native operation: breaking monoliths into microservices, containerizing workloads, adopting managed messaging services, and integrating cloud-native scaling patterns.
Refactor has the highest upfront cost and longest timeline (12–24 months for complex applications) but delivers the largest long-term value: deployment velocity improvements of 3–5x, infrastructure cost reductions from right-sized containers versus VMs, and the ability to scale individual service components independently.
The business case for refactoring must be made explicitly — it is not self-evident from infrastructure cost savings alone. The decision to refactor should be driven by deployment bottlenecks, scaling constraints, or reliability problems that the current architecture cannot solve, not by the desire to use newer technology.
Repurchase: Replace with SaaS
Repurchase replaces a custom-built or on-premises package application with a cloud SaaS alternative. Examples: replacing a self-hosted CRM with Salesforce, replacing an on-premises HR system with Workday, replacing a self-hosted email platform with Google Workspace.
The repurchase decision requires honest assessment of total cost of ownership: current software licensing, internal development and maintenance staff, infrastructure costs, and the cost of custom features not available in the SaaS replacement. Organizations consistently underestimate the cost of maintaining custom applications and overestimate the feature gap between their custom system and commercial SaaS alternatives.
Retire: Decommission
Retire decommissions applications that are no longer providing business value. Asset portfolio audits consistently identify 10–30% of applications as retirement candidates — systems built for projects that completed, duplicates of functionality now provided by other systems, or applications with usage below their infrastructure cost justification.
Each retired application eliminates ongoing operational cost, reduces the portfolio complexity that migration teams must manage, and removes security attack surface. Organizations that invest time in thorough portfolio audits before beginning migrations routinely identify retirement savings that partially offset migration costs.
Retain: Keep On-Premises
Retain defers migration for applications that are not ready: active development making migration timing impractical, compliance requirements specifying on-premises data residency, or applications near end-of-life that will be retired within 12–18 months. Retained applications should have an explicit future disposition date — "retain indefinitely" is not a migration strategy.
Cloud Migration Strategy: The 6R Decision Matrix
| Application Characteristic | Best Fit |
|---|---|
| Legacy custom code, stable, no modernization roadmap | Rehost |
| Self-managed databases or middleware | Replatform |
| Monolith with scaling or deployment bottlenecks | Refactor |
| Package software with available SaaS equivalent | Repurchase |
| Low utilization, duplicated functionality | Retire |
| Active development, compliance constraints, near EOL | Retain |
Five Migration Phases
Phase 1: Assessment
Assessment is the most critical phase and the most frequently compressed. Teams that spend 6–8 weeks on thorough assessment avoid the most expensive migration failures. The output of assessment is a complete application inventory with 6R classification, dependency mapping, and a prioritized migration sequence.
Application inventory components: server count and purpose, operating system versions and end-of-support dates, database engines and versions, network dependencies (which application calls which), data classification (public, internal, confidential, regulated), compliance requirements (GDPR, PCI-DSS, HIPAA, SOC 2).
Dependency mapping is the step most teams underinvest in. An application that appears to be standalone often has implicit dependencies on shared databases, on-premises Active Directory, or internal network services. Migrating that application without its dependencies to cloud first produces a broken system — traffic still returns to the on-premises data center for every authentication request.
Phase 2: Planning and Architecture Design
Migration planning translates the assessment output into a sequenced migration plan. Applications are grouped into waves: low-risk, low-dependency applications migrate first to validate the cloud environment and team processes before higher-criticality systems.
Architecture design for each migrating application includes: target cloud service selection, VPC design (which subnets will the application use), IAM role design (what permissions does the application need), data migration approach, and rollback procedure if the migration must be reversed.
Security architecture is designed during this phase, not after. Network segmentation, IAM boundary definitions, encryption key management, and logging configuration should be defined before the first migration wave begins.
Phase 3: Pilot Migration (Proof of Concept)
The pilot migration deploys two to three low-risk applications to the cloud environment and validates the full migration process: infrastructure provisioning, application deployment, data migration, monitoring configuration, and rollback procedure. The pilot surfaces process gaps and tooling issues before they affect business-critical systems.
Pilot selection criteria: applications with low business impact if the migration encounters problems, minimal external dependencies, and workloads that exercise the migration tooling and processes planned for more complex applications.
Document every issue encountered during the pilot and its resolution. The pilot runbook becomes the template for subsequent migration waves.
Phase 4: Migration Waves
Waves migrate applications in groups organized by dependency order and business risk. Wave 1 typically contains development and test environments plus low-criticality production systems. Later waves include business-critical applications migrated with blue-green or canary deployment patterns.
Blue-green migration: bring up the cloud environment in parallel with the on-premises environment, validate the cloud deployment fully, then cut traffic over. Rollback is a DNS change. Blue-green requires maintaining both environments simultaneously during the cutover window — typically 1–4 weeks.
Data migration is the highest-risk component of each wave. For active databases, AWS Database Migration Service (DMS) provides continuous replication from source to target, enabling near-zero-downtime cutovers with a brief maintenance window for final synchronization and traffic cutover. Validate data integrity with row count comparisons and checksum verification before decommissioning source systems.
Phase 5: Optimization
Post-migration optimization begins 30–90 days after cutover, once the cloud environment has stabilized. The optimization backlog includes: rightsizing (matching instance types to actual utilization), Reserved Instance purchases for predictable workloads, auto-scaling policy tuning, unused resource cleanup, and cloud security posture review.
Most organizations achieve their target cost structure 6–9 months after migration completion, not immediately. The first month post-migration typically shows higher cloud costs than projected because instances are provisioned conservatively and Reserved Instances have not yet been purchased.
Risk Management by Category
Data Loss Risk
Probability: Medium (10–15%) | Impact: Critical
Mitigation: Full backup verification before migration begins; parallel operation of source and target during migration window; data integrity validation (row counts, checksums on critical tables) before decommissioning source. Never decommission a source system without verified data integrity in the target.
Downtime Risk
Probability: Medium (15–20%) | Impact: High
Mitigation: Blue-green deployment for all production migrations; rollback runbooks tested before cutover; maintenance window communication to users for planned downtime; monitoring dashboards prepared before cutover so post-migration issues are visible immediately.
Security Risk
Probability: High (20–25%) | Impact: Critical
Mitigation: Security architecture review before migration; penetration testing of cloud environment before cutover; IAM configuration audit (no overly permissive roles); network segmentation verification; CloudTrail and VPC Flow Logs enabled on day one.
Compliance Risk
Probability: Low (5–10%) | Impact: Critical
Mitigation: Data residency requirements mapped before cloud region selection; compliance documentation for regulated data (GDPR, HIPAA, PCI-DSS) updated to reflect cloud architecture; data processing agreements with cloud providers established before regulated data migrates.
Migration Cost Model
Migration cost has two components: one-time migration investment and ongoing cloud operating cost. Both must be modeled accurately to build a credible business case.
Migration Investment by Scale
| Scale | Systems | Timeline | Estimated Investment |
|---|---|---|---|
| Small | 1–5 systems | 3–4 months | $30K–$80K |
| Medium | 10–20 systems | 6–9 months | $150K–$400K |
| Large | 50+ systems | 12–24 months | $500K–$1.5M+ |
Investment components: cloud architect and migration engineer fees, application modification (replatform/refactor scope), data migration tooling and labor, security architecture and penetration testing, training and knowledge transfer, project management.
Ongoing Cloud Operating Cost vs. On-Premises
A representative medium-scale comparison (50 servers):
On-premises annual cost:
- Hardware amortization: $60K
- Power and cooling: $30K
- Software licensing: $40K
- IT staff (3 FTE partial): $80K
- Network and storage: $20K
- Total: ~$230K/year
AWS annual cost (post-optimization):
- EC2 (Reserved Instances, right-sized): $45K
- RDS Multi-AZ: $20K
- S3 and backup: $8K
- CloudFront CDN: $4K
- Cloud engineer (1 FTE partial): $15K
- Total: ~$92K/year
Annual savings: ~$138K (60% reduction) Payback period at $250K migration investment: ~22 months
These figures are representative; actual savings depend heavily on current on-premises costs, target workload characteristics, and Reserved Instance commitment levels.
Success Metrics for Cloud Migration
Define KPIs before migration begins. Post-migration success cannot be measured against undefined baselines.
Financial KPIs: Monthly cloud cost vs. on-premises baseline; Reserved Instance coverage (target >60%); cloud waste percentage (unused capacity as % of total spend, target <5%).
Operational KPIs: System uptime (target 99.9%+); deployment frequency (measured in deployments per week); mean time to recovery for incidents; backup restoration test success rate.
Migration execution KPIs: Applications migrated on schedule; budget variance; data integrity validation pass rate; rollback events (goal: zero).
Organizations that track these metrics from the first migration wave identify cost and performance issues early enough to correct them before they affect the overall program budget or timeline.
Related Articles
MLOps Guide: Taking Machine Learning Models to Production [2026]
87% of machine learning models built by data science teams never reach production. The models work — they pass cross-validation, they score well on holdout sets, they demonstrate genuine predictive value. The problem is not the modeling. The problem is everything that happens between a notebook experiment and a reliable, monitored, production system. MLOps is the discipline that closes that gap. This guide covers the full MLOps stack: maturity levels, tooling choices (MLflow, DVC, Kubeflow
Read More: MLOps Guide: Taking Machine Learning Models to Production [2026]LLM Fine-Tuning Guide: Custom Model Training with LoRA and QLoRA [2026]
General-purpose LLMs are impressive. They can write code, summarize documents, answer questions, and translate between languages with reasonable accuracy. But "reasonable" is not good enough when your application requires consistent output format, domain-specific terminology, a particular tone, or behavior that the base model was never trained to exhibit. That gap is where fine-tuning matters. Fine-tuning updates a model's weights on your specific data, changing how the model behaves — not
Read More: LLM Fine-Tuning Guide: Custom Model Training with LoRA and QLoRA [2026]Computer Vision Applications: Object Detection, OCR, and Industrial AI [2026]
Computer vision has moved well past the research phase. The models are trained, the frameworks are mature, the hardware is accessible, and the use cases are generating measurable returns. What was a specialized capability requiring deep expertise in 2018 is now deployable infrastructure — if you know which component to reach for and where the real complexity lives. This guide covers computer vision applications across industrial, medical, logistics, and document processing domains. It expl
Read More: Computer Vision Applications: Object Detection, OCR, and Industrial AI [2026]