Cloud Migration

Cloud migration moves a workload from its current environment to a cloud environment. The workload includes the application, data, infrastructure, dependencies, and operating practices that deliver a business outcome.

That definition is wider than copying servers. A server can arrive in the cloud while its identity, network, monitoring, recovery, or support model remains unfinished. The move succeeds only when the workload works at the target and the team can operate it there.

Migration is also a selection process. You might move a workload with few changes, change its platform, replace it, redesign it, keep it where it is, or retire it. The right outcome can be no migration at all.

Start with the reason

Define the business outcome before choosing a migration tool or cloud service. Common drivers include leaving a data center, reducing hardware work, improving recovery, reaching new locations, changing cost structure, or accelerating delivery.

Turn the driver into measurable acceptance criteria. Examples include:

A deadline for leaving a facility
Maximum allowed outage during cutover
Required transaction latency or throughput
Recovery time and recovery point objectives
Security and compliance controls
A cost range measured over a stated period
Operational readiness and ownership

A migration is not successful because a resource exists at the target. Success means the workload meets agreed business, technical, security, and operating criteria.

Discover the real workload

Build an inventory before you design the move. Record applications, servers, databases, files, networks, identities, certificates, scheduled jobs, interfaces, owners, and support contracts.

Then map dependencies. A web application might call an identity provider, share a database, write to a file store, send mail, and feed a reporting job. Moving only the visible application can break the complete service.

Capture a baseline for current demand and behavior. Measure utilization, transaction volume, latency, availability, recovery behavior, and cost. The baseline supports target sizing and gives you evidence for post-migration comparison.

Discovery is never perfect. Record unknowns as risks, assign owners, and test the assumptions that could change the migration plan.

Choose a strategy per workload

The 7 Rs provide a useful strategy vocabulary:

Retire: Decommission a workload that no longer provides enough value.
Retain: Keep a workload in its source environment for now.
Rehost: Move it with little or no application change.
Relocate: Move the existing platform to a cloud version or another cloud location without changing the workload architecture.
Repurchase: Replace the workload with another product, often software as a service.
Replatform: Make limited changes to use a different runtime or managed service.
Refactor or re-architect: Change the application architecture to use different cloud capabilities.

These strategies are choices, not maturity levels. Rehosting can meet a deadline with less change. Replatforming can remove specific operating tasks. Refactoring can address architectural limits, but it adds design, testing, and delivery work.

Do not assign one strategy to an entire portfolio. Select a strategy for each workload from its business value, constraints, dependencies, risk, deadline, and target operating model.

Prepare the destination

A landing zone is the prepared cloud environment where workloads arrive. It establishes shared foundations such as identity, account or subscription structure, network connectivity, security policy, logging, resource organization, and cost controls.

Prepare and test those foundations before production migration. Otherwise, each team invents a different access, network, and logging design during its cutover window.

The target design must cover the whole workload. Define compute, storage, data services, identity, secrets, connectivity, name resolution, observability, backup, recovery, deployment, and support ownership.

Cloud services change responsibility boundaries. A managed database can remove operating-system and database installation work. You still own data classification, access, configuration, recovery requirements, and correct application behavior.

Move in waves

A migration wave is a manageable group of workloads scheduled to move together. Build waves from dependency groups, business priorities, technical complexity, and team availability.

Start with a small, lower-risk wave that still represents real work. Use it to test the landing zone, tooling, runbooks, support handoff, and decision process. Apply what you learn to later waves.

Keep tightly coupled components in the same move group when a split would violate latency, consistency, or availability requirements. If a dependency must remain behind, design and test the temporary hybrid connection.

Every wave needs clear entry and exit criteria. Entry criteria can include completed assessment, approved target design, tested backup, synchronized data, and an accepted cutover plan. Exit criteria can include functional checks, performance checks, monitoring, security review, owner acceptance, and stable operation.

Design the cutover

Cutover redirects production use from the source workload to the target workload. It is a controlled change, not the whole migration.

A cutover runbook records ordered tasks, owners, timing, evidence, communication, and decision points. Typical tasks include:

Confirm people, tools, backups, and target health.
Freeze changes or source writes when consistency requires it.
Complete the final data synchronization.
Validate data and target services.
Change routing, name resolution, or load-balancer targets.
Run functional and nonfunctional checks.
Decide whether to continue, fix forward, or roll back.
Hand the workload to operations and begin close monitoring.

The data design determines much of the cutover risk. Define how you seed data, capture changes, validate completeness, and handle writes during the transition. A rollback after new target-side writes is harder than a rollback before any data changes.

Choose a planned-outage or near-zero-downtime approach from the workload's business requirements. Near-zero downtime usually requires continuous replication, controlled traffic movement, and more testing. It is not automatically the safer or cheaper option.

Make rollback executable

A rollback plan returns service to an agreed safe state when predefined failure criteria are met. State those criteria before cutover. Assign the person who can order the rollback.

The plan must account for data. Redirecting traffic back to the source can be simple when the target has accepted no new writes. After target-side writes, you may need reverse synchronization, reconciliation, or another recovery path.

Rehearse the runbook in a representative environment. Confirm task duration, permissions, monitoring, communication, and recovery steps. A document that nobody has executed is an assumption, not evidence.

Validate and stabilize

Validate more than reachability. Check business transactions, integrations, data integrity, performance, security controls, logging, alerts, backup, recovery, and operator access.

Keep migration and application teams available during a defined stabilization period. Compare target behavior with the baseline. Track incidents and unresolved risks. Do not decommission the source until rollback obligations have ended and the workload owner accepts the target.

Migration ends with a new operating state. Review cost, performance, reliability, security, and operational work after cutover. Rightsize resources, remove temporary connections, refine automation, update documentation, and capture lessons for the next wave.

Know the limits

Cloud migration does not automatically modernize an application. Rehosting can preserve the same architecture and operating problems in a new location.

Migration also does not guarantee lower cost, better security, higher availability, or easier operations. Those outcomes require a suitable target design, correct configuration, trained owners, and ongoing review.

Some workloads should remain where they are. Data-location rules, specialized hardware, latency, unsupported software, unresolved dependencies, sunk investment, or weak business value can justify retention. Retirement can create more value than moving an unused system.

Use the lasting sequence: define the outcome, discover the workload, choose a strategy, prepare the target, plan waves, rehearse cutover and rollback, validate, then optimize.