Cloud Infrastructure Migration: A 6-Phase Playbook for Mid-Market Enterprises
Country Manager, India
AI, Manufacturing, DevOps, and Managed Services. 17+ years across Manufacturing, E-commerce, Retail, NBFC & Banking
Cloud Infrastructure Migration: A 6-Phase Playbook for Mid-Market Enterprises
Cloud migration projects fail less often than they used to, but the failures still happen for the same reasons: insufficient discovery, naive lift-and-shift assumptions, ignored data gravity, and underestimated cutover complexity. The 6-phase playbook below is the one we run on customer engagements, and the structure consistently produces predictable migrations within 6-18 month windows for mid-market enterprises (200-2,000 employees).
Phase 1: Discovery and Application Portfolio Assessment (Weeks 1-6)
The first phase produces an inventory and a classification of every application in scope. The deliverables:
- Application portfolio register — name, business owner, technical owner, technology stack, dependencies, criticality, regulatory class
- Infrastructure inventory — VMs, databases, storage, network paths, integrations
- Dependency map — runtime dependencies, data flows, shared services
- Migration disposition per application — Retire, Retain, Rehost, Replatform, Refactor, Repurchase (the 6 Rs)
The 6Rs framing is the standard categorisation. The practical proportions in mid-market migrations:
| Disposition | Typical share | What it means |
|---|---|---|
| Retire | 10-20% | Decommission instead of migrating — the application is unused or duplicated |
| Retain | 5-15% | Stay on-prem for now (regulatory, technical, or cost reasons) |
| Rehost ("lift and shift") | 30-50% | Move VMs as-is to cloud IaaS |
| Replatform | 15-30% | Minor changes to take advantage of cloud (e.g., move database to RDS) |
| Refactor | 5-15% | Significant re-architecture (e.g., monolith to microservices) |
| Repurchase | 5-15% | Replace with SaaS |
Phase 2: Landing Zone and Foundations (Weeks 4-10, parallel to discovery)
The landing zone is the cloud account / subscription / project structure plus the cross-cutting controls that every migrated workload will rely on. Building it before workloads land prevents the rework that comes from migrating into an unstructured environment.
Landing zone components:
- Account / subscription / project hierarchy with separation of dev / staging / prod and per-team scoping
- Network architecture — VPCs/VNets, transit gateways, on-prem connectivity (DX, ExpressRoute, Interconnect)
- Identity foundation — SSO via SAML/OIDC, role-based access control patterns, break-glass account management
- Security baseline — encryption defaults, logging to a centralised audit account, CSPM enrolled, guardrails via SCPs/Azure Policy/Org Policy
- Cost management — tagging policy, budget alerts, commitment management process
- Observability — centralised logging, metrics, and tracing destinations
For most customers we use AWS Control Tower / Azure Landing Zones / GCP Foundation Setup as the base and customise. Building landing zones from scratch without an opinionated baseline takes 3-4x longer for the same outcome.
Need expert help with cloud infrastructure migration?
Our cloud architects can help you with cloud infrastructure migration — from strategy to implementation. Book a free 30-minute advisory call with no obligation.
Phase 3: Wave Planning and Application Pilots (Weeks 10-14)
"Big bang" migrations fail. Wave-based migrations succeed. The plan groups applications into 3-8 waves of related workloads, with the early waves chosen for low risk and high learning value.
Wave-1 selection criteria:
- Non-critical applications — internal tools, dev environments, low-traffic services
- Limited integration surface — minimal cross-application dependencies
- Owners who can dedicate engineering time to the migration
- Clear "done" definition — the migration team needs an unambiguous success signal
Run 2-3 pilot applications through the full migration process before committing to the wave plan. The pilots reveal gaps in the landing zone, the runbooks, and the team's mental model that paper planning cannot surface.
Phase 4: Migration Execution (Weeks 12-44, depending on portfolio)
Wave execution is the longest phase. For each wave, the playbook:
- Detailed runbook per application — pre-cutover validation, cutover steps, rollback plan, post-cutover validation
- Engineering capacity allocation — typically 1-3 weeks per non-trivial application, parallelised across waves
- Migration tooling — AWS MGN, Azure Migrate, Google Migrate to Containers, or third-party (CloudEndure, Carbonite, Zerto)
- Cutover scheduling — usually weekend windows for production cutovers
- Post-cutover stabilisation — typically 1-2 weeks of close monitoring and quick fixes
The largest source of schedule slip is database migration, particularly for databases that need to migrate without downtime. Plan database migrations explicitly with replication tooling (DMS, Database Migration Service, ASR) and dual-write windows where the app design allows.
Phase 5: Optimisation (Weeks 28-52, overlapping with later waves)
Lift-and-shift migrations preserve cost inefficiencies. The optimisation phase converts the migrated workloads into something cloud-native enough to capture cloud's economic advantages.
Standard optimisation passes:
- Right-sizing — most lifted VMs are oversized 30-60% versus actual utilisation
- Storage tier reallocation — move infrequently-accessed data from EBS/Premium to S3/Blob
- Reserved / committed capacity — convert stable workload to 1-year or 3-year commitments
- Database modernisation — move to managed services (RDS, Cloud SQL, Azure Database) where viable
- Replatform candidates — applications identified during discovery as Replatform but deferred during execution
The optimisation phase typically delivers 25-40% cost reduction relative to the post-migration baseline. Without it, lift-and-shift migrations often cost more than the on-prem baseline they replaced.
Phase 6: Decommission and Operate (Weeks 50+)
The final phase covers on-prem decommissioning and the transition to steady-state cloud operations. The deliverables:
- On-prem decommission schedule with hardware lease releases and data centre exit
- Cloud operating model — who owns what, on-call rotations, runbooks, vendor contracts
- Cost governance — monthly cost review, quarterly architecture review, annual commitment renegotiation
- Skills transition — training, certifications, recruitment
The Three Migration Mistakes That Repeat
From migrations we have run or rescued, three patterns produce the most pain:
- Skipping discovery — every migration that started with "we know our portfolio" found out at week 6 that they didn't. Discovery is non-negotiable
- Migrating before optimising landing zone — workloads that land in an immature landing zone get migrated again later, doubling the work
- No post-migration optimisation — the cost case for migration assumes optimisation; without it, the case fails
How Opsio Helps
Opsio runs cloud migrations end-to-end as part of how Opsio delivers cloud infrastructure engagements. Specialised migrations — aws migration for enterprise, Opsio's azure migration, end-to-end gcp migration — apply this 6-phase playbook with provider-specific tooling and accreditations. Post-migration we typically transition customers to cloud managed delivery for steady-state operation.
For hands-on delivery, see datadog monitoring delivery.
For hands-on delivery, see managed cloud scalability.
For hands-on delivery, see aws cloud migration services.
For hands-on delivery, see how Opsio delivers cloud migration.
For hands-on delivery, see cloud migration services.
For hands-on delivery in India, see cloud migration delivery.
About the Author
Country Manager, India
Praveena leads Opsio's India operations, bringing 17+ years of cross-industry experience spanning AI, manufacturing, DevOps, and managed services. She drives cloud transformation initiatives across manufacturing, e-commerce, retail, NBFC & banking, and IT services — connecting global cloud expertise with local market understanding.
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.