A cloud migration is not a project with an end date. It is the first ninety days of an operating commitment that typically runs three years or longer, which means the decision determining long-term cost is the operating model rather than the platform.
Most migration RFPs ask what it costs to move. The cost of moving is knowable, quotable, and the wrong thing to optimize against. Two harder questions decide the outcome: what the environment costs to operate once you are running in it, and how long you stay locked in before switching turns prohibitive. Operating cost and switching cost rarely appear in the RFP at all.
I have watched organizations run a rigorous six-month platform evaluation and then scope the engagement as a twelve-week project. The evaluation was correct. The scope was not. The contract covering the first ninety days rarely covers the years after them, and migration value gets lost in the gap between the two documents.
A migration decision commits you to an operating model, a cost structure, and an identity architecture. All three outlive the project team by years. The platform you select determines what your team spends its time on for as long as you stay on the platform, which is a longer horizon than the statement of work implies.
Start with the identity model. Suppose your environment runs hybrid Active Directory with conditional access policies. The depth of each platform's federation support then determines how much custom integration your team maintains permanently. Custom integration work appears in no migration quote, and the maintenance continues long after the project closes.
Egress economics come second. Cross-platform data transfer and inter-region pricing vary enough to move total cost of ownership materially for data-heavy workloads. Model transfer costs against your own data movement patterns, because a generic estimate assumes a traffic profile you do not have. [VERIFY: confirm current published egress rates for AWS, Azure, and GCP at draft time. Provider pricing pages are the only acceptable source and they change frequently.]
Recurring operating cost comes third, and operating cost dominates the other two. Flexera's 2026 State of the Cloud Report surveyed 753 cloud decision-makers, who estimated that 29 percent of their IaaS and PaaS spending delivers no useful value or is otherwise avoidable.¹ The 29 percent figure is self-reported, which makes the number a measure of what practitioners believe they are wasting rather than an audited finding. Self-reported or not, the figure remains the clearest available signal that operating cost, rather than migration cost, determines whether the investment pays back.
Identity architecture, egress economics, and recurring operating cost share one property. The platform choice decides all three, and none of the three appears as a line item in the proposal recommending that platform.
Exit cost prices the decision you cannot reverse cheaply. Calculate what moving off a given platform would take three years from now, in dollars and in engineering hours. A platform that is inexpensive to enter and expensive to leave has deferred a cost rather than avoided one, and the deferred cost stays invisible on the business case that won approval.
Cloud exit cost is the total of four line items: egress fees to move your data out, engineering hours to rewrite identity and access policies, replacement or re-architecture cost for any proprietary managed service you adopted, and the parallel running cost of operating both environments during the transition. Price all four against your environment three years from now rather than against your environment today, because data volumes and service dependencies both grow.
The fourth item is the one most calculations miss. Leaving a platform is itself a migration, which means it carries the same parallel infrastructure cost and the same cutover risk as the move that got you there. An exit plan that assumes a clean switch is not an exit plan.
Run the calculation before you commit rather than after. Pricing the reversal in advance is the only way to surface a lock-in cost while you still have leverage to negotiate against it.
A platform-agnostic evaluation starts without a predetermined answer and stays open to any of them. Platform-agnostic does not mean multi-cloud, and it does not mean treating every platform as interchangeable.
Some environments land on a single platform after rigorous evaluation. Others land on a deliberate hybrid split driven by data residency requirements or by estates inherited through acquisition. Multi-cloud adopted without a specific driver adds operational complexity and returns nothing in exchange. An evaluation that produced no exit cost figure was a preference with supporting documentation.
Executives should use the Rs framework to decide which workloads stay put. Deciding what does not move is the portfolio question, and it is the part of the framework an executive influences directly.
The framework traces to 2011, when Gartner research director Richard Watson identified five ways to migrate applications to the cloud.² AWS expanded the list to six in 2016 and added a seventh, relocate, in 2017 to cover hypervisor-level migrations. AWS now documents all seven in its Prescriptive Guidance.³ Choosing among rehost, replatform, and refactor for a given workload is a technical judgment, and the teams doing the work should own it.
Retain and retire sit apart from the technical five. Retain and retire are business decisions, and both get skipped in practice. Every workload migrated that should have been decommissioned becomes technical debt you paid to move rather than eliminate. Every workload migrated that should have stayed put becomes an operating cost you took on by choice. Both errors stay hidden until the environment runs and the first full invoice arrives.
Lift-and-shift deserves a specific mention, because organizations treat rehosting as a decision when it functions as a deferral. Rehosting buys speed and postpones cost optimization, which is a sound trade when the postponement is deliberate and scheduled. The trade turns bad when the right-sizing pass never gets funded. Commit to rehosting as phase one with a funded phase two, or accept that you are paying cloud rates for on-premises headroom you left behind.
The Rs question worth asking in a steering meeting is how many workloads the assessment recommended retiring, and whether the retirement count holds up under scrutiny.
Name a person before cutover starts and write the name into the runbook. Rollback authority is a governance decision, and unassigned authority defaults to whoever holds the most seniority on the bridge call when something breaks. Seniority in the moment is a poor proxy for informed judgment about a specific environment.
The supporting data is unambiguous. Uptime Institute's 2025 Annual Outage Analysis found that close to 40 percent of organizations experienced a major outage caused by human error in the preceding three years, and that 85 percent of those incidents traced to staff failing to follow procedures or to flaws in the procedures themselves.⁴ A rollback called without a pre-agreed threshold and a named decision maker falls into the second category, meaning a flaw in the procedure itself. The procedure was missing, so nobody could follow it.
Quantitative rollback criteria defined in advance are the clearest signal that a migration plan is complete. The plan should specify the error rate, the latency threshold, and the failed transaction count that trigger a reversal. Absent those three numbers, the team decides mid-incident, under pressure, while still disagreeing about what counts as failure. Teams make poor decisions under exactly those conditions.
Two questions settle rollback authority before signature. What quantitative thresholds trigger a rollback, and who holds authority to invoke it? A migration partner who cannot answer both questions in writing is presenting a plan with a gap in it, however detailed the rest of the document looks.
Skip the partner when you already hold the operating capability in-house and the migration is a genuine one-time event. Some organizations meet both conditions. An enterprise with a dedicated virtualization team, current platform expertise, and no plan to change platforms again for five years should run the migration internally. A partner would add coordination overhead and sell capability the enterprise already has.
Self-management after cutover follows the same logic. Consider an environment that runs stably, serves a homogeneous user population, and sits with a team holding capacity beyond its existing commitments. A managed service in that setting is a cost with no matching benefit. Organizations overestimate how often stability, homogeneity, and spare capacity hold together, and go-live plus fourteen months tends to be where the overestimate surfaces. All three conditions are real when they are real.
Pairing the wrong customer with the wrong model is expensive for everyone: an engagement that should never have started produces a strained relationship, a disappointed buyer, and a story that isn't case-study worthy. Naming the conditions for a no in advance costs far less than discovering the same conditions in month fourteen.
The useful question is: which capabilities do you intend to build and keep? Which capabilities would you rather rent?
Architectural decisions determine the shape of an outcome. Architecture does less to determine the quality of that outcome. A correctly scoped engagement, on a correctly selected platform, with named rollback authority, will still generate its first two hundred tickets from ordinary implementation detail.
Containers, peripherals, and logon storms share a resolution: each failure surfaces at implementation depth, and people working at that depth catch them. Evaluating the operating model rather than the migration event is how you find out whether those people are still around on month four.