Cloud Migration Strategy: The Practical 2026 Playbook

What are the six cloud migration types, and how do they compare?

The six migration types — rehost, replatform, refactor, repurchase, retire and retain — describe the six things you can do with any workload facing a move. Rehost lifts it unchanged, replatform swaps components for managed equivalents, refactor rewrites it for cloud-native services, repurchase replaces it with SaaS, retire switches it off, and retain deliberately leaves it where it is. A realistic migration uses four or five of the six, not one.

Retire and retain are the most under-used entries on that list. Every estate carries workloads nobody would rebuild today, and moving them simply relocates the problem onto a metered bill.

Should you choose a migration type per workload or per company?

Choose per workload. A company-wide decision to lift-and-shift everything, or to go cloud-native everywhere, forces the wrong treatment onto most of the estate — a payroll system and a customer-facing API have nothing in common except an owner. Score each workload on its own merits, then group the results into delivery waves.

Four questions settle almost every workload:

• Does it still earn its keep? If nobody can name the process it serves, the answer is retire.
• Is it commodity or differentiating? Commodity means repurchase; differentiating earns the refactor budget.
• What is the change rate? Code untouched for two years rarely repays a rewrite.
• What is the constraint? A lease expiry pushes towards rehost; a scaling ceiling pushes towards replatform or refactor.

RioCloud Solutions has run cloud and DevSecOps work from Chandigarh since 2020, for 100+ brands across 12 countries. The sequence below is what we work through before a single workload moves — engagement examples sit on our case studies page.

What do you need to inventory before you move anything?

A migration inventory has to cover far more than servers. You need the application, the data it holds, the integrations it depends on, the identities that reach it, the licences that bind it and the person who owns it. Anything missing from that list becomes an incident during cutover rather than a line item during planning.

• Applications and versions — OS, runtime, middleware, and anything past end of support.
• Data — size, growth rate, classification, residency rules, retention obligations.
• Integrations — inbound and outbound, with protocols, hostnames, allow-lists and certificates.
• Identity and access — directory dependencies, service accounts, hardcoded credentials.
• Licensing — per-core, per-socket or per-user terms, and whether they survive shared tenancy.
• Ownership — a named business owner and technical owner, not a team alias.
• Performance baselines — latency, throughput and error rates, so you can prove parity afterwards.

How do you find the dependencies nobody documented?

Architecture diagrams are a starting hypothesis, never the answer. Real dependency maps come from observed traffic: run agentless network flow collection or an application discovery tool across a full business cycle, then reconcile what it sees against what people say. The gap between the two is where migration risk lives.

• Observe through a month-end. Batch jobs, reconciliations and reporting extracts only appear on the dates they run.
• Chase every unexplained flow. A connection nobody recognises is a dependency, not noise.
• Check the edges. Cron on forgotten VMs, scripts on someone's workstation, file drops on an SMB share.
• Follow DNS and certificates. Hardcoded hostnames and pinned IPs break silently when addressing changes.
• Ask suppliers. Third parties often hold allow-lists containing your outbound IPs, which change on migration day.

The application nobody owns is the one that breaks — no test plan, no rollback plan, nobody to call at 2am. Treat an unowned workload as a blocker: find the owner or retire it.

What should you cost-model before the first workload moves?

Model the run-rate before you commit, not after. A credible model covers compute shape, egress, storage tiers, licensing, support plan and the one-off migration cost, each stated as a range with the driver that moves it. Anything you cannot model, flag as an assumption and revisit after the first wave rather than burying it in a total.

• Compute — instance shape, hours running, commitment coverage. Size on observed utilisation, never on-prem cores 1:1.
• Egress and cross-zone traffic — free inside the building, metered in the cloud, and routinely modelled as zero.
• Storage — tier and provisioned IOPS, plus the snapshots, replicas and backups nobody counts.
• Licensing — check whether per-core or per-socket terms survive shared tenancy.
• Support plan — a percentage of spend with a floor, usually left out of the business case.
• One-off migration — tooling, transfer, people, and the dual-running months when you pay twice.

List prices and discount programmes change often — as of mid-2026, verify current pricing with your provider before you budget. For provider-level trade-offs, our AWS vs GCP vs Azure comparison covers where each is genuinely cheaper.

Why does lift-and-shift often cost more than the datacentre?

Lift-and-shift usually costs more because it moves an estate sized for peak, owned outright and long since depreciated, onto a meter that bills every hour whether the capacity is used or not. Rehosting removes none of the over-provisioning; it converts a sunk capital cost into a recurring operational one. The bill reflects yesterday's sizing decisions at today's list prices.

Three mechanics do most of the damage: idle time becomes billable, so weekend development servers now cost production rates; traffic that was free inside the building is metered the moment it crosses a zone; and storage arrives with snapshots, replicas and backups that each carry a line. None of that makes rehosting wrong — it makes it a stage, not a destination. Rehost to hit the deadline, then treat the quarters after landing as optimisation work, using our AWS cost reduction playbook.

How do you plan cutover so downtime stays inside the window?

Cutover planning is mostly about deciding in advance, and in writing, what success looks like and what triggers a rollback. Pick a pattern that matches the workload's tolerance for downtime, lower DNS TTLs days ahead, freeze changes on both sides, and rehearse the sequence at least once against production-like data. The rehearsal, not the plan, tells you whether the window is realistic.

• Pilot light. A minimal target environment stays warm and scales up at cutover — cheap to hold, slower to promote.
• Parallel run. Both estates process simultaneously and you compare outputs. Expensive, but the only honest test for finance systems.
• DNS and TTL. Drop TTLs to 60 seconds at least 48 hours ahead and confirm nothing caches beyond it.
• Freeze window. No schema changes, releases or firewall edits on either side from T-48 hours.
• Rollback criteria. Written thresholds for error rate, latency and failed transactions, plus a named person authorised to call it.
• Comms plan. Who tells customers, support and suppliers, and at which decision point.

Set the rollback deadline earlier than feels necessary. Teams that decide at hour six of an eight-hour window almost always overrun.

What are the real risks when you migrate the data?

Data is where migrations genuinely fail, because compute can be rebuilt and data cannot. The risks cluster around four things: consistency between source and target, replication lag at the moment you switch, the physics of moving large datasets, and control of encryption keys. Each needs a decision before the cutover date is fixed.

• Consistency. Agree a reconciliation method — row counts, checksums, business totals — and run it before the switch as well as after.
• Replication lag. Measure actual lag under production write load; that number sets your write freeze.
• Large datasets. Past a certain size, network transfer stops being practical and physical transfer appliances or staged seeding become the sane option.
• Encryption keys. Decide who holds them, where they live and how you re-encrypt — losing key custody mid-migration is unrecoverable.
• The point of no return. Name the moment after which the source is no longer authoritative, and tell the room when it passes.
• A readable source. Keep the old estate readable but not writable for a defined period after cutover.

How do you keep cloud costs under control after go-live?

Post-migration cost control is a standing process, not a project phase. Five mechanics matter — tagging, rightsizing, commitment discounts, autoscaling and anomaly alerting — in that order, because you cannot reduce or commit to spend you cannot attribute. Put the first two in place within 30 days of landing, while the estate is still fresh in everyone's head.

• Tagging. Enforce owner, environment and cost-centre tags at creation time through policy, not a spreadsheet chase.
• Rightsizing. Wait for a fortnight of real production metrics, size on the high percentile rather than the average, and step down gradually.
• Commitment discounts. Commit only to the baseline you are confident still exists next year; leave the volatile top on demand.
• Autoscaling and schedules. Non-production rarely needs to run overnight or at weekends — usually the fastest saving available.
• Anomaly alerts. Alert on percentage movement per service per week, routed to the team that owns the tag.

If e-commerce is your context, the e-commerce cloud cost audit runs the same loop against seasonal traffic, and a cost optimisation walkthrough shows the order of operations in practice.

Why do cloud migrations fail?

Most failed migrations fail for organisational reasons rather than technical ones. The recurring causes are an unowned application, a business case built on unmodelled costs, a big-bang cutover with no rollback path, and a team inheriting an estate it was never trained to run. All four are visible before you start, if anyone is willing to look.

• Big-bang cutover. Moving everything in one weekend removes any chance to learn between waves.
• No wave zero. Skip the low-stakes pilot and the first production workload becomes the experiment.
• Landing zone as an afterthought. Accounts, networking, identity and guardrails retrofitted later cost far more than built first.
• Security bolted on. Controls belong in the pipeline from wave zero — see DevSecOps for startups.
• Skills gap. The team that ran hardware now runs a bill, and nobody budgeted the training.
• Success measured by move date. If the only metric is workloads migrated, cost and reliability regressions go unmeasured.

Migration readiness checklist

Run this before wave one. If more than two items are unresolved, the date is optimistic.

1. Every in-scope workload has a named business owner and technical owner.
2. Dependency mapping has covered a full month-end cycle.
3. A migration type is assigned per workload, with the reason recorded.
4. Retire and repurchase candidates have been actively identified.
5. The run-rate cost model exists, with ranges and stated assumptions.
6. Landing zone, identity model and network design are built and reviewed.
7. Data reconciliation method and replication lag are measured, not assumed.
8. Rollback criteria are written, with a named decision-maker per wave.
9. Performance baselines are captured so parity can be proven.
10. Tagging policy is enforced before the first resource is created.
11. A wave zero pilot is complete and its lessons folded back in.

Frequently asked questions

How long does a cloud migration take?

It depends far more on estate complexity than estate size. A handful of well-understood applications can move in weeks; a large estate with undocumented integrations and licence constraints usually runs across several quarters in waves. Discovery and dependency mapping normally consume more calendar time than the moves themselves.

Is lift-and-shift ever the right answer?

Yes — when a hard deadline exists, such as a lease expiry or hardware refresh, or when the workload is stable and slated for replacement anyway. The mistake is treating rehost as the finish line. Budget optimisation work for the quarters after landing, or the bill stays higher than the datacentre.

Should we migrate everything to a single cloud provider?

For most organisations, yes. One provider means deeper discounts, one identity model, one skills investment and one set of guardrails. Multi-cloud is justified by specific needs — data residency, a service only one provider offers, or a genuine regulatory requirement — not by a general wish to avoid lock-in.

How much downtime should we plan for during cutover?

Set the target from the business, then design the pattern to fit it. Near-zero downtime is achievable with continuous replication and a short write freeze, but it costs more in tooling and rehearsal. Whatever window you agree, add contingency and set the rollback decision point well before it closes.

Do we need Kubernetes to migrate to the cloud?

No. Kubernetes solves scheduling and packing problems at a certain scale and adds real operational overhead below it. Managed compute, container services or plain virtual machines carry most migrations perfectly well. Treat Kubernetes as a platform question for after the move, not a precondition for it.

What is the biggest mistake in the first 90 days after migrating?

Declaring victory. The estate is at its most inefficient on landing day, the tags are at their cleanest, and everyone still remembers what each workload does. Teams that spend that window on tagging, rightsizing and commitment planning keep the savings; teams that move straight on rarely recover the context.

Next steps

Pick your three worst-understood workloads and map their dependencies this month — that exercise alone usually reshapes the plan. For a second opinion on scope, sequencing or the cost model, talk to RioCloud Solutions, or see how our cloud and DevSecOps team runs discovery and landing zones. If containers are on the table, read Kubernetes for small teams first.