Why Most Cloud Migrations Stall
Cloud migrations fail for predictable reasons. Not because of AWS complexity. Not because of technical gaps. They fail because the discovery phase was rushed, the dependency mapping was incomplete, or the organisation treated migration as a purely technical project when it is fundamentally an operational change.
Here is the framework we use at GenClouds for every migration engagement — from the first assessment conversation to production go-live.
Phase 1: Discovery and Assessment (2-4 Weeks)
You cannot migrate what you cannot see. The discovery phase maps your existing estate with enough precision to make informed migration decisions.
We use AWS Application Discovery Service and, where necessary, direct agent-based discovery on-premise. The output is a complete inventory of:
- All servers, VMs, and containers with CPU, memory, storage, and network utilisation profiles
- All application dependencies — what talks to what, on which ports, with what traffic patterns
- All external integrations — APIs, partner systems, data feeds
- License implications — Windows Server, SQL Server, Oracle Database all have specific AWS licensing options that affect architecture decisions
The discovery output feeds directly into the Migration Readiness Assessment — a structured evaluation of technical, operational, and people readiness using the AWS Migration Readiness model.
Phase 2: Migration Strategy — The 6 Rs
Not every workload gets the same treatment. We categorise each application against the AWS 6 Rs:
- Rehost (Lift and Shift): Move to EC2 as-is. Fastest, lowest risk, limited optimisation. Right for applications with stable usage patterns and no immediate need for cloud-native features.
- Replatform: Move with minor optimisations — RDS instead of self-managed MySQL, ECS instead of self-managed containers. Meaningful operational improvements with moderate effort.
- Repurchase: Move to a SaaS equivalent — Salesforce, Workday, ServiceNow. Right when the application is not a differentiator.
- Refactor: Re-architect to be cloud-native — microservices, Lambda, ECS Fargate, event-driven. High effort, high long-term value. Right for core differentiating applications.
- Retain: Keep on-premise for now. Some workloads have compliance, latency, or licensing constraints that make migration premature.
- Retire: Decommission. Migrations are an opportunity to eliminate technical debt.
A typical enterprise estate breaks down roughly as: 60% Rehost, 20% Replatform, 10% Retire, 5% Refactor, 5% Retain/Repurchase. Your mileage will vary.
Phase 3: Landing Zone and Foundation (2-3 Weeks)
Before migrating a single workload, we establish the AWS landing zone — the organisational, networking, and security foundation that everything will run on.
This includes:
- AWS Organizations with a multi-account structure (Management, Log Archive, Security, Shared Services, per-environment workload accounts)
- AWS Control Tower for account vending and guardrails
- IAM Identity Center (SSO) for centralised access management
- VPC design: 3-AZ, separate subnets for public/private/data layers, Transit Gateway for inter-account connectivity
- Security baseline: GuardDuty, Security Hub, Config, CloudTrail enabled in all accounts and regions from day one
- Centralised logging: CloudWatch logs aggregated to the Log Archive account
This is the phase most clients underinvest in. A well-designed landing zone is 10-15% of the total migration effort and determines the operational quality of everything that follows.
Phase 4: Migration Factory (4-12 Weeks)
The migration factory model runs waves of migrations in parallel — typically 5-15 applications per wave — with a standardised process for each.
Each application goes through: Discovery → Design → Build → Test → Cutover → Validate. The standardisation means the team builds muscle memory and velocity increases with each wave.
We use AWS Application Migration Service (MGN) for Rehost migrations — it replicates the source server continuously and enables near-zero-downtime cutovers. For database migrations, AWS Database Migration Service handles the lift with minimal disruption.
Phase 5: Optimise and Modernise (Ongoing)
Migration is not the destination — it is the starting point. Once workloads are running on AWS, the optimisation work begins: rightsizing, Reserved Instance purchases, implementing auto-scaling, adding observability, and beginning the modernisation of key applications.
This is where the real business value of cloud is realised. The operational agility, the ability to scale on demand, the access to managed services that eliminate undifferentiated heavy lifting — these are the outcomes of a well-executed migration, not just the migration itself.
What Determines Success
In our experience, the migrations that succeed have three things in common: a committed internal champion (typically a CTO or VP Engineering), a clear scope and timeline with genuine executive sponsorship, and a migration team that includes both AWS expertise and deep knowledge of the existing environment.
If you are planning a migration or evaluating your options, start with a conversation. We offer a structured Migration Readiness Assessment that gives you a clear picture of where you stand and what a successful migration looks like for your specific environment.