A Step-by-Step Cloud Migration Roadmap (with Checklists)

Migrations don’t fail at cutover, they fail in the sequencing decisions made months earlier. This roadmap is the sequence that works: five phases, each with an exit checklist you can actually verify before moving to the next.

The five phases at a glance

Phase	Core question	Typical duration	Exit artifact
1. Assess	What do we actually have?	2-6 weeks	Complete inventory + dependency map
2. Plan	Where does each thing go, and in what order?	3-8 weeks	Strategy per app, landing zone design, wave schedule, budget
3. Pilot	Does our process survive contact with reality?	2-4 weeks	One workload live in production, runbook corrected
4. Migrate	Execute the waves	Weeks-months	Everything moved or consciously retained
5. Optimize	Stop overpaying; run it well	Ongoing	Right-sized, committed, monitored estate

Phases 1-3 feel slow when a deadline looms. They are where the schedule is actually won: every hour of assessment saves a multiple of it in wave 3 when an undocumented dependency would otherwise take down two applications at 2 a.m.

Phase 1, Assess: inventory before opinions

You cannot plan a cloud migration from tribal knowledge. Every environment contains servers nobody remembers, dependencies nobody documented, and utilization far below what anyone believes.

Run discovery tooling, not surveys. AWS Application Discovery Service, Azure Migrate’s appliance, or an agentless scanner will map servers, installed software, network connections between machines, and actual CPU/RAM/disk utilization over 2-4 weeks of observation. The utilization data matters twice: it feeds right-sizing (most on-prem servers run under 20% CPU) and it exposes the dead apps you’ll retire.

Map dependencies explicitly. The network-connection data tells you which applications talk to each other. Apps that chat constantly must move in the same wave, or you’ll pay latency and egress fees for traffic that used to cross a rack and now crosses the internet.

Score each application on business value and technical fit, this feeds the strategy assignment in the 6 Rs playbook.

Assess-phase checklist:

• Discovery tooling deployed; 2+ weeks of utilization data collected
• Every server accounted for, owner, purpose, environment (prod/dev/test)
• Dependency map generated from observed network traffic, then reviewed by app owners
• Data volumes measured per application (this drives transfer timelines later)
• Compliance and data-residency constraints listed per app
• Candidate retire list drafted (no logins/traffic in 90 days)
• Business-value + technical-fit score recorded per application

Phase 2, Plan: strategy, landing zone, waves, money

Four planning outputs, all of them written down:

1. A strategy per application. Assign one of the 6 Rs to every item in the inventory. Retire decisions execute immediately, they need no cloud.

2. A landing zone. Before the first workload arrives, you need the destination built: account/subscription structure, a VPC and network design (IP ranges that don’t collide with on-prem, a painful thing to fix later), identity integration, centralized logging, and guardrails. This is its own project; our landing zone guide covers it, and the shared responsibility model explains which security controls are yours to build here.

3. A wave schedule. Group applications into waves of 5-15, ordered by: dependency clusters move together; lower-risk apps go early (the team is still learning); revenue-critical apps go late (the process is proven by then); and anything with a hard external date (lease expiry, license renewal) anchors the calendar.

4. A budget with both numbers. Migration cost (labor, tooling, parallel-running both environments for the overlap months, commonly 20-40% of one year’s infrastructure spend) and target run cost. Estimate run cost from measured utilization, not current server specs, here’s how. Expect the first post-migration bills to run high until optimization lands; say so up front and nobody panics.

Plan-phase checklist:

• Every application has an assigned R and a named owner
• Provider selected with reasons documented (or multi-provider split justified, rare for SMBs)
• Landing zone designed: accounts, network/IP plan, identity, logging, guardrails
• Wave schedule published with dependency groupings visible
• Migration budget and target run-rate approved
• Rollback criteria defined per wave (“we revert if X”)
• Success metrics agreed (cutover downtime budget, performance baselines, cost targets)

Phase 3, Pilot: one real workload, end to end

The pilot is where your runbook meets reality, at a stake you can afford. Choose a workload that is genuinely production, real users, real data, but survivable: an internal tool, a reporting system, a secondary web app. A static marketing site proves nothing; your CRM is too much to risk.

Run the pilot as a full dress rehearsal: replicate the data, stand up the app in the landing zone, test, cut over inside a defined window, verify, and, importantly, rehearse the rollback even though you won’t need it. Time every step. The pilot almost always surfaces the same categories of surprise: a firewall rule nobody documented, a hardcoded IP address, a DNS TTL set to 24 hours, a backup job pointing at the old environment.

Pilot-phase checklist:

• Pilot workload migrated and serving production traffic
• Actual cutover time measured vs. the runbook estimate
• Rollback procedure executed at least once (in rehearsal)
• Every surprise written into the runbook as a check for future waves
• Monitoring and backups confirmed working in the new environment
• Go/no-go review held: does the wave schedule still look right?

Phase 4, Migrate: execute in waves

Now the repeatable part. Each wave follows the same rhythm:

1. Prepare (week 1-2): provision target infrastructure from templates, start data replication (block-level for rehosts via MGN/Azure Migrate; database-level via DMS or native replication, see migrating a production database).
2. Validate: test the applications against replicated data in the target. Functional checks, performance against baseline, integration points.
3. Cut over: inside the agreed window. For most internal apps a scheduled evening window is fine; for customer-facing systems that can’t blink, use the zero-downtime patterns, replication plus DNS/traffic shifting.
4. Stabilize (1-2 weeks): hypercare, elevated monitoring, fast response, old environment kept warm as the rollback path.
5. Retro: 30 minutes, honest, feeding corrections into the next wave. Wave 4 should be dramatically smoother than wave 1; if it isn’t, the retros aren’t working.

Per-wave checklist:

• Replication running and lag verified before the cutover window
• Cutover runbook rehearsed; roles assigned (who flips DNS, who watches dashboards, who decides rollback)
• Rollback tested and time-boxed (“decide within 45 minutes”)
• Post-cutover validation script run and passed
• Old environment decommission scheduled, not immediate, not never (2-4 weeks is typical)

That last item deserves emphasis: the migration isn’t done until the old servers are off. Every month both environments run, you pay twice. Decommissioning discipline is where projected savings become real ones.

Phase 5, Optimize: the phase that pays for the project

Thirty days after each wave, real usage data exists. Three loops, run continuously:

• Right-size. Compare provisioned vs. used. Rehosted estates routinely shed 25-40% of compute cost here by downsizing instances and adding autoscaling where load varies.
• Commit. Once the footprint is stable, buy reserved instances or savings plans on the steady-state baseline, 30-60% below on-demand. Don’t buy commitments before right-sizing, or you’ll lock in the waste.
• Harden operations. Cost anomaly alerts, backup restore tests (not just backup jobs), patching automation, and a monthly cost review with a named owner. Bill shock is a process failure, not a pricing one.

FAQ

How long does a cloud migration take?

A small portfolio (5-15 applications) typically takes 3-6 months from assessment to final cutover. Mid-size portfolios (20-60 apps) run 6-12 months, and large or compliance-heavy estates 12-24 months. The biggest schedule variables are dependency complexity, data volume, and how much time the team can protect from day-job interruptions.

What is the first step in a cloud migration?

Inventory. Before choosing providers or strategies, run discovery tooling (AWS Application Discovery Service, Azure Migrate, or an agentless scanner) to get a complete list of servers, applications, dependencies, and actual utilization. Every downstream decision, strategy, sizing, cost estimate, wave order, is built on this list.

Should we migrate everything at once or in waves?

In waves, almost always. Big-bang migrations concentrate all risk into one weekend and give the team no chance to learn. Waves of 5-15 applications, grouped by dependency (apps that talk to each other move together), let each wave apply lessons from the last. The exception is very small estates, where a single cutover weekend can be simpler.

What is a migration pilot and what should we pick?

A pilot is one production workload moved end to end before the main waves, proving your tooling, runbook, network path, and rollback under real conditions. Pick something real enough to matter but survivable if it goes badly: an internal tool with a forgiving user base, a reporting system, or a well-understood web app. Not your revenue system, and not a toy static site that proves nothing.

What does the optimize phase actually involve?

Three recurring loops: right-sizing (match instance sizes to measured utilization, typically a 25-40% saving on rehosted estates), commitment purchases (reserved instances or savings plans on the steady-state footprint, 30-60% off on-demand rates), and operational hardening (alerting, backup testing, patching automation, cost anomaly alerts). It starts about 30 days after each wave lands, once usage data is real.

---

If you’re somewhere between phase 1 and a deadline, you don’t have to sequence this alone. Talk to a Webisoft cloud engineer, we’ll review your inventory and wave plan, or build them with you, and tell you honestly where the risks are hiding.