The cloud migration horror story is now a genre. The team that moved everything to AWS in a weekend and spent the next three months fixing intermittent outages. The database migration that ran at 10% of expected speed and extended a two-week project to four months. The infrastructure bill that was three times the estimate because nobody modelled egress costs. The on-premise system that turned out to have fourteen undocumented integrations discovered only after the cutover.
These stories are not inevitable — they are the predictable result of specific, avoidable decisions. According to Flexera's State of the Cloud Report, 60% of cloud migrations run over budget, and over-schedule rates are similar. But the organisations that migrate successfully share a common pattern: they treat migration as an architecture project, not a hosting change.
This article presents a practical framework for IT directors and engineering leads planning a cloud migration — covering the failure modes, the 6-R decision framework for each workload, and a pre-migration assessment checklist you can use before the first line of migration code is written.
Why Cloud Migrations Fail: The Three Root Causes
Root Cause 1: The Lift-and-Shift Trap
The fastest way to move to the cloud is to take your existing servers and run them as virtual machines in a cloud data centre. This approach — called "lift and shift" or rehosting — is also the most common source of disappointment. The system works, but the cloud bill is similar to the on-premise cost (sometimes higher), and the team has gained none of the cloud-native advantages: auto-scaling, managed databases, serverless execution, or pay-per-use economics. Lift-and-shift is sometimes the right answer for a first migration phase — but only when it is a deliberate stepping stone to re-architecture, not the final destination.
Root Cause 2: Underestimating Data Migration
Moving application code to the cloud is comparatively straightforward. Moving years of production data — with referential integrity, zero data loss, and minimal downtime — is where migrations most commonly run over schedule. Common traps include: database schema differences between on-premise and cloud-managed database services, network bandwidth bottlenecks when transferring hundreds of gigabytes, time zone and encoding issues surfaced only when real data runs through the migrated system, and legacy binary data formats that require transformation as part of the migration.
Root Cause 3: No Rollback Plan
Every migration has a cutover moment — the point at which live traffic switches from on-premise to cloud. Teams that have not defined their rollback procedure before cutover day discover, under pressure, that rolling back is either technically impossible or would take longer than fixing forward. Define and test the rollback procedure before the migration begins. A documented, tested rollback plan is not pessimism — it is the thing that allows you to cut over confidently, because you know you can recover if something unexpected happens.
The 6-R Framework: Choosing the Right Migration Strategy
Not every workload should be migrated the same way. The 6-R framework — originally developed by Gartner and widely adopted by AWS — provides a decision model for categorising each application in your portfolio before migration begins. Applying it systematically to your workload inventory is the single most high-value activity in migration planning.
The 6-R Migration Strategies
Rehost — Lift and Shift
Move the application to cloud infrastructure without changes. Use when: the application needs to migrate quickly (compliance deadline, data centre lease expiry), or as a first phase before planned re-architecture. Best for: legacy monoliths with complex dependencies, applications with no internal engineering ownership. Risk: no cloud economics benefit until further refactoring.
Replatform — Lift, Tinker and Shift
Make a small number of targeted optimisations during migration — switching from a self-managed database to a cloud-managed service (RDS, Cloud SQL), or moving from a self-managed message queue to a managed one (SQS, Pub/Sub). Achieves meaningful operational savings with moderate effort. Use when: the application has clear operational pain points that a managed service directly solves, but a full re-architecture is not justified by the ROI.
Refactor — Re-architect
Significantly modify or rewrite parts of the application to take full advantage of cloud-native capabilities: breaking a monolith into services, implementing auto-scaling, adopting serverless execution for appropriate components, or rebuilding the data layer on a cloud-native database. Use when: the application is a core business system with high traffic variability, or where the current architecture is actively limiting business capability. Highest effort, highest long-term return.
Re-purchase — Move to SaaS
Replace the on-premise application with a cloud-based SaaS alternative. Use when: the application is commodity software (CRM, HR, ERP) that a specialist vendor operates more efficiently than your team. This is often the fastest path to cloud for non-differentiating business systems. Challenge: data migration from the old system and process change management for end users.
Retire — Decommission
Identify applications that are no longer needed and retire them during the migration window. Typically 10–20% of a typical enterprise application portfolio can be decommissioned on audit — they exist because nobody took ownership of shutting them down. Retiring these applications reduces migration scope, infrastructure cost and ongoing security surface area.
Retain — Leave On-Premise (For Now)
Intentionally leave specific workloads on-premise — typically because they have regulatory requirements that prevent cloud hosting, hardware dependencies (specialised processing cards, sensors), or they are scheduled for replacement within 12 months and migration investment is not justified. Every retained workload should have a documented review date.
Pre-Migration Assessment Checklist
Before the first line of migration code is written, this checklist should be completed for your migration portfolio. Teams that skip this step spend the migration discovering things they should have known at the planning stage.
Barquecon Cloud Migration Assessment
- Application inventory: Do we have a complete list of all applications, services and databases in scope? Have we documented their dependencies on each other — including undocumented runtime dependencies discovered through network traffic analysis?
- 6-R classification: Has each workload been assigned a migration strategy (Rehost/Replatform/Refactor/Re-purchase/Retire/Retain)? Are these decisions documented and agreed by the application owners?
- Data volumes: Have we measured the total data volume for each database? Have we calculated the transfer time at available network bandwidth and confirmed this is within the maintenance window or planned cutover period?
- Data sensitivity: Have we identified which data stores contain personal data, financial data or regulated information? Have we confirmed the cloud hosting arrangement meets the applicable compliance requirements (GDPR, RBI, HIPAA where relevant)?
- Integration map: Do we have a documented map of all integrations — third-party APIs, internal service calls, batch file exchanges, event queues — that will be affected by the migration?
- Cost model: Have we modelled the target cloud infrastructure cost at expected production load — including compute, storage, data transfer (egress), managed service costs, and support tier?
- Performance baseline: Do we have documented performance metrics for critical user journeys in the on-premise system? These are the benchmarks against which the migrated system will be validated.
- Rollback procedure: Have we documented and tested the rollback procedure for each workload? Can we return to on-premise within a defined recovery time if the migration encounters a critical issue post-cutover?
- Cutover window: Have we agreed the cutover window with business stakeholders — including acceptable downtime duration and the communication plan if downtime exceeds expectation?
- Post-migration monitoring: Do we have cloud-native monitoring configured before cutover — not as a post-launch task? Are alerts defined for the performance thresholds that matter to the business?
Sequencing: The Order That Minimises Risk
The most common sequencing mistake is starting with the most complex or most critical system, because stakeholders want to demonstrate immediate value. The sequencing that works is the opposite: start with the least critical, best-understood workloads.
Phase 1 — Low-risk candidates first. Start with internally-used applications, low-traffic services, or systems that are already partially cloud-dependent. These build team confidence, surface infrastructure problems at low stakes, and establish the monitoring and deployment patterns you will use for more critical migrations.
Phase 2 — Retire and re-purchase. Complete the Retire decisions to reduce scope. Complete the Re-purchase (SaaS replacement) decisions to clear non-core systems from the migration backlog. Both reduce the complexity of subsequent phases.
Phase 3 — Core workloads with Rehost or Replatform. Migrate your core business systems using the most conservative strategy justified by their architecture. If the plan is to Refactor later, Rehost now and refactor after the system is stable in the cloud — not during the migration.
Phase 4 — Refactor for cloud economics. Once systems are stable in the cloud, apply targeted re-architecture to the workloads where cloud-native capabilities deliver the most business value. This phase is continuous, not a one-time event — cloud-native modernisation is an ongoing engineering practice, not a project with an end date.
"A cloud migration is not a destination — it is the beginning of a different way of operating infrastructure. The organisations that treat it as a project miss the ongoing discipline that makes cloud economics work."
— Barquecon Research Team
The pre-migration assessment checklist and the 6-R classification process are not bureaucracy — they are the work that makes the migration itself straightforward. Every item on the checklist that is skipped during planning becomes a discovery during execution, at three times the cost and under production pressure.
