Cloud migration is one of the most consequential infrastructure decisions a growing company makes — and one of the most frequently botched. The typical failure mode isn’t a dramatic outage during cutover. It’s a migration that takes 18 months instead of 6, costs 3x the estimate, and ends with a “cloud” deployment that’s really just the same monolith running on more expensive hardware.
This playbook is the framework we use for every cloud migration engagement. It covers assessment through post-migration optimization, with the specific patterns, decisions, and checkpoints that determine whether a migration succeeds or becomes a cautionary tale.
Before You Migrate: The Assessment
Every migration starts with the question most teams skip: should we migrate, and if so, what exactly should change?
Not every workload benefits from cloud migration. A stable, well-running application on a single dedicated server that costs $200/month and never needs to scale doesn’t necessarily benefit from a move to AWS. Migration has costs — engineering time, operational disruption, new tooling to learn — and those costs need to be justified by specific benefits.
The 5 Reasons That Actually Justify Migration
1. Scaling constraints. Your current infrastructure can’t handle traffic spikes, and adding capacity takes days or weeks instead of minutes. Cloud auto-scaling solves this — but only if your application architecture supports horizontal scaling.
2. Deployment bottleneck. Deploying to production requires maintenance windows, manual steps, and a prayer. Modern cloud infrastructure with CI/CD, containerization, and blue-green deployment can make deployments a boring, automated, zero-downtime event.
3. Cost optimization at scale. Counterintuitively, cloud can be cheaper than dedicated servers — but only when you use it correctly. Auto-scaling (paying for capacity only when you need it), spot instances, reserved capacity, and serverless computing can reduce costs for workloads with variable demand.
4. Security and compliance. Cloud providers offer compliance certifications (SOC 2, HIPAA, PCI DSS) at the infrastructure level that would cost hundreds of thousands to achieve independently. If compliance is a business requirement, the cloud’s shared responsibility model is a significant advantage.
5. Operational burden. Your team spends 20+ hours per week managing servers, applying patches, handling hardware failures, and managing backups. Cloud managed services eliminate this operational overhead, freeing engineering time for product work.
If none of these five apply to you, you may not need to migrate. Save the engineering effort for something that creates more value.
The Infrastructure Assessment
Before designing the target architecture, audit what you have:
Application inventory. Document every application, service, database, and scheduled job running in your current environment. For each: what it does, who uses it, how critical it is (can the business operate for 1 hour / 1 day / 1 week without it?), what it depends on, and what depends on it.
Data inventory. Map every database, file store, cache, queue, and data pipeline. Document sizes, growth rates, access patterns (read-heavy vs. write-heavy), and any data residency or compliance requirements.
Network and integration map. How do systems communicate? Internal APIs, database connections, file transfers, message queues, third-party integrations. This map determines the migration sequence — you can’t migrate a service that depends on a database that hasn’t moved yet.
Performance baselines. Before migration, measure current performance: response times, throughput, error rates, resource utilization. These become the benchmarks you compare against post-migration. Without baselines, you can’t prove the migration improved (or didn’t degrade) performance.
Choosing Your Migration Strategy
The 6 Rs (Refined for 2026)
The classic “6 Rs” framework still applies, but with updated guidance:
Rehost (“Lift and Shift”). Move the application to cloud infrastructure with minimal changes. Same code, same architecture, different hardware.
When it makes sense: Legacy applications that work fine but need to leave a data center. Applications where the business value doesn’t justify re-architecture investment. Quick wins to reduce data center footprint.
When it doesn’t: Applications that need to scale horizontally (lift-and-shift won’t fix a scaling problem if the architecture is the bottleneck). Monoliths that need to become microservices.
Replatform (“Lift and Optimize”). Move to cloud with targeted optimizations — swap the self-managed database for RDS, replace the custom caching layer with ElastiCache, shift from VM-based deployment to containers. The application logic stays the same; the infrastructure underneath improves.
When it makes sense: Most mid-market migrations. You get 80% of cloud benefits with 30% of the re-architecture effort. Typically the best ROI migration strategy.
Refactor/Re-architect. Redesign the application to be cloud-native — microservices, containers, serverless, event-driven architecture. The most expensive and time-consuming strategy, but produces the greatest long-term benefits.
When it makes sense: Applications that need fundamental scaling improvements. Systems where technical debt is so severe that replatforming would just move the problem. Strategic products that justify significant investment.
Our recommended approach for most mid-market companies: the strangler fig pattern — extract services incrementally from the monolith while it continues running. Each extracted service is cloud-native. Over time, the monolith shrinks until it’s decommissioned. This avoids the “18-month rewrite” risk while producing genuinely cloud-native architecture. We detail this approach in our zero-downtime migration case study.
Repurchase. Replace with a SaaS product. Your custom-built CRM becomes Salesforce. Your home-grown email system becomes SendGrid. Often the right choice for undifferentiated functionality.
Retire. Turn it off. Many companies discover during the assessment that 20–30% of their applications are unused, redundant, or no longer needed. Don’t migrate dead weight.
Retain. Keep it where it is. Some systems (legacy hardware integrations, systems approaching end-of-life, low-priority internal tools) aren’t worth migrating. Explicitly decide to retain them rather than discovering mid-migration that they can’t be moved.
Strategy Assignment Framework
For each application in your inventory, score on two axes:
Business criticality (1–5): How important is this application to daily business operations?
Migration complexity (1–5): How difficult is this to migrate (dependencies, data volume, architectural constraints, compliance requirements)?
| Low Complexity | High Complexity | |
|---|---|---|
| High Criticality | Replatform (quick cloud benefits, low risk) | Refactor with strangler fig (invest in doing it right) |
| Low Criticality | Rehost or Retire (minimize effort) | Retain or Repurchase (don’t over-invest) |
The Migration Sequence
Order matters. Migrating in the wrong sequence creates temporary integration nightmares — applications on two different infrastructures trying to communicate across networks they weren’t designed for.
Sequencing Principles
1. Migrate shared infrastructure first. DNS, monitoring, logging, CI/CD pipelines, secrets management. These need to exist in the cloud before any application moves.
2. Migrate databases before the applications that use them. Database replication from source to cloud can run in parallel with the existing application. Once the replica is caught up, the application cutover is a quick DNS or connection string change.
3. Migrate independent services before dependent ones. Applications with no downstream dependencies are the safest to move first. They’re also the best candidates for learning and building confidence in your migration process.
4. Migrate the monolith last (if using strangler fig). Extract services from the edges inward. The monolith shrinks as its responsibilities are moved to cloud-native services. The final cutover is smaller and less risky.
5. Never migrate everything at once. The “big bang” migration — shutting down the old environment and launching the new one over a weekend — is the highest-risk approach. Every migration we’ve done uses incremental cutover with rollback capability at every step.
Zero-Downtime Migration Techniques
Database Migration
Approach: Continuous replication with cutover.
- Set up a cloud database instance (RDS, Cloud SQL, or equivalent)
- Configure continuous replication from the source database to the cloud replica
- Let replication run until the replica is fully caught up (replication lag = 0)
- During a low-traffic window (not a maintenance window — the application stays up): switch the application’s database connection to the cloud replica
- Verify the application works correctly against the new database
- Keep the old database running for 48 hours as a rollback target
- Decommission the old database after the observation period
Replication lag monitoring is critical. If the replica falls behind, the cutover will lose transactions. Monitor continuously and only cut over when lag is consistently zero.
Application Migration
Approach: Traffic shifting with shadow and canary.
- Deploy the application in the cloud environment
- Shadow traffic: send a copy of production requests to the cloud deployment. Compare responses. Fix any discrepancies.
- Canary: route 1–5% of real traffic to the cloud deployment. Monitor error rates, latency, and functionality.
- Progressive shift: increase cloud traffic to 10% → 25% → 50% → 100% over 1–2 weeks
- At each step, monitor all metrics and be ready to route back to the old environment instantly
- After 100% traffic is on cloud and stable for 72+ hours, decommission the old deployment
This approach means zero downtime, full rollback capability at every step, and production-validated results before full cutover.
Cloud Provider Selection
The Big Three Compared
| Factor | AWS | GCP | Azure |
|---|---|---|---|
| Market share | ~31% (largest) | ~12% | ~24% |
| Service breadth | Most services (200+) | Fewer but high-quality | Extensive, Microsoft ecosystem |
| Best for | General purpose, broadest ecosystem | Data/ML workloads, Kubernetes | Microsoft shops, enterprise |
| Managed database | RDS, Aurora, DynamoDB | Cloud SQL, AlloyDB, Firestore | Azure SQL, Cosmos DB |
| Kubernetes | EKS | GKE (best managed K8s) | AKS |
| Serverless | Lambda (most mature) | Cloud Functions | Azure Functions |
| Pricing model | Complex but flexible | Simpler, sustained discounts | Complex, EA discounts |
| Documentation | Excellent | Good | Good |
Our default recommendation: AWS. Not because it’s objectively “best” — but because it has the largest ecosystem, the most third-party integrations, the deepest hiring pool of engineers who know it, and the most comprehensive documentation. For mid-market companies, these practical advantages outweigh GCP’s or Azure’s specific technical strengths.
Choose GCP when: You’re running heavy data/ML workloads, you want the best managed Kubernetes (GKE), or your team already has GCP experience.
Choose Azure when: Your organization is deeply invested in the Microsoft ecosystem (Active Directory, Office 365, .NET), or your enterprise clients require Azure for compliance.
Post-Migration: Optimization
Migration is not the finish line — it’s the starting line. The first 90 days after migration are when you capture the cost and performance benefits that justified the move.
Cost Optimization (Do This Immediately)
Right-sizing. Most teams migrate with oversized instances because they’re afraid of under-provisioning. After 2–4 weeks of production data, right-size every instance based on actual utilization. We typically find 30–40% cost savings from right-sizing alone.
Reserved instances / savings plans. For stable workloads, commit to 1-year reserved capacity for 30–40% savings over on-demand pricing. Only do this after 30+ days of production data confirms the workload is stable.
Auto-scaling configuration. Set up scaling policies based on actual traffic patterns. Scale up for peak hours, scale down for off-peak. This is the core cloud cost advantage — paying for capacity only when you need it.
Storage tiering. Move infrequently accessed data to cheaper storage classes (S3 Infrequent Access, Glacier). Implement lifecycle policies that automatically transition data based on age.
Operational Excellence
Monitoring and alerting. Deploy comprehensive monitoring before you need it: infrastructure metrics (CPU, memory, disk, network), application metrics (latency, error rates, throughput), business metrics (transactions processed, users active), and cost monitoring (daily spend tracking with anomaly alerts).
Infrastructure as Code discipline. Every cloud resource should be defined in Terraform, Pulumi, or CloudFormation. No manual console changes. This ensures reproducibility, audit trails, and the ability to recreate your entire environment from code.
Disaster recovery testing. Cloud makes disaster recovery achievable — but only if you test it. Schedule quarterly DR tests: simulate a region failure, verify your multi-AZ or multi-region failover works, and document recovery time.
The 6-Month Timeline
| Phase | Duration | Key Activities |
|---|---|---|
| Assessment | Weeks 1–3 | Application inventory, dependency mapping, performance baselines, strategy assignment |
| Foundation | Weeks 4–6 | Cloud account setup, networking (VPC, subnets, security groups), IaC foundation, CI/CD pipelines, monitoring stack |
| Database Migration | Weeks 7–10 | Replication setup, sync verification, cutover, validation |
| Application Migration (Wave 1) | Weeks 11–14 | Independent/low-risk applications, shadow testing, progressive cutover |
| Application Migration (Wave 2) | Weeks 15–20 | Dependent/high-risk applications, strangler fig extractions |
| Optimization | Weeks 21–24 | Right-sizing, reserved instances, auto-scaling, storage tiering, DR testing |
What This Costs
| Company Size | Infrastructure Complexity | Migration Investment | Timeline |
|---|---|---|---|
| Small (5–10 services, 1 database) | Low | $20,000–$50,000 | 6–10 weeks |
| Medium (10–25 services, 2–5 databases) | Medium | $50,000–$120,000 | 10–16 weeks |
| Large (25–50+ services, 5+ databases) | High | $100,000–$250,000 | 16–26 weeks |
These figures include our engineering time but not your cloud infrastructure costs (which typically decrease or stay neutral after migration).
Cloud Migration Playbook: Legacy to Cloud-Native in 6 Months
Start with an Infrastructure Assessment — we’ll audit your current environment, recommend the right migration strategy, and provide a specific timeline and budget estimate.