Most enterprise cloud migrations do not fail on technology. They fail because the organization starts moving workloads before it understands what it owns, why it is moving, and what “done” looks like. Servers get lifted into the cloud, the bill doubles, and a year later the data center is still running. This playbook is the disciplined alternative: assess, plan, move, operate — as an organizational program, not a series of technical moves.

What cloud migration really involves

Cloud migration is moving applications, data, and infrastructure from on-premises environments (or one cloud to another) into a target cloud platform, then operating them there. The definition matters because organizations confuse the move with the objective. The objective is almost never “be in the cloud” — it is exiting a data center, improving resilience and scalability, enabling faster delivery, or building the elastic foundation that capabilities such as AI require.

The most expensive failure mode is a migration with no business case beyond itself. Before any assessment begins, answer a blunt question: what changes because we moved? A data center lease expiring in eighteen months is an obvious driver. If no justification can be articulated, deferring migration is a legitimate decision, not a failure of ambition.

Discovery and portfolio assessment

You cannot plan a migration without an inventory. The portfolio assessment produces a defensible, complete picture of the application estate: what exists, what it does, who owns it, what it depends on, and how it behaves. Most organizations find this step surprising, because the inventory is never as clean as assumed. Expect to discover applications nobody owns, servers running workloads nobody recognizes, and dependencies documented nowhere.

Building the inventory

A working inventory captures, per application and per infrastructure component:

Ownership: the business owner and technical team. Applications without an owner are retirement candidates or future migration emergencies.
Technical profile: languages, frameworks, middleware, databases, operating systems — commercial or custom-built.
Infrastructure footprint: servers, storage, network, and licensing constraints, especially license terms that restrict where software may run.
Traffic and criticality: usage patterns, peaks, and real recovery objectives. Many applications claim four nines of availability nobody will pay for.
Dependencies: upstream and downstream systems, integration mechanisms, shared databases, batch schedules, surrounding human processes.

Automated discovery tooling helps, but the inventory is fundamentally a research exercise: interviews, configuration databases, and actual traffic analysis. A configuration database unmaintained for three years is a rumor, not a source of truth.

Dependency mapping

Migrations break on dependencies: the application that moves cleanly while its downstream partner still expects it on the corporate network, the batch job referencing a database that moved, the single-sign-on integration tied to a network address. Dependency mapping identifies move groups — applications and infrastructure that must migrate together because splitting them would break communication, data consistency, or security. The unit of migration planning is the move group, not the application.

The business case per workload

Not every application deserves to move. For each move group, record the expected value: cost reduction, risk reduction, agility gain, or deadline pressure. Workloads with no positive case are retained or retired. An assessment concluding that everything should move did not actually assess.

The 6 Rs decision framework

The industry-standard framework for migration decisions is the 6 Rs. For each move group, exactly one applies:

Rehost (“lift and shift”): move the workload to the cloud with minimal changes — virtual machines become cloud virtual machines, databases become managed database instances of the same type. Fast, low risk, and low initial cost — but it captures almost none of the cloud’s economic benefits and often increases operating cost because cloud infrastructure is priced per unit consumed rather than per cabinet owned.
Replatform (“lift, tinker, and shift”): make targeted changes during the move — switch to a managed database service, move containerizable workloads onto containers, adopt cloud-native load balancing. Modest additional effort over rehosting, with meaningful operational savings from managed services.
Repurchase (“drop and shop”): replace the workload with a cloud-native or SaaS alternative — migrate from a self-hosted email system to a SaaS provider, from a licensed database to a managed cloud offering. Eliminates the operational burden entirely but requires data migration, integration rework, and change management.
Refactor (“re-architect”): rebuild the workload to take advantage of cloud-native capabilities — break a monolith into services, adopt serverless for spiky workloads, redesign for elasticity. The highest effort and the highest potential return, but the effort is easily underestimated and the timeline is the least predictable.
Retain (“revisit”): leave the workload where it is. The right answer for workloads with no migration business case, regulatory constraints that bind them to specific infrastructure, or systems scheduled for decommissioning whose migration cost would exceed their remaining life.
Retire: decommission the workload. The assessment phase should produce a meaningful list of these — duplicate systems, applications with no remaining users, infrastructure kept running “just in case.” Retirements are the cheapest migration outcome.

Trade-offs in practice

The honest distribution for a typical portfolio: a large share rehosted or replatformed, a meaningful minority repurchased, a few refactored, and a non-trivial share retained or retired. Programs planning to refactor everything are planning a multi-year redevelopment program under the name “migration” — the funding, staffing, and governance are different, and the plan should say so. Also weigh coupling: refactoring a workload while its dependencies stay in the data center creates latency and security complications. Rehosting is often the correct first step even for workloads that will eventually be refactored — it exits the data center on schedule, and refactoring happens later in the cloud, where managed services make it easier.

Landing zone design

The landing zone is the foundational cloud environment into which everything migrates: the account structure, networking, identity integration, security baselines, and operational tooling. It must exist — designed, built, and hardened — before the first production workload moves. Skipping it leaves applications in an account configured like a developer sandbox, and the remediation afterward exceeds the cost of doing it properly first.

Account structure

A single cloud account is not an enterprise architecture. The standard pattern is multi-account: a management account for billing and governance, shared-services accounts for centralized tooling, and separate workload accounts per business unit, tier, or portfolio. Account boundaries are the cloud’s strongest isolation mechanism — billing, blast radius, and access control all follow the account lines. Designing this up front is far cheaper than splitting one account later.

Networking

The network design defines how the cloud connects to what remains on-premises and how cloud resources communicate with each other. The core decisions:

Connectivity: dedicated private links versus VPN tunnels, based on bandwidth, latency, and reliability. Hybrid connectivity is almost always needed during the transition and often persists after it.
Segmentation: virtual networks per account or tier, with routing that prevents unintended lateral movement and reflects the organization’s security zones.
Address space: plan IP addressing early — overlapping ranges between on-premises and cloud networks are a classic blocker, discovered late and painful to fix.
DNS and traffic flow: name resolution across environments, outbound filtering, and where inspection happens.

Identity and access

Cloud identity must integrate with the existing identity provider: centralized single sign-on for the console, roles mapped to job functions rather than individuals, and service-to-service authentication. Define the standard roles before workload teams start requesting administrative access “temporarily.”

Guardrails from day one

The landing zone should ship with policy enforcement active: approved regions and services, required encryption, mandatory cost-attribution tags, logging requirements. Policy-as-code evaluated at deployment time keeps it compliant by construction — that is what makes it an enterprise environment rather than a collection of cloud accounts.

Migration waves and the factory model

With the inventory complete and the landing zone built, migration proceeds in waves: grouped move groups on a schedule, each wave informing the next.

Wave planning

Waves are sequenced by risk and learning value. The first wave is deliberately small and representative: a handful of move groups exercising the landing zone, migration tooling, cutover process, and operating model. This pilot exposes the gaps — missing firewall rules, unhandled dependencies, procedures that do not work — far cheaper with five applications than fifty. Later waves grow in size as the process becomes routine; critical, complex, tightly coupled systems move last, when the team has the most experience. Workloads with hard external deadlines anchor the schedule.

The factory model

Once the first waves validate the approach, migration becomes a factory: a repeatable process with defined stages — assess, mobilize, migrate, validate, cut over, decommission — executed by teams with clear roles. The value is in the repetition: standardized runbooks, predictable timelines per workload class, a team that gets faster with each wave. The factory needs clear intake: which move groups are in which wave, who owns each application’s migration, the acceptance criteria, and who signs off. Migration without ownership tracking is how applications get moved and abandoned.

Cutover strategies and rollback planning

Cutover is when production traffic shifts to the cloud. Three strategies cover the practical options:

Big-bang: traffic switches at a defined moment. Simplest to execute and reason about; the blast radius is the entire workload. Fits smaller systems, natural low-traffic windows, and cases where parallel operation is impractical.
Phased: traffic shifts incrementally — a user subset, region, or function at a time. Smaller blast radius per step, validated under real load before full commitment. The cost is complexity: the system must tolerate split-brain operation during the phase-in.
Parallel run: both environments serve production (or the new shadows the old) for a defined period, outputs compared before retirement. Most expensive and most rigorous — the right choice where correctness failures are costly, such as financial processing or regulatory reporting.

Rollback planning

Every cutover plan needs a defined, tested rollback: trigger conditions (error rate thresholds, latency budgets, data-integrity checks), the procedure (DNS change, traffic shift, database reversion), and the decision authority — who can call it at 3 AM. Rehearse it; do not just document it. Rollbacks are hardest at the data layer: rolling back application servers is a traffic shift, but rolling back a database that has accepted writes in the new environment is a data reconciliation problem — the part organizations most often neglect.

Cutover readiness

Before any production cutover: performance-test at realistic load in the target environment, review the cloud security configuration, test backup and restore, update runbooks for the cloud operating model, schedule trained on-call staff, and brief stakeholders on the window and communication plan. Cutovers fail more often on operational readiness than on technology.

Data migration specifics

Data is where the laws of physics apply: applications move quickly, data moves at the speed of bandwidth, and its volume and sensitivity shape the entire plan. The core decisions per dataset: online replication with a final cutover versus offline bulk transfer; the transfer mechanism (network, physical transfer devices for very large datasets, provider-to-provider paths); and the consistency model during transition. Online replication keeps the source running but requires handling the delta — changes between the initial copy and cutover. Offline transfer is simpler but needs downtime proportional to data volume. Validation deserves its own workstream: row counts, checksums, schema verification, application-level spot checks. “The copy completed” is not evidence the data is correct.

Two categories need special attention. Regulated data may have residency and handling requirements constraining where it travels and how it is encrypted in transit — the compliance review happens before the transfer plan, not after. Shared databases are a dependency problem in data form: the database moves once, and every consuming application must be ready or be given a compatibility path.

Operating after the move

Migration ends when the last workload is cut over and the old infrastructure is decommissioned. But the program’s value is determined by what happens next: whether the organization operates the cloud estate well or simply runs its data center with cloud pricing.

The operating model shift

Cloud operations differ from data-center operations: infrastructure is provisioned by API rather than procurement, changes land in minutes rather than weeks, and the bill arrives monthly as a variable cost rather than annually as a capital budget. Teams need infrastructure-as-code skills, cloud-native monitoring, and cost awareness as a daily practice. Runbooks — incident response, backup and recovery, patching — must be rewritten for the cloud.

Cost control

The most common post-migration surprise is the bill. Without the physical constraint of purchased hardware, consumption expands: over-provisioned instances, storage accumulating without lifecycle rules, idle development environments, unmodeled data transfer costs. Cost control is an operating discipline: tagged resources for attribution, budgets and alerts per account, recurring rightsizing, and committed-use pricing once usage patterns stabilize. Treat cost management as a migration workstream from the start — tagging standards in the landing zone, cost review in wave retrospectives. For the full discipline, see our cloud cost optimization guide.

Decommissioning

The migration is not complete until the old environment is gone. Decommissioning is routinely deferred — “we’ll turn it off next quarter” — which means paying for two environments indefinitely. Include decommissioning criteria and dates from the start, and track retirement with the same rigor as cutovers.

Continuous improvement

A migrated estate is a starting point, not an end state. Review rehosted workloads for replatforming opportunities, replace self-managed components with managed services where the economics favor it, and evolve toward the cloud-native patterns deferred during the move. See our platform engineering guide for the target operating model, and our legacy modernization playbook for the application-level work that typically follows.

Putting it into practice

Cloud migration rewards the organizations that treat it as a program: a complete inventory, honest 6 Rs decisions, a landing zone built before the first workload moves, wave-based execution, cutovers with real rollback plans, and an operating model — cost discipline and decommissioning included — defined from the start. The technology is the least risky part; the planning is where migrations are won or lost.

For organizations planning a migration — scoping the assessment, designing the landing zone, sequencing the waves, or building the post-move operating model — structured advisory support keeps the program honest and on schedule. Arihant Global Ventures Inc. provides technology advisory and delivery engagements for exactly these questions: migration strategy, landing zone architecture, and the enterprise architecture work that makes the move stick. See our capabilities for what we do, our engagements for how we work, or contact us to start the conversation.

Cloud Migration Playbook: Assess, Plan, Move, Operate