Cloud Migration Strategy

Moving an application to the cloud without modifying its architecture. Fast and low-risk but leaves cloud-native optimisation for later.

"Phase 1 is a pure rehost — we move all 40 VMs as-is to get out of the datacenter before the lease expires. Re-architecture comes in Phase 2."

Migrating an application with minor cloud-native modifications — such as switching from self-managed MySQL to RDS — without changing the core architecture.

"We're replatforming the database tier to RDS — same application code, same schema, but managed backups, patching, and Multi-AZ failover."

Redesigning an application to fully leverage cloud-native capabilities — such as decomposing a monolith into microservices or replacing a cron job with serverless functions.

"The order processing monolith is a refactor candidate — we'll break it into event-driven microservices in the second phase of the migration."

Replacing an existing application with a SaaS equivalent. The most common example is moving from an on-prem CRM to Salesforce.

"We're repurchasing our HR system — the legacy on-prem product is end-of-life and Workday covers all our requirements natively."

Decommissioning applications that are no longer needed. Discovered during application portfolio assessment when usage data shows a system has no active users.

"Portfolio analysis found 30% of our application estate is retire-eligible — these 80 systems have had fewer than 5 logins in the past 12 months."

Deliberately keeping an application on-premises — for regulatory reasons, latency requirements, or because the migration cost outweighs the benefit.

"The trading system is a retain — sub-millisecond latency requirements and regulatory data residency constraints mean it stays in our co-location facility."

A structured inventory and analysis of all applications in an organisation — identifying dependencies, usage, technical debt, and the appropriate migration strategy (6Rs) for each.

"The portfolio assessment took 6 weeks and catalogued 340 applications. We categorised 40% as rehost, 25% retire, 20% replatform, and 15% refactor."

An evaluation of an organisation's readiness to migrate to cloud across dimensions including operating model, security, talent, governance, and financial management.

"The MRA revealed we need 3 months of skills training before the migration starts — our operations team has no experience with Infrastructure as Code."

A pre-configured, secure, multi-account cloud environment that serves as a foundation for all workloads. Establishes baseline security controls, networking, identity, and governance guardrails.

"The landing zone is set up before any workloads migrate — it defines the account structure, VPC design, and security guardrails that all teams must use."

A batch of applications migrated together in a single iteration. Applications are grouped by dependency, risk level, or business unit to minimise downtime and coordination complexity.

"Wave 1 contains 15 low-risk, stateless applications. Wave 2 migrates the database tier once Wave 1 is stable. Production traffic follows in Wave 3."

The planned maintenance window during which live traffic is switched from the source environment to the cloud target. A narrow, scheduled period of acceptable downtime.

"The cutover window is Saturday 02:00–04:00 UTC — the only 2-hour window in the month where transaction volume is low enough to accept downtime."

Running the source and target environments simultaneously, processing the same transactions through both, and comparing outputs to validate the migration before cutover.

"We ran both systems in parallel for 2 weeks — every order was processed by the legacy system and the migrated system. Output discrepancy rate fell below 0.01% before we cut over."

A documented procedure to revert to the source environment if the migration fails. Defines the trigger conditions (error rate thresholds, revenue impact) and step-by-step reversal actions.

"The rollback plan is pre-approved and rehearsed. If error rate exceeds 5% for 10 minutes post-cutover, we switch DNS back to the legacy environment — target RTO for rollback is 8 minutes."

A standardised, repeatable operating model for executing migrations at scale — combining tooling, automation, runbooks, and a dedicated team to process many applications through the same pipeline.

"The migration factory processes 15 applications per sprint. Each application moves through the same discovery → test → pilot → cutover → validation pipeline with automated tooling."

The post-migration intensive monitoring period — typically 2–4 weeks — during which additional operational support is provided to rapidly detect and resolve issues in the newly migrated environment.

"All migrated applications enter a 3-week hypercare period. The migration team remains on call alongside the normal operations team until we're confident in the new environment's stability."