An infrastructure migration moves servers, applications, data and networking from one environment to another: usually from an on-premises data center or colocation facility to AWS, Azure or Google Cloud. Done well, it unlocks managed services, elastic capacity and a smaller operations burden. Done badly, it moves the same problems to a more expensive place. This guide covers the phases, decisions and safeguards that make the difference.
Why Cloud Infrastructure Migration Matters
Legacy data centers struggle to keep up with demand spikes, hardware refresh cycles and the pace of new services. A planned cloud infrastructure migration shifts capital expenditure to operational expenditure, gives teams managed databases, analytics and security services, and lets capacity follow demand instead of a five-year hardware forecast. The benefits only arrive if the migration is planned around the applications, not just the servers.
The Four Phases of an IT Infrastructure Migration
| Phase | Goal | Key outputs |
|---|---|---|
| 1. Assess | Know exactly what you’re moving | Inventory, dependency map, migration pattern per application, cost estimate |
| 2. Prepare | Build a safe place to land | Landing zone: accounts, networking, identity, logging, guardrails |
| 3. Migrate | Move workloads in waves | Replication, testing, cutover runbooks, rollback plans |
| 4. Optimize | Make it cheaper and better than before | Right-sizing, commitments, managed-service adoption, monitoring |
Phase 1: Discovery and Dependency Mapping
The most common migration failure is discovering a dependency during cutover. Before choosing tools or dates:
- Inventory everything: servers, databases, storage, scheduled jobs, certificates, DNS records, firewall rules and third-party integrations.
- Map dependencies from real network traffic, not just documentation. Discovery tools in AWS Migration Hub, Azure Migrate and Google Cloud Migration Center can collect this automatically.
- Capture performance baselines (CPU, memory, IOPS, latency) so you can size targets correctly and prove the migration didn’t make things slower.
- Agree on downtime windows and compliance requirements with application owners early.
Group applications that depend on each other into the same migration wave so you aren’t running chatty systems across a hybrid link for months.
Choosing a Migration Pattern (The 6 R’s)
Not every workload should move the same way. Rehosting (“lift and shift”) moves an application as-is for speed, at the cost of leaving cloud-native efficiencies on the table. Replatforming makes targeted changes, such as swapping a self-managed database for a managed service, without a full rewrite. Refactoring rearchitects the application to be cloud-native, delivering the biggest long-term payoff for the highest short-term effort. Repurchasing replaces a system with a SaaS equivalent; retiring decommissions workloads nobody actually needs anymore; and retaining deliberately leaves something on-premises when migration isn’t worth the risk or cost. AWS’s migration strategy guidance adds a seventh, relocating, for moving whole virtualized environments such as VMware clusters without changing them.
| If the application is… | Usually choose |
|---|---|
| Stable, rarely changed, and needed quickly in the cloud | Rehost |
| Running on a database or middleware with a managed equivalent | Replatform |
| Core to the business and changing frequently | Refactor (often after an initial rehost) |
| A commodity function such as email, CRM or ticketing | Repurchase |
| Unused, or duplicated by another system | Retire |
| Tied to hardware, regulation or a contract end date | Retain for now |
Most real migrations use a mix across the portfolio, not one strategy applied uniformly.
Phase 2: Build the Landing Zone First
Before the first workload moves, set up the environment it will land in, defined as code (Terraform or the provider’s equivalent) so it’s repeatable and reviewable:
- Account or project structure separating production, non-production and shared services.
- Networking: address ranges that don’t overlap with on-premises, private subnets, and VPN or dedicated connectivity back to the data center for the hybrid period.
- Identity: single sign-on from your existing directory, least-privilege roles, and no long-lived access keys.
- Logging and guardrails: centralized audit logs, encryption defaults, budget alerts and policies that block the obvious mistakes, such as public storage buckets.
Phase 3: Migration Tooling and Data
Provider-native tools (AWS Application Migration Service, Azure Migrate, Google Cloud’s Migrate to Virtual Machines) handle much of the replication and cutover mechanics for rehost-style migrations, and are usually the fastest path for straightforward lift-and-shift work. For databases, continuous replication (AWS Database Migration Service, Azure Database Migration Service, or native replication) keeps the target in sync until cutover, so the final switch takes minutes instead of a long export and import. Complex refactoring efforts typically need custom tooling and a phased cutover plan rather than a single automated tool.
Cutover Runbook Checklist
- Lower DNS TTLs a few days before cutover so the switch propagates quickly.
- Freeze changes to the source system for the cutover window.
- Confirm replication lag is zero, then stop writes to the source.
- Run smoke tests and the agreed acceptance checks against the target.
- Switch DNS or load balancer targets, and watch error rates and latency against your baseline.
- Name one person who makes the go or no-go call, and define the rollback trigger in advance.
Plan for Rollback
Every migration plan needs an explicit rollback path for each phase, not just a hope that it won’t be needed. Keep the source environment running and in sync until the migrated workload has run cleanly in production for a defined burn-in period, and define in advance exactly what conditions would trigger a rollback decision rather than deciding under pressure during an incident.
A migration that ships on schedule but leaves the team unable to safely revert is a worse outcome than one that takes an extra sprint to get the rollback plan right.
Phase 4: Optimize After the Move
Lift-and-shift workloads are usually oversized, because they were sized for on-premises hardware. In the first 30 to 90 days after each wave, right-size instances using real utilization data, move steady workloads onto savings plans or committed-use discounts, turn off non-production environments outside working hours, and replace self-managed components with managed services where it pays off. Our guide to cloud cost optimization strategies covers this phase in detail.
Common Infrastructure Migration Mistakes
- Skipping dependency mapping and finding a hard-coded IP address or forgotten batch job during cutover.
- Migrating before the landing zone exists, then retrofitting security and networking under pressure.
- Treating the migration as finished at cutover and never optimizing, so the cloud bill ends up higher than the data center.
- Moving everything at once instead of in waves, with no way to learn from early moves.
- Decommissioning the source environment before the burn-in period ends.
Microsoft’s Cloud Adoption Framework and AWS’s prescriptive guidance both go deeper on running migrations at scale. If you’re planning a move to AWS or Google Cloud and want help with discovery, the landing zone or the cutover itself, our cloud computing services cover the full migration path.