The 6 Rs of Cloud Migration

Rehost is a legitimate strategy when applied deliberately — the problem is using it as the default without analysis.

When Rehost makes sense:
• Time-to-cloud pressure — data centre contract expiry, hardware failure, compliance deadline
• Short-lived applications — planned decommission within 18–24 months; no point refactoring
• Dependencies on other migrating apps — must move together but can't refactor simultaneously
• Risk aversion — critical systems where the team lacks confidence to refactor safely

When Rehost is inappropriate:
• Application will remain in production for 5+ years → cloud costs without cloud benefits
• Application has significant horizontal scaling requirements → auto-scaling requires refactoring
• Application runs on end-of-life OS not supported in cloud → replatform or refactor is required

The "lift-and-shift trap":
Teams that rehost everything quickly discover:
• Cloud bills are higher than expected — on-prem servers were provisioned for peak; cloud instances run continuously
• No elasticity — you pay for the same compute 24/7 that you could have auto-scaled
• Operations complexity unchanged — you still manage patching, OS, everything

Best practice: Rehost as a temporary step with a committed date to evaluate and modernise. Document it in the migration record: "Rehosted as wave 2 expedient; review for replatform/refactor by Q4."

Key vocabulary:
• Rehost — move VM to cloud with minimal changes; also called lift-and-shift
• Lift-and-shift trap — the mistake of rehosting without modernisation, incurring cloud costs with no cloud benefits
• Post-migration modernisation plan — the committed path from rehost to a cloud-native target state

Replatform is the "sweet spot" strategy — but only when the bottleneck is infrastructure, not code.

What Replatform looks like in practice:
• Self-managed MySQL → Amazon RDS / Azure Database for MySQL (managed, automated backups, patching)
• Self-managed Redis → ElastiCache / Azure Cache for Redis
• On-premises app server → containerized + ECS/App Service (no code change, just packaging)
• VM-based batch jobs → AWS Batch or Azure Batch

When Replatform is the right call:
• Healthy codebase well-tested, maintainable, few tech debt risks
• Infrastructure bottleneck — the team spends more time managing database servers than writing features
• No horizontal scaling need — moderate, predictable traffic patterns
• Limited time/budget for full refactor but need to reduce operational toil

When to choose Refactor/Rearchitect instead:
• Monolith with tight coupling — scaling one feature requires scaling everything
• Traffic patterns require elastic, zero-to-scale compute (serverless, containers on Kubernetes)
• The codebase has significant tech debt that makes replatforming risky
• Competitive differentiation requires features only possible with a cloud-native architecture (ML services, event streaming)

In architecture discussions:
> "For the reporting service, I'd replatform — swap the self-managed Postgres for RDS, containerize the app, no code changes. For the real-time pricing engine, we need to refactor — the monolith can't scale the hot path without architectural change."

Key vocabulary:
• Replatform — move with targeted optimisations (managed services, containerisation) but no code rewrite
• Refactor/Rearchitect — redesign the application to exploit cloud-native capabilities
• Operational toil — recurring manual work (patching, restores) that managed services eliminate
• Horizontal scaling — adding more instances of an application to handle load (requires stateless architecture)

Repurchase (Replace) is often the right strategic choice but carries hidden complexity that must be assessed before committing.

The four Repurchase risk areas:

1. Data migration:
• Years of custom schema must map to the SaaS data model
• Data quality issues surface during migration (duplicates, inconsistent formats)
• Historical data may not all be importable — how much history do you need in the new system?

2. Integration re-engineering:
• Every internal system that integrated with the old CRM API must connect to the new SaaS API
• Integration inventory is often larger than expected — billing, ERP, support tools, analytics
• Timeline and cost often dominated by integration work, not the CRM itself

3. Custom business logic:
• Complex pricing rules, workflows, approval hierarchies embedded in the custom system
• SaaS platforms have limited customisation floors — "can the product configure to our process, or do we change our process to fit the product?"
• Decisions: replicate in SaaS low-code customisation, build an external service, or accept changed process

4. TCO at scale:
• Salesforce, ServiceNow, SAP SaaS: per-seat pricing can be very high at 500+ users
• Run a proper 5-year TCO comparison: current on-premises all-in cost vs. SaaS licences + integration + migration cost

When Repurchase is clearly correct:
• Custom system has high maintenance cost and low strategic differentiation
• The SaaS product has a rich ecosystem (integrations, partner apps)
• The team lacks skills to maintain and evolve the current system

Key vocabulary:
• Repurchase (Replace) — retiring the current system in favour of a SaaS or packaged alternative
• Drop-and-shop — informal term for Repurchase; drop the old, shop for the new
• Integration inventory — the full list of systems that connect to the application being replaced
• Vendor lock-in — dependency on a specific vendor's proprietary features, API, or data model

Retire and Retain are not failures — they are active strategic decisions that reduce cost and complexity.

Retire — the underused strategy:
• Typical discovery: 10–20% of enterprise application portfolios are unused or duplicated
• Common candidates: shadow IT apps nobody maintains, applications replaced by newer systems but never switched off, BI reports nobody has run in two years
• Impact: zero migration cost, zero future cloud cost, reduced attack surface, reduced compliance scope
• How to find them: usage analytics, interview application owners, check last login dates

In planning discussions:
> "The discovery scan found 47 applications. After stakeholder interviews, 11 are candidates for retirement — nobody has accessed them in 18 months and the business owner confirmed they're obsolete. We retire those before wave 1 starts."

Retain — the principled pause:
• Valid reasons to Retain on-premises:
— Application is already being replaced in 12 months by a new system (not worth migrating)
— Genuine data sovereignty requirements (government health data, EU financial data requiring specific jurisdictional control)
— Dependency on hardware peripherals or local network requirements that can't be virtualised
— Application is so deeply integrated with on-premises systems that migration is blocked until those systems also migrate

Retain ≠ "we'll do it later forever":
A Retain decision should have a review date. Every retained application should be reassessed in the next migration wave planning cycle.

The business case for Retire + Retain:
> "By retiring 11 applications and retaining 8, we've reduced our active migration scope from 47 to 28 applications — a 40% reduction in migration project cost."

Key vocabulary:
• Retire (Decommission) — shut down applications that are no longer needed; frees up migration capacity and reduces cloud spend
• Retain — keep on-premises intentionally; must have a documented reason and review date
• Shadow IT — applications deployed without central IT oversight, often discovered during portfolio assessment
• Data residency — a legal/regulatory requirement that data must physically remain in a specific geography

Refactor and Rearchitect sit on a spectrum of transformation depth — both require a business case.

Spectrum of the "Re-" strategies:

Strategy	Code change	Architecture change	Risk
Rehost	None	None	Low
Replatform	Minimal (config, packaging)	Small (managed services swap)	Medium-low
Refactor	Significant (cloud-native patterns)	Moderate (Lambda, DynamoDB swap)	Medium
Rearchitect	Extensive (new domains, APIs)	Fundamental (microservices, event-driven)	High

Business case for Refactor (Lambda + DynamoDB example):
• Cost: Lambda charges per invocation + duration. A payment service processing 1M transactions/month at 200ms each might cost $40/month vs. $300/month for a 24/7 EC2 instance.
• Operational overhead: no OS patching, no server management, automatic scaling
• Scaling: DynamoDB scales to millions of requests/second with no capacity management
• Risk: business logic preserved; integration points unchanged

Framing Refactor vs. Rewrite:
> "This is not a rewrite — the payment calculation logic stays exactly the same. We're changing how it's deployed and what infrastructure it relies on. The function signatures, the business rules, the tests — all carry over."

Key vocabulary:
• Refactor — adapt code to use cloud-native services while preserving business logic
• Rearchitect — fundamentally restructure the application design (monolith to microservices)
• Serverless — compute model where you pay per execution, not per running instance
• Cloud-native pattern — an architectural approach designed to leverage cloud capabilities (auto-scaling, managed services, event-driven)