Cloud Migration: From Planning to Production in 90 Days

Cloud migrations fail for predictable reasons: unclear scope, big-bang cutovers, and nobody owning cost after the move. A 90-day plan is realistic for a small-to-mid-sized estate if you split the work into phases and migrate in waves.

Days 1–15: Assess

Before moving anything, build an inventory.

• Every application, database, scheduled job and integration
• Who owns each one and how critical it is
• Current performance, peak load and data volumes
• Compliance requirements and where data is allowed to live
• What the current setup actually costs, including licenses and people time

Then decide a strategy per workload. The common options are rehost (move as-is), replatform (move with small changes, such as switching to a managed database), refactor (rebuild for cloud-native services), replace with SaaS, or retire. Most estates end up with a mix, and retiring things is the cheapest migration there is.

Days 15–30: Design the landing zone

The landing zone is the foundation everything else sits on. Define it as code from the start, usually with Terraform.

• Account or project structure for production, staging and development
• Networking: VPCs, subnets, private connectivity and DNS
• Identity: single sign-on, roles and least-privilege access
• Logging, monitoring and alerting
• Backup policies and encryption defaults
• Budgets and cost allocation tags

Getting this right first means every migrated workload inherits good security and visibility automatically.

Days 30–75: Migrate in waves

Group workloads into waves of increasing risk. Start with something low-stakes, such as an internal tool, to prove the process.

For each workload:

1. Build the target environment from code
2. Set up data replication from the old system
3. Run both environments in parallel and compare results
4. Cut over during a quiet period with a tested rollback plan
5. Watch closely for a few days before decommissioning the old system

Databases deserve the most care. Use replication or change-data-capture so the final cutover is a short sync, not a long copy.

Days 75–90: Optimize and hand over

Right after migration is when cost and performance are easiest to fix.

• Right-size instances based on real usage, not on the old hardware
• Turn on autoscaling where load varies
• Use commitment discounts for steady baseline load
• Remove idle resources, unattached disks and old snapshots
• Document runbooks and hand on-call ownership to a named team

Common mistakes

• Lift-and-shift everything. Moving inefficient systems unchanged often costs more than before.
• No owner for cost. Without budgets and tags, spend drifts upward quietly.
• Skipping the parallel run. It feels slow, but it is what makes zero-downtime cutovers possible.
• Treating security as a later phase. Retrofitting access controls is much harder than building them into the landing zone.

Next step

A short assessment usually shows which workloads to move first and roughly what the target will cost. If you want a second pair of eyes, book an infrastructure review.