Rehost, replatform, refactor, retire or retain: a cloud migration decision framework for the enterprise

There are five cloud migration strategies that matter for most enterprise estates: rehost (move it as-is), replatform (move it with targeted swaps to managed services), refactor (re-architect it for cloud-native operation), retire (switch it off) and retain (keep it where it is, for now). Choosing between them is not a matter of technical taste. It is a per-application decision, and in an enterprise it is governed by three constraints that the textbook frameworks underweight: how much downtime the application can tolerate, which regulatory obligations travel with its data, and what it is wired to. Settle those three, in that order, for every application before anyone estimates effort, and most of the risk in a migration programme is retired on paper instead of in production.

The stakes justify the discipline. McKinsey estimates that cloud could add around $3 trillion in EBITDA across the Forbes Global 2000 by 2030, and that the value created by enabling innovation is more than five times what pure IT cost reduction delivers. In banking, it found the largest share of cloud value comes from improved IT resiliency rather than from cheaper infrastructure. Yet the cost side keeps slipping: Flexera's 2026 State of the Cloud report put estimated wasted spend on infrastructure and platform services at 29 percent, the first increase in five years, with 85 percent of organisations naming cloud spend management as a top challenge. The difference between those two numbers is mostly decided by the treatment chosen for each application and by what happens in the months after cutover.

The five strategies, and what each one actually commits you to

The vocabulary comes from Gartner's original "R" taxonomy, which AWS later expanded into seven strategies by adding relocate and repurchase. The five below carry the weight in almost every enterprise portfolio; the other two are covered at the end of this section.

Rehost (lift and shift). The application moves to cloud infrastructure with no meaningful change to code or architecture. It is the fastest way to exit a data centre, reduce hardware refresh exposure and get workloads under a single control plane. What it commits you to is running yesterday's architecture on today's pricing model: sizing inherited from on-premises peaks, licensing models that may not translate, and operational habits built for servers that never went away. Rehost is an excellent first move and a poor destination. It works when it comes with a dated plan to revisit the application, and fails when the programme declares victory at cutover.

Replatform (lift, tinker and shift). The application moves with a small number of deliberate substitutions: a self-managed database becomes a managed database service, an application server becomes a container platform, file shares become object storage, a homegrown scheduler becomes a managed workflow service. Core code stays largely intact. For regulated enterprises this is often the highest-return strategy, because each substitution hands patching, backup, encryption and high availability to a service whose controls are documented and auditable. The commitment is modest re-testing and a clear decision about which substitutions earn their keep. Replatforming everything that could be replatformed is how a fast programme becomes a slow one.

Refactor (re-architect). The application is redesigned to use cloud-native capabilities: decomposition into services, event-driven integration, serverless or managed compute, horizontal scaling, infrastructure as code from the ground up. It is the only strategy that changes what the application can do for the business, and the only one that reliably changes its unit economics. It is also the most expensive, the slowest and the most likely to overrun, because effort is usually estimated before anyone has read the code. Refactor where the current architecture is the reason a business outcome cannot be achieved, and where the application changes often enough for the investment to compound. Refactoring a stable system because it is old is not a strategy; it is a hobby.

Retire. The application is decommissioned, and its data is archived to meet retention obligations. In nearly every enterprise portfolio assessment a meaningful slice of the estate turns out to be redundant: duplicated after an acquisition, superseded by a newer system nobody switched the old one off for, or used by a handful of people for a report that could be produced elsewhere. Retirement is the cheapest migration there is, removes attack surface and shrinks every subsequent wave. Its real cost is organisational: someone has to own the decision, prove nobody depends on the system, and handle data retention properly.

Retain. The application stays where it is, deliberately and with a review date. Common reasons are a hard regulatory or contractual constraint, a dependency that must move first, latency to on-premises equipment, a vendor that does not support cloud deployment, or a system with a defined end of life that does not justify migration effort. Retain is a legitimate strategy, not a failure, provided it is a decision rather than a default. An application retained without a reason and a review date becomes the reason the data centre lease gets renewed.

Two further strategies complete the AWS set. Repurchase replaces an application with a commercial product, usually SaaS, and is the right call when a capability is not differentiating and a market product is good enough. Relocate moves virtualised infrastructure at the hypervisor level, typically VMware estates, with minimal change to operations; it is a speed play for data centre exits that buys time to make better per-application decisions later.

Why generic decision trees break down in the enterprise

Most migration decision trees start with business value: is the application strategic, is it differentiating, does it change often. Those questions matter, but enterprise programmes rarely fail on strategy. They fail on constraints that surface late: a payments system whose real cutover window turns out to be eleven minutes, a clinical integration nobody listed, a database that four other applications quietly write to, a data residency rule that applies to logs and backups as well as the primary store. A framework that does not interrogate constraints first produces treatment decisions that collapse on contact with the estate.

The framework below inverts the usual order. It eliminates applications that should not move, then lets constraints narrow the options, and only then lets business value choose between what remains.

The decision framework: six questions, asked in order

• 1. Does anyone still need it? Check usage logs, licence assignments and downstream consumers, not just the owner's opinion. If the answer is no, or the capability exists elsewhere, retire it and archive the data.
• 2. Is there a hard blocker to moving it in this programme? Regulatory, contractual, vendor support, physical latency or an unresolved dependency. If yes, retain it, record the blocker and set a review date.
• 3. Is a market product good enough? If the capability is not differentiating and a SaaS product meets the requirement, including the compliance requirement, repurchase.
• 4. Does the current architecture block a business outcome, and does the application change often? If both are true, and the team can absorb the effort, refactor, ideally incrementally.
• 5. Is there a managed-service substitution with a clear payback? If swapping the database, runtime or storage removes significant operational work or control burden, replatform with only those substitutions.
• 6. Otherwise, rehost, and put a revisit date in the plan before the application moves.

The order matters because each question is cheaper to answer than the next and removes applications from the expensive part of the funnel. In a large estate, the first two questions alone usually take a significant share of the portfolio out of migration scope, which shortens the programme more than any tooling decision will.

Constraint one: uptime and recovery objectives

Uptime is the constraint that most directly decides the cutover pattern, and the cutover pattern often decides the strategy. A useful practice is to classify every application into a tier based on the downtime the business will actually accept during migration, which is frequently different from its production availability target.

• Tier 0, no planned downtime: payments, core banking posting, electronic health records, order capture, trading. These need continuous replication with change data capture, a period of parallel running with reconciliation, and traffic that can be shifted back within minutes. They should move incrementally, slice by slice, rather than in a single cutover weekend, which in practice favours replatform or incremental refactor over rehost.
• Tier 1, a short window measured in minutes to an hour: customer-facing portals and internal systems with predictable quiet periods. Block-level or database replication up to the cutover moment, a final sync, and a rehearsed rollback.
• Tier 2, a window measured in hours: most internal line-of-business applications. Standard rehost tooling with snapshot-based migration is usually enough.
• Tier 3, days are acceptable: batch, reporting and archival systems. The cheapest path wins, and these are often the strongest retire candidates.

Two rules make the tiers hold up in practice. First, rehearse every Tier 0 and Tier 1 cutover at least twice with production-scale data, and plan against the measured window rather than the estimated one. Second, define rollback criteria in advance and name the person authorised to call it. Most migration incidents that become outages are not technical failures; they are hesitations by teams that never agreed what failure looked like.

Recovery objectives matter after cutover as much as during it. An application with a four-hour recovery time objective on premises does not need a multi-region active-active design in the cloud. Over-engineering resilience beyond what the business requires is one of the fastest ways to make a migrated estate cost more than the one it replaced.

Constraint two: compliance and data obligations

Compliance rarely decides whether an application can move to the cloud. It decides the shape of the move: which region, which services, which contract terms, which controls must be demonstrably in place before the first byte of regulated data lands. The provider secures the platform; the customer remains accountable for how it is configured and used, and for proving that to an auditor.

• Residency and localisation. Some obligations dictate where data may live, and they reach further than the primary database. The Reserve Bank of India's 2018 direction on payment system data requires that data to be stored only in India; where processing happens abroad, the data must be deleted there and brought back within one business day or 24 hours. Backups, disaster recovery replicas, log pipelines, analytics copies and support access all have to respect rules like this.
• Provider contracts. In US healthcare, HHS guidance is explicit that a covered entity or business associate may use a cloud service for electronic protected health information only under a HIPAA-compliant business associate agreement, and a provider that stores encrypted PHI without holding the key is still a business associate. Providers typically limit their agreement to a defined list of eligible services, so the architecture has to stay within that list.
• Third-party risk regimes. In the EU, the Digital Operational Resilience Act has applied since 17 January 2025 and requires financial entities to maintain a register of information covering their ICT third-party arrangements, with stronger contractual expectations, including exit strategies, for services supporting critical or important functions. In the US, the June 2023 interagency guidance from the Federal Reserve, FDIC and OCC sets out risk management expectations across the full life cycle of third-party relationships, from planning and due diligence to termination.
• Evidence, not intent. Auditors want proof that controls operate in the new environment: centralised logging, key management and rotation, access reviews, change records, vulnerability management. Building evidence collection into the landing zone from day one is far cheaper than reconstructing it before the first audit.
• Exit and concentration. Regulators increasingly expect a credible plan for leaving a provider. Every refactor onto proprietary services raises the cost of that exit, which makes portability a compliance consideration, not only an architectural preference.

In practice, compliance pressure tends to push applications toward replatforming onto managed services whose controls are already documented, and away from hand-built infrastructure that the enterprise must evidence itself. Occasionally it forces a retain decision. It almost never supports a hurried rehost of regulated data into an environment whose controls have not been validated.

Constraint three: legacy dependencies

The application list is not the unit of migration. The dependency graph is. Two applications that look independent in the CMDB may share a database, exchange files nightly or call each other thousands of times per transaction. Split them across an on-premises and cloud boundary and they will either break or slow down, often in ways that only appear under real load.

• Chatty integrations. Calls that took well under a millisecond inside one data centre can take several milliseconds or more across a hybrid link. Multiplied across thousands of calls per business transaction, that turns into seconds of user-facing delay.
• Shared databases. When several applications read from and write to the same schema, they must move together or be decoupled first, usually behind an API layer.
• Hard-wired infrastructure. Hard-coded IP addresses and hostnames, mapped network drives, partner file drops over FTP, and batch schedules that assume a particular server will be awake at 2 a.m.
• Licensing tied to hardware. Per-core or per-socket licences, hardware dongles and licences bound to a machine identifier can make a technically simple rehost commercially expensive.
• Mainframe and midrange systems. These are seldom rehosted. More often they are retained and wrapped with APIs, or strangled incrementally as capability moves out piece by piece.
• Undocumented consumers. Reports, spreadsheets and partner integrations that read directly from a database are typically discovered only when they stop working.

The remedy is automated dependency discovery combined with interviews, followed by move groups built around dependency affinity rather than organisational ownership. Hard dependencies should be broken before a wave, with an API facade or a replicated data feed, not improvised during cutover.

Putting it together: a scoring model for the portfolio

To make the framework repeatable across hundreds or thousands of applications, score each one from one to five on six dimensions: business value and rate of change, technical condition, uptime tier, regulatory weight, dependency entanglement and licensing friction. The scores do not make the decision, but they make patterns visible and arguments shorter.

• High rate of change, poor technical condition, low entanglement: strong refactor candidate, delivered incrementally.
• Stable, acceptable condition, moderate entanglement: rehost in an early wave, with a replatform review scheduled once the application is running in the cloud.
• Heavy operational burden on databases or middleware, high regulatory weight: replatform onto managed services with inherited controls.
• High entanglement with a mainframe or shared core: retain for now, decouple behind APIs, and move consumers first.
• Low usage, duplicated capability: retire, with a data retention plan.
• Commodity capability with a credible compliant SaaS market: repurchase.

The output of the assessment should be one row per application with six fields: treatment, wave, move group, cutover pattern, compliance owner and review date. If any of those fields is blank, the application is not ready to be estimated.

Healthcare: what changes when the data is PHI

Healthcare migrations carry clinical as well as commercial risk, and the playbook has to reflect that.

• Confirm which provider services fall under the business associate agreement, and keep PHI workloads inside that boundary, including logging, monitoring and analytics services.
• Map every PHI data flow, including copies that are easy to forget: log files, message queues, data warehouse extracts, backups and test environments. Non-production environments should use synthetic or de-identified data.
• Treat interface engines and HL7 or FHIR integrations as first-class migration objects with their own testing, since a silent message failure can affect patient care.
• Align cutover windows with clinical downtime procedures, and involve clinical operations in rehearsals rather than informing them afterwards.
• Expect some workloads, such as imaging archives or systems tied to on-site medical devices, to remain on premises or in a hybrid pattern because of latency and data volume.

Banking: resilience is the regulation

In banking, the migration itself is a resilience event that supervisors care about, and the plan should be written with that audience in mind.

• Core ledgers are rarely rehosted. The pattern that works is incremental: place an API abstraction in front of the core, move capabilities out in slices, and run old and new paths in parallel with automated reconciliation.
• Respect the batch calendar. End-of-day, month-end and regulatory reporting cycles define the real cutover windows.
• Keep the third-party register, exit strategy and concentration analysis current as each wave lands, rather than as a year-end exercise.
• Design key management and hardware security module usage early, since cryptographic architecture is expensive to change after go-live.
• Check data localisation and supervisory notification requirements in every jurisdiction the bank operates in before selecting regions.

Cost optimisation pitfalls after migration

Cutover is where most business cases stop modelling and where most of the waste begins. The same pitfalls appear in almost every estate.

• Sizing inherited from on-premises peaks. Rehosted servers are usually provisioned to match the hardware they replaced, which was itself sized for a peak plus headroom. Right-size against observed cloud utilisation within the first few weeks.
• Commitments bought at the wrong time. Committing to reserved capacity or savings plans before right-sizing locks in waste; waiting a year leaves steady-state savings on the table. Right-size first, then commit in tranches.
• Dual running that never ends. The old environment stays warm "just in case" long after the rollback window has closed. Every wave should have a decommissioning date that someone is accountable for.
• Data transfer charges from split dependencies. Applications separated from their databases or partners by a hybrid link, or spread across availability zones and regions without need, generate egress and cross-zone charges that never appeared in the business case.
• Non-production running around the clock. Development, test and staging environments sized like production and running 24 hours a day are among the easiest savings to capture and the most commonly missed.
• Storage and observability sprawl. Orphaned volumes, forgotten snapshots, unlimited log retention and high-cardinality metrics grow quietly until the monitoring bill rivals the compute bill.
• Licensing surprises. Bring-your-own-licence terms, Windows and SQL Server licensing, and per-core database licences behave differently on cloud infrastructure than on owned hardware.
• Resilience beyond the requirement. Multi-region active-active designs for systems whose recovery objectives would be met by a well-tested backup and restore process.
• Spend without an owner. Without consistent tagging, cost allocation and named accountability, nobody is responsible for the bill, and the bill behaves accordingly. Flexera's 2026 data suggests AI workloads are making this harder, not easier.

A 90-day cost discipline after each wave

• Weeks one to two: confirm every resource carries owner, application, environment and cost-centre tags, and that unallocated spend is reported weekly.
• Weeks two to six: right-size compute and databases against observed utilisation, schedule non-production shutdowns, and set storage and log retention policies.
• Weeks six to ten: decommission the on-premises footprint for the wave, release licences and confirm the data centre cost actually falls.
• Weeks ten to twelve: buy commitments for the stable baseline, review data transfer patterns, and agree unit cost metrics, such as cost per transaction or per patient encounter, with the business owner.
• Ongoing: review each application's treatment again at its review date. Many rehosted applications become replatform candidates once their real behaviour in the cloud is visible.

How Webneuron approaches enterprise migrations

Webneuron works as an engineering-first migration partner across AWS, Azure and Google Cloud, which in practice means the people assessing an estate are the same engineers who will build the landing zone, migrate the waves and run or hand over the platform. That continuity matters, because the most expensive migration mistakes are made at the boundary between whoever produced the plan and whoever has to execute it.

The other difference is that no engagement starts from a blank page. Webneuron embeds pre-built industry playbooks into every migration, so the decisions this guide describes are made against patterns that have already been tested rather than invented under deadline pressure. A playbook typically brings:

• A reference landing zone with identity, network segmentation, encryption, logging and policy guardrails defined as code, and controls mapped to the relevant regulatory frameworks.
• An assessment model covering the six questions and scoring dimensions above, so treatment decisions are consistent and defensible across the portfolio.
• Cutover runbooks for common platforms and uptime tiers, including replication approaches, rehearsal plans and rollback criteria.
• Evidence packs that collect the artefacts auditors and risk teams ask for as a by-product of normal operation.
• A FinOps baseline, with tagging standards, budgets and post-wave optimisation steps in place before the first workload moves.

For regulated sectors the playbooks go further. In healthcare, they cover PHI data-flow mapping, business associate agreement service boundaries, interface engine migration and clinical downtime coordination. In banking, they cover incremental core modernisation behind an API layer, parallel running with reconciliation, third-party register and exit-plan documentation, and data localisation checks by jurisdiction. Webneuron's work with a regional bank, moving capability out of a twenty-year-old core in slices rather than in a single cutover weekend, reflects the pattern described above. The effect of starting from proven playbooks is less risk carried into each wave and shorter timelines, because teams spend their time on what is genuinely unique about an estate rather than on rediscovering what is not.

On a discovery call, we can walk through a sample of your portfolio against this framework and show where the treatment decisions, constraints and cost exposure are likely to sit.

Frequently asked questions

What are the main cloud migration strategies? The five core strategies are rehost, replatform, refactor, retire and retain. AWS adds repurchase (moving to a SaaS product) and relocate (moving virtualised infrastructure at the hypervisor level) to make seven.

Which cloud migration strategy is best? None is best in general. The right strategy is chosen per application, based first on whether it is still needed, then on uptime, compliance and dependency constraints, and only then on business value and the effort involved.

Is lift and shift a bad strategy? No. Rehosting is often the fastest way to exit a data centre and reduce risk. It becomes a problem when applications are never revisited after they move, because they keep on-premises sizing and licensing habits that cost more in the cloud.

How do you migrate regulated workloads such as healthcare or banking systems? Settle data residency, provider contracts and control evidence before migration starts, keep regulated data within services covered by the relevant agreements, move critical systems incrementally with parallel running, and maintain third-party risk documentation and exit plans as each wave lands.

Why do cloud costs often rise after migration? Most often because rehosted resources keep on-premises sizing, the old environment keeps running, non-production environments run around the clock, data transfer between split dependencies grows, and spend has no clear owner.

How long does an enterprise cloud migration take? A pilot wave can usually be completed within a few months. A large enterprise estate typically migrates over one to two years in waves, with timing driven by dependency groups, uptime constraints and decommissioning milestones rather than by tooling.

Sources

• AWS Prescriptive Guidance, migration strategies (the 7 Rs) and paths to the cloud.
• Flexera, 2026 State of the Cloud Report (published March 2026; survey of 753 cloud decision-makers and users).
• McKinsey & Company, Projecting the global value of cloud: $3 trillion is up for grabs for companies that go beyond adoption.
• U.S. Department of Health and Human Services, Office for Civil Rights, Guidance on HIPAA and Cloud Computing.
• Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), applicable from 17 January 2025.
• Board of Governors of the Federal Reserve System, FDIC and OCC, Interagency Guidance on Third-Party Relationships: Risk Management (June 2023).
• Reserve Bank of India, Storage of Payment System Data (circular dated 6 April 2018) and accompanying FAQs.