Infrastructure Discovery and Application Assessment

The first step is building an accurate inventory: which servers, applications, databases and services actually exist, what they depend on, and how they're currently configured. It's common for this inventory to surface systems nobody remembered were still running — those need a decision (migrate, retire, or replace) just as much as the well-documented systems do.

Each application should be assessed individually for migration approach: rehost (move as-is), replatform (move with minor changes, like switching to a managed database), or refactor (redesign for cloud-native patterns). Not every application deserves the same treatment — a legacy internal tool may be fine rehosted, while a core customer-facing service may justify refactoring.

Dependency Mapping

Applications rarely stand alone. Dependency mapping identifies which systems talk to which — shared databases, internal APIs, scheduled jobs, file shares — so that migration order can respect those relationships. Moving a system before something it depends on is a common and avoidable cause of migration incidents.

Migration Planning and Workload Classification

Once assessment and dependency mapping are done, workloads can be grouped into migration waves — typically starting with lower-risk, lower-dependency systems to validate the process, before moving business-critical systems. Each wave should have a defined rollback plan in case something doesn't go as expected.

Server, Database and Container Migration

Server migration typically means moving virtual machines to cloud compute instances, either through image-based migration tools or rebuilding from infrastructure as code. Database migration is usually the more delicate part — it requires a strategy for schema and data transfer, plus a plan for minimizing downtime, often using replication to keep the source and target in sync until cutover. Containerized applications are generally the most portable, since the container image already encapsulates the runtime environment.

Cloud-to-Cloud Migration

Migrating between cloud providers (or out of a data center that already uses cloud-like abstractions) adds a layer of translation: equivalent services rarely map one-to-one, so architecture may need adjustment rather than a direct lift. IAM models, networking constructs and managed service behavior all differ enough between providers that a cloud-to-cloud migration deserves the same assessment rigor as an on-premises migration.

Validation and Performance Testing

Before cutting production traffic over, migrated workloads should be validated functionally (does it behave the same way) and under realistic load (does it perform acceptably on the new infrastructure). Performance characteristics can shift meaningfully between environments — different storage latency, different network topology — so assumptions from the old environment should be re-verified rather than carried over.

Security Review

Migration is a natural point to review security posture rather than simply replicate old, possibly outdated configurations. That includes revisiting network segmentation, IAM permissions, encryption settings and exposed endpoints in the new environment, rather than assuming the old environment's security decisions were still correct.

Post-Migration Optimization

A migration is not complete the moment workloads are running in the new environment. Post-migration optimization — rightsizing instances based on actual observed usage, cleaning up temporary migration resources, and tuning autoscaling — is what turns "it's running in the cloud" into "it's running efficiently in the cloud."