Migration playbook: escaping lock-in without disruption

Migration projects fail in a predictable sequence. The technical work gets scoped. The timeline gets set. The engineering team starts moving workloads. Somewhere in the middle, dependencies surface that weren't in the original assessment, the double-run period extends beyond the budget allocated for it, and the project either stalls or completes at significantly higher cost than planned.

Industry research consistently puts the majority of cloud migration initiatives over budget, with inadequate assessment cited as the primary cause. The Flexera 2026 State of the Cloud Report puts the root cause in sharper focus: “Understanding application dependencies” is ranked as the single biggest migration challenge across all respondents (54%), cited ahead of technical feasibility (44%), cost assessment (43%), and post-migration optimization (39%). Dependencies that surface during execution rather than assessment are the most common source of delays.

That reframes what a migration playbook needs to be. Most guides lead with tooling and sequencing. This one leads with the decisions that have to be made before any workload moves, because those are the decisions that determine whether the project succeeds.

Phase 1: assess before you commit

Key takeaway: A migration failure is a planning failure that hasn't happened yet. The dependency mapping, workload categorization, and ownership decisions made in the assessment phase determine almost everything that follows.

The assessment phase has one purpose: to establish a clear, honest picture of what you're moving, what it depends on, what it will cost to move, and who is accountable for each decision. Organizations that compress this phase to accelerate the start of technical work consistently find that the time saved in planning is paid back with interest during execution.

The assessment work breaks into three areas:

Workload inventory and categorization 
Before any migration decision is made, every workload in scope needs to be categorized against the 6 Rs framework, the industry-standard classification used across Gartner and Accenture migration frameworks:

• Retire: Workloads that are no longer actively used or justified. Typically 10 to 20% of an enterprise estate falls into this category. The cheapest workload to migrate is the one you turn off, and identifying retirements early generates immediate cost savings that fund the rest of the migration.
• Rehost: Lift-and-shift workloads with minimal dependencies and no requirement for provider-specific services. These move fastest and with least risk.
• Replatform: Workloads that need minor modifications to run efficiently in a new environment but don't require a full rebuild.
• Refactor: Workloads that need significant rearchitecting to run portably, typically those built on proprietary provider services with no direct equivalent elsewhere.
• Retain: Workloads that stay on the current provider for regulatory, technical, or contractual reasons during the migration window.
• Renegotiate: Workloads where the primary action is commercial rather than technical, renegotiating terms with the existing provider using demonstrated portability as leverage.

The categorization exercise will surface the workloads that drive the most migration complexity: the ones built on proprietary services that have no clean equivalent on the target provider. These are not reasons to abandon the migration; these are reasons to sequence it correctly.

Dependency mapping
For each workload, document what it depends on: other services, data stores, networking configurations, authentication systems, and whether those dependencies create a sequencing constraint. Workloads with complex dependency chains cannot move independently; they move as groups. Discovering this during execution rather than assessment is one of the most common sources of migration delay, and one of the most avoidable.

Ownership assignment
Every workload in scope needs a named owner who is accountable for the migration decision, the cutover criteria, and the rollback plan. The absence of defined ownership is one of the primary reasons migration projects stall. Ownership doesn't mean the owner does the technical work. It means they are accountable for the outcome and have the authority to make the trade-off decisions the migration may require.

Phase 2: sequence by risk, not by speed

Key takeaway: Migration sequencing should be driven by risk profile and dependency complexity, not by which workloads are easiest to move. Moving the wrong workload first creates downstream constraints that are expensive to resolve.

The sequencing instinct in most migration projects is to start with quick wins: low-complexity workloads that can be moved fast and demonstrate progress. This instinct is partially right. Early wins build internal confidence and demonstrate that the migration approach works. But sequencing purely for speed creates a specific problem: it leaves the high-complexity, high-dependency workloads until last, when budget pressure is highest and tolerance for delay is lowest.

A risk-based sequencing model works differently:

Start with retirements
Before any workload moves, retire the ones that shouldn't move at all. This reduces the scope of the migration, generates immediate savings from eliminated cloud spend, and simplifies the dependency map for everything that follows. According to the Flexera 2026 State of the Cloud Report. This figure that ticked upward this year for the first time in five years, driven by growing cost complexity from AI and new services

Move isolated workloads early (rehost)
Lift-and-shift migrations with minimal dependencies validate the migration process, build team capability, and demonstrate progress to stakeholders without creating downstream complexity. These are the appropriate early wins.

Sequence refactor workloads by dependency, not complexity
The workloads that require rearchitecting should be sequenced based on what depends on them, not how hard they are to move. A heavily-depended-on service that requires refactoring needs to move before the workloads that depend on it, even if it would be easier to move those dependents first.

Plan retains and renegotiations in parallel
Workloads that stay on the current provider during the migration window don't require technical work, but they do require commercial decisions. Use the migration period to renegotiate terms on retained workloads with demonstrated portability as leverage. The credible ability to move is valuable even when you choose not to exercise it.

Take the multicloud assessment.

Phase 3: define cutover criteria before the double-run starts

Key takeaway: The double-run period, when workloads operate on both the source and target environments simultaneously, is a financial liability, not a safety net. Every day without defined cutover criteria is a day of unnecessary spend.

The most consistently underestimated cost in migration projects is the parallel operation period. Running workloads on two environments simultaneously is expensive, and the cost scales directly with how long the double-run continues. Organizations that enter the double-run period without defined cutover criteria, the specific measurable conditions that must be met before the source environment is decommissioned, routinely find that the period extends far beyond the original estimate.

Cutover criteria need to be defined before the double-run starts, not during it. They should specify:

Performance parity thresholds

What performance metrics must the target environment meet before the source is decommissioned? Define these as specific, measurable values rather than qualitative assessments.

Data integrity verification

What checks confirm that data in the target environment is complete, accurate, and consistent with the source? Who is responsible for running these checks and signing off on the result?

Rollback conditions

Under what specific circumstances will the migration revert to the source environment? What is the rollback process, who authorizes it, and what is the maximum acceptable rollback time? These conditions should be defined and tested before they are needed.

Stakeholder sign-off requirements

Which teams need to confirm readiness before cutover proceeds? Defining this in advance prevents the cutover from being blocked by stakeholders who weren't included in the planning process.

Without these criteria documented and agreed before the double-run begins, cutover decisions become negotiated in real time under cost pressure, which is precisely when they are most likely to be made on the wrong basis.

Phase 4: managing internal resistance

Key takeaway: The organizational obstacles to migration are more predictable than the technical ones. Addressing them explicitly in the planning phase is cheaper than managing them as surprises during execution.

The teams most likely to resist migration aren't the ones with the most complex workloads. They're the ones with the least clarity about what the migration means for their current ways of working, their existing tooling investments, and their day-to-day operational responsibilities.

Three things reduce this resistance more effectively than technical communication:

Early involvement in workload categorization
Teams that participate in the 6 Rs assessment for their own workloads are significantly less likely to obstruct the migration decisions that result from it. Categorization done to teams generates resistance. Categorization done with teams generates ownership.

Clear answers to the autonomy question
The most common concern from engineering teams is that migration means losing control over their technology choices. Address this directly and specifically: what changes, what stays the same, and what they will gain in return for what they give up. Vague reassurances don't reduce resistance. Specific, honest answers about the trade-offs do.

Visible executive ownership
Migrations with named executive sponsors who are visibly accountable for outcomes consistently outperform those where ownership is diffuse. This isn't about executive involvement in technical decisions. It's about having a named individual whose professional accountability is attached to the migration's success.

The organizational work in phases 1 through 4 is what separates migrations that complete on time and on budget from the ones that don't. The technical work is necessary but not sufficient. A migration that is technically sound but organizationally underprepared will stall at the first significant decision point, and in a migration project, significant decision points arrive on a schedule that doesn't wait for internal alignment to catch up.

Read the migration feasibility checklist. 

Frequently asked questions (FAQ)

How long should the assessment phase take? 

For most enterprise migrations, a thorough assessment takes four to eight weeks for an estate of moderate complexity. Organizations that compress this to two weeks consistently report that undiscovered dependencies surface during execution and add more time to the project than the compressed assessment saved. The assessment phase is the cheapest time to discover complexity; it gets more expensive with every subsequent phase.

What's the right size for a first migration workload? 

Small enough to complete within a single sprint cycle, significant enough to validate the migration process end to end. The goal of the first migration is to test the tooling, the process, the rollback procedure, and the team's capability, not to move the most important workload. A rehost migration of a low-criticality service is usually the right starting point.

How do we handle workloads that can't move due to contractual lock-in? 

Contractual constraints, including minimum spend commitments, dedicated instance reservations, and long-term service agreements, are a sequencing input, not a migration blocker. Map the contract end dates alongside the technical workload categorization and sequence migrations to align with contract expiry where possible. In the interim, use demonstrated portability on other workloads to strengthen your negotiating position for the next contract cycle.

What does a rollback plan actually need to contain? 

At minimum: the specific conditions that trigger a rollback, the technical steps required to restore the source environment to operational status, the time required to execute those steps, and the named individual authorized to make the rollback decision. Rollback plans that exist only as documentation are less useful than ones that have been tested in a non-production environment before the cutover window opens.

How do we measure migration success beyond cost? 

Cost is the most visible migration metric but not always the most meaningful one. The metrics that matter to ITMMs specifically are: delivery speed on migrated workloads compared to pre-migration baseline; incident recovery time in the new environment compared to the old; compliance evidence production before and after; and negotiating leverage in the next provider contract cycle. Define these baseline measurements before migration begins so the comparison is credible when the project closes.