Cloud Architecture Migration

Cloud Migration Patterns

The 6 Rs framework for categorising migration approaches, wave planning, Strangler Fig modernisation, database migration with DMS, and risk mitigation strategies for large-scale cloud migrations.

⏱ 12 min read

What it is

The 6 Rs framework (originated by Gartner, popularised by AWS) categorises every application in a migration portfolio into one of six strategic dispositions: Retire (decommission — the application is no longer needed), Retain (keep on-premises — too risky or complex to migrate in the current window), Rehost ("lift and shift" — move to cloud VMs/containers with minimal changes), Replatform ("lift, tinker, and shift" — make targeted optimisations like moving to RDS or Elastic Beanstalk without re-architecting), Refactor/Re-architect (redesign for cloud-native capabilities — microservices, serverless, managed services), and Repurchase (replace with SaaS — move a CRM from self-hosted to Salesforce). Each disposition has a different cost, risk, and timeline profile.

In practice, a portfolio of 200 applications typically distributes as: 5–10% Retire, 20–30% Retain, 40–50% Rehost, 10–20% Replatform, 5–15% Refactor, and 5–10% Repurchase. The Rehost bucket provides the fastest path to cloud with the lowest risk and enables cost optimisation (Reserved Instances, rightsizing) before deeper modernisation. The Refactor bucket delivers the highest long-term value but requires the most engineering investment. A phased strategy — Rehost to move fast, then Replatform and Refactor over subsequent quarters — is more effective than attempting Refactor-everything in a single programme.

Why it exists

Data centre consolidation deadlines, hardware end-of-life events, and lease expirations drive migration urgency. Organisations cannot refactor every application before the data centre contract ends. The 6 Rs framework enables rational prioritisation: identify which applications can be lifted-and-shifted in 2 weeks vs which require 6 months of re-architecture, then sequence the work to exit the data centre on time while minimising business disruption. Without this framework, migration projects either stall (trying to modernise everything at once) or create technical debt (rehosting everything without a post-migration modernisation plan).

Database migration is the highest-risk component of most migrations. AWS Database Migration Service (DMS) enables continuous replication from the source database to the target AWS database, allowing a prolonged parallel-run period where both systems are active, then a minimal-downtime cutover (update the connection string, validate, retire the source). AWS Schema Conversion Tool (SCT) automates conversion of Oracle or SQL Server DDL and stored procedures to Aurora PostgreSQL or MySQL-compatible SQL, accelerating heterogeneous database migrations. Understanding DMS and SCT capabilities before beginning is critical for estimating migration complexity and timeline.

When to use

  • Rehost: Applications with a hard migration deadline, low current cloud investment, or legacy applications running stably on-premises that the team does not want to touch during migration.
  • Replatform: Applications where a specific bottleneck can be addressed with a managed service swap (Oracle → RDS, self-hosted Redis → ElastiCache) without re-architecting the application logic.
  • Refactor: Applications identified as strategic investments where cloud-native capabilities will deliver measurable business value (scalability, reliability, development velocity) and the team has capacity for the re-architecture work.
  • Repurchase: Commodity software (email servers, HR systems, CRM) where the operational burden of self-hosting exceeds the customisation value; SaaS replacements eliminate the migration problem entirely.
  • Strangler Fig: When a monolith must be incrementally modernised to microservices without a big-bang rewrite; route specific feature traffic to the new service while the monolith handles the rest, gradually strangling it.

When not to use

  • Refactor under time pressure: Attempting to refactor a monolith into microservices within the same deadline as the data centre exit is a common failure mode; separate the migration timeline from the modernisation timeline.
  • Rehost without a post-migration plan: "We'll optimise once we're in the cloud" without a specific timeline and owner consistently results in rehosted VMs running for 3+ years with no cloud optimisation, higher costs than on-premises, and no business value realised.
  • Strangler Fig for stateless services: If the monolith component being extracted has no shared state dependencies, a full extraction (not strangler) is simpler and faster; Strangler Fig is for stateful components with shared data concerns.

Typical architecture

6 Rs Decision Tree
─────────────────────────────────────────────────────────
  Application assessed in migration portfolio
        │
  Is it still used? No → RETIRE
        │
  Can it be migrated in this programme? No → RETAIN
        │
  Is there a SaaS replacement that covers 80%+ needs? Yes → REPURCHASE
        │
  Will architecture remain the same?
        ├─ Yes, exact lift → REHOST
        ├─ Yes, with managed service swap → REPLATFORM
        └─ No, redesign needed → REFACTOR

DMS Migration Flow (Database)
─────────────────────────────────────────────────────────
  On-premises Oracle (source)
        │
  DMS Replication Instance
  [Full Load → then CDC (Change Data Capture)]
        │
  Aurora PostgreSQL (target)
        │
  Parallel run: both DBs active, app writes to both
        │
  Validation: row count, checksum comparison
        │
  Cutover: update connection string, stop DMS task
        │
  Decommission source Oracle

Strangler Fig (incremental modernisation)
─────────────────────────────────────────────────────────
  Phase 1:  all traffic → Monolith
  Phase 2:  /api/orders → New Orders Service; rest → Monolith
  Phase 3:  /api/orders, /api/payments → new services
  Phase N:  Monolith fully decomposed → decommission

Pros and cons

Pros

  • Rehost delivers rapid data centre exit — a skilled cloud engineer can rehost 5–10 servers per week using automated tools (AWS Application Migration Service).
  • DMS continuous replication enables near-zero-downtime database migration with a prolonged parallel-run validation period before cutover.
  • Strangler Fig allows incremental modernisation with rollback capability at each step — much lower risk than big-bang rewrites.
  • AWS Migration Hub tracks migration progress across all accounts and services, providing a single pane of glass for programme management.
  • Post-rehost, Reserved Instance purchasing delivers immediate 30–40% cost savings before any optimisation work begins.

Cons

  • Rehost of poorly sized on-premises VMs often results in over-provisioned cloud instances that cost more than necessary — rightsizing must follow rehost.
  • DMS homogeneous migrations (Oracle→Aurora) require SCT for stored procedures and triggers; complex PL/SQL cannot be automatically converted and requires manual rewrite.
  • Migration waves that don't respect application dependencies cause integration failures post-migration; discovery and dependency mapping are underestimated.
  • Strangler Fig proxy layer adds latency and becomes a complexity bottleneck when many teams need to route traffic through it simultaneously.
  • Cloud costs during migration are temporarily elevated — old data centre plus new cloud infrastructure run in parallel; migration budget must include this overlap period.

Implementation notes

Begin with a migration assessment using AWS Migration Hub and the AWS Application Discovery Service (ADS) to automatically discover on-premises servers, their utilization data, and inter-server network dependencies. ADS agents run on each server and report to Migration Hub, which builds a dependency graph. Use this dependency map to define migration waves — groups of applications that have no external dependencies on applications in a later wave. Wave 1 should be the simplest, lowest-risk applications (internal tools, dev environments) to build team confidence and refine the migration runbook before tackling mission-critical systems. The final wave (Wave N) should contain the most complex, highest-risk applications after the team has executed 5–10 earlier waves.

For database migrations, run DMS in Full Load + CDC mode and keep the parallel-run period for at least 72 hours before cutover. During parallel run, validate row counts, run business-logic validation queries that compare results between source and target, and verify that CDC is keeping up with replication lag. Use DMS CloudWatch metrics (CDCLatencySource and CDCLatencyTarget) to verify replication lag is under 5 seconds before scheduling the cutover. For heterogeneous migrations, use SCT's Assessment Report to quantify the percentage of code that can be automatically converted versus what requires manual intervention — this is the most reliable estimate of migration complexity.

Common failure modes

  • Dependency mapping skipped: Application A is migrated in Wave 1 but it calls Application B's internal API which is still on-premises; post-migration latency increases dramatically and some calls fail; always run ADS before wave planning.
  • DMS large table full load timing out: A 500 GB table with no partitioning takes 20+ hours for full load; DMS replication instance is undersized; pre-split large tables and right-size the DMS replication instance for throughput.
  • Stored procedure conversion underestimated: SCT reports 30% manual conversion required; team discovers 600 stored procedures at 30% = 180 complex procedures to rewrite manually; this is a 6-month project, not a 6-week one.
  • No rollback plan: Migration proceeds with the on-premises system decommissioned before cloud validation is complete; issues are discovered post-cutover with no way to roll back; always keep the source system running for 2–4 weeks post-cutover before decommissioning.
  • Licensing surprise: SQL Server or Oracle licenses are not included in the rehost cost model; BYOL vs License Included pricing on RDS is a significant cost difference; engage AWS licensing specialists before migrating commercial database workloads.

Decision checklist

  • Has application discovery and dependency mapping been completed using ADS or equivalent tooling before defining migration waves?
  • Has each application been assigned an R-disposition (Retire/Retain/Rehost/Replatform/Refactor/Repurchase) with justification?
  • For database migrations, has a DMS assessment been run and the percentage of manual conversion quantified?
  • Does each wave have a documented rollback plan that keeps the source system running for at least 2 weeks post-cutover?
  • Has the parallel-run cost (dual infrastructure for migration overlap period) been included in the migration budget?
  • Is there a post-migration optimisation backlog (rightsizing, Reserved Instances, Replatform) with an owner and timeline?

Example use cases

  • Data centre exit programme: 150-server estate assessed with ADS; 12 servers retired, 20 retained, 95 rehosted using AWS MGN in 8 waves over 6 months, 15 replatformed to RDS/ECS, 8 refactored to serverless; data centre contract exited on time; post-migration optimisation programme delivers 35% cost reduction over following 12 months.
  • Oracle to Aurora migration: 2 TB Oracle database with 400 stored procedures; SCT converts 70% automatically, 120 procedures manually rewritten over 8 weeks; DMS CDC replication runs for 2 weeks parallel; cutover in 4-hour maintenance window; Oracle licensing eliminated saving $180K/year.
  • Monolith strangling: 8-year-old PHP monolith; new orders microservice (Go + Aurora) deployed behind API Gateway; Route rewrites at nginx layer redirect /api/v2/orders to new service; remaining monolith handles auth, inventory, reporting; 2 engineers modernising one domain per quarter without touching the monolith core.

Further reading