The 6 Rs of Cloud Migration

Gartner defined six strategies for cloud migration. Choosing the right approach for each application determines your success and ROI.

1. Rehost (Lift and Shift)

What It Is: Move applications to cloud with minimal changes. Virtual machines migrate as-is.

When to Use:

• Urgent datacenter exit
• First step in broader transformation
• Legacy applications with complex dependencies
• Applications nearing end-of-life

Pros:

• ✓ Fastest migration path
• ✓ Lowest initial cost
• ✓ Minimal risk
• ✓ Quick wins for stakeholders

Cons:

• ✗ Limited cloud benefits
• ✗ Ongoing high operational costs
• ✗ Technical debt carried forward
• ✗ No scalability improvements

Example: 100 VMs hosting legacy Java EE applications move to EC2 instances with AWS Migration Hub.

2. Replatform (Lift, Tinker, and Shift)

What It Is: Minor optimizations during migration without changing core architecture.

When to Use:

• Applications with obvious optimization opportunities
• Self-managed databases that can use managed services
• Workloads that benefit from specific cloud features

Typical Changes:

• Self-managed MySQL → Amazon RDS
• On-premise load balancers → Cloud load balancers
• Manual scaling → Auto-scaling groups

Pros:

• ✓ Better than pure rehost
• ✓ Some immediate cost savings
• ✓ Reduced operational overhead
• ✓ Still relatively quick

Cons:

• ✗ Not fully cloud-native
• ✗ Limited scalability gains
• ✗ May need future refactoring

Example: Migrate application servers to EC2 but replace Oracle Database with Amazon Aurora.

3. Repurchase (Drop and Shop)

What It Is: Replace existing applications with SaaS alternatives.

When to Use:

• Commercial software with SaaS equivalents
• Home-grown tools that don’t provide competitive advantage
• High maintenance cost applications

Common Migrations:

• Email servers → Microsoft 365 / Google Workspace
• On-premise CRM → Salesforce
• File servers → SharePoint / Dropbox
• HR systems → Workday / BambooHR

Pros:

• ✓ No infrastructure to manage
• ✓ Always up-to-date features
• ✓ Predictable pricing
• ✓ Faster deployment

Cons:

• ✗ Data migration complexity
• ✗ Customization loss
• ✗ Potential vendor lock-in
• ✗ Ongoing subscription costs

4. Refactor (Re-architect)

What It Is: Redesign applications to be cloud-native, typically breaking monoliths into microservices.

When to Use:

• Core business applications
• Applications needing better scalability
• Monoliths causing deployment bottlenecks
• Applications with high technical debt

Transformation Examples:

• Monolith → Microservices on Kubernetes
• Traditional database → Multi-region distributed database
• Synchronous processing → Event-driven architecture
• Manual deployment → CI/CD pipelines

Pros:

• ✓ Maximum cloud benefits
• ✓ Improved scalability and resilience
• ✓ Better developer productivity
• ✓ Long-term cost optimization

Cons:

• ✗ Highest cost and effort
• ✗ Requires significant expertise
• ✗ Longest timeline (months to years)
• ✗ Risk of scope creep

Real Example:

E-commerce monolith refactored into:

• Product catalog service (Node.js + MongoDB)
• Order processing service (Java + PostgreSQL)
• Payment service (Python + Redis)
• Inventory service (Go + DynamoDB)
• API gateway (Kong/AWS API Gateway)
• Event bus (Kafka/AWS EventBridge)

5. Retire

What It Is: Decommission applications that are no longer needed.

When to Use:

• Redundant applications (common after mergers)
• Shadow IT discoveries
• Applications with < 10% utilization
• Functionality now covered by other systems

Process:

1. Identify application dependencies
2. Notify stakeholders
3. Archive data per compliance requirements
4. Decommission infrastructure
5. Redirect users to alternatives

Benefits:

• Reduced license costs
• Lower operational overhead
• Simplified portfolio
• Security risk reduction

Statistics: Companies typically retire 10-20% of applications during cloud migrations.

6. Retain (Revisit)

What It Is: Keep applications on-premises, at least for now.

When to Use:

• Applications scheduled for replacement
• Regulatory constraints on cloud usage
• Extremely complex mainframe applications
• Applications with hardware dependencies
• Recent major upgrades (wait for ROI)

Not a Permanent Decision: Revisit quarterly as cloud capabilities evolve and constraints change.

Building Your Migration Strategy

Application Assessment Framework

Score each application (1-5) on:

1. Business Criticality: How important is it?
2. Technical Complexity: How hard to migrate?
3. Technical Debt: How much modernization needed?
4. Cloud Readiness: How compatible with cloud?
5. Operational Cost: What are current costs?

Decision Matrix:

Migration Waves

Never migrate everything at once:

Wave 1: Quick Wins (Months 1-3)

• Development/test environments
• Low-risk applications
• Clear rehost candidates
• Build team confidence

Wave 2: Foundation (Months 3-6)

• Core infrastructure services
• Establish patterns and standards
• CI/CD pipelines
• Observability platform

Wave 3: Business Applications (Months 6-18)

• Production workloads
• Replatform opportunities
• Begin refactoring initiatives
• Optimize costs

Wave 4: Complex Systems (Months 12-24+)

• Core business systems
• Major refactoring projects
• Data platform migrations
• Legacy system replacement

Common Pitfalls to Avoid

1. Migrating without optimization: Rehosting everything wastes cloud potential
2. Underestimating complexity: “Lift and shift” is never just copying files
3. Ignoring application dependencies: Missed dependencies cause outages
4. No cloud skills development: Team needs training before migration
5. Poor cost management: Unoptimized cloud costs exceed on-premise costs
6. Inadequate testing: Test disaster recovery and rollback procedures

Success Metrics

Technical Metrics:

• Application availability (target: 99.9%+)
• Deployment frequency (increase)
• Mean time to recovery (decrease)
• Infrastructure provisioning time (decrease)

Business Metrics:

• Total cost of ownership
• Developer productivity
• Time to market for features
• Customer satisfaction scores

Partner with Migration Experts

Cloud migration is complex and risky without experience. At Kawarezmi, we’ve migrated hundreds of applications to cloud:

Our Migration Services:

• Comprehensive application assessment
• Migration strategy development
• Proof of concept for complex applications
• Execution and cutover support
• Post-migration optimization
• Team training and knowledge transfer

We help you:

• Choose the right migration strategy for each application
• Minimize business disruption
• Achieve target cost savings
• Build cloud-native capabilities

Planning a cloud migration? Schedule a migration assessment with our team.

Strikethrough uses two tildes. Scratch this.

Link

I’m an inline-style link

I’m an inline-style link with title

I’m a reference-style link

I’m a relative reference to a repository file

You can use numbers for reference-style link definitions

Or leave it empty and use the link text itself.

URLs and URLs in angle brackets will automatically get turned into links. http://www.example.com or http://www.example.com and sometimes example.com (but not on Github, for example).

Some text to show that the reference links can follow later.

Paragraph

Lorem ipsum dolor sit amet consectetur adipisicing elit. Quam nihil enim maxime corporis cumque totam aliquid nam sint inventore optio modi neque laborum officiis necessitatibus, facilis placeat pariatur! Voluptatem, sed harum pariatur adipisci voluptates voluptatum cumque, porro sint minima similique magni perferendis fuga! Optio vel ipsum excepturi tempore reiciendis id quidem? Vel in, doloribus debitis nesciunt fugit sequi magnam accusantium modi neque quis, vitae velit, pariatur harum autem a! Velit impedit atque maiores animi possimus asperiores natus repellendus excepturi sint architecto eligendi non, omnis nihil. Facilis, doloremque illum. Fugit optio laborum minus debitis natus illo perspiciatis corporis voluptatum rerum laboriosam.

Ordered List

1. List item
2. List item
3. List item
4. List item
5. List item

Unordered List

• List item
• List item
• List item
• List item
• List item

Code and Syntax Highlighting

Inline code has back-ticks around it.

var s = "JavaScript syntax highlighting";
alert(s);

s = "Python syntax highlighting"
print s

Blockquote

This is a blockquote example.

Inline HTML

You can also use raw HTML in your Markdown, and it’ll mostly work pretty well.

Definition list

Is something people use sometimes.

Markdown in HTML

Does *not* work **very** well. Use HTML tags.

Tables

Colons can be used to align columns.

There must be at least 3 dashes separating each header cell. The outer pipes (|) are optional, and you don’t need to make the raw Markdown line up prettily. You can also use inline Markdown.

Image

Youtube video