Cloud migration strategy is the plan for moving applications, data and infrastructure from where they run today into cloud environments, choosing for each workload how far to change it. The reference model is the 6 Rs: rehost, replatform, repurchase, refactor, retain and retire. A good strategy matches each workload to the right move rather than one blanket approach.
This guide is written for CTOs, founders and engineering managers weighing a move to the cloud, or partway through one and unsure whether they picked the right path. It explains why teams migrate, walks through the 6 Rs with honest trade-offs, lays out a phased plan, and covers the cost, security and partnering decisions that quietly determine whether the project pays off.
Why migrate to the cloud in the first place
Migration is not a goal on its own. It is a means to outcomes that on-premises or legacy hosting struggles to deliver, and it is worth being explicit about which outcomes actually matter to your business before you touch a single server. A cloud migration strategy that cannot name its own objectives tends to drift into a lift-and-shift that costs more than the data centre it replaced.
The common drivers, roughly in the order teams cite them, are these:
- Elasticity. Cloud lets you scale capacity up for a launch, a seasonal peak or a batch job, then scale back down. You stop paying for the headroom you provisioned for the worst day of the year.
- Speed of delivery. Managed databases, queues, container platforms and serverless runtimes remove undifferentiated work. Engineers spend less time racking hardware and patching operating systems, and more time shipping features.
- Reliability and reach. Multiple availability zones and regions make it feasible to build systems that survive a data-centre failure and serve users close to where they live, which is hard and expensive to replicate with owned hardware.
- Capital to operating cost. Migration converts large, lumpy hardware purchases into a metered operating expense. That can help cash flow, though it does not automatically make things cheaper, a point we return to under cost.
- Access to managed services. Analytics, machine learning, event streaming and identity services are available on demand. Building the equivalent in house is often neither realistic nor wise.
Against these, be honest about what migration does not fix. It will not repair a poorly designed application, and moving a fragile monolith to the cloud usually just gives you a fragile monolith with a larger bill. Understanding how your systems are structured, an exercise covered in more depth in our guide to web application architecture, is a prerequisite for deciding what each workload actually needs. The choice between owned and rented infrastructure is itself worth thinking through carefully, and we compare the two directly in our piece on cloud vs on-premise.
The 6 Rs of cloud migration
The 6 Rs are the industry-standard menu of migration paths, popularised by cloud providers and analysts and still the clearest way to reason about each workload as of 2026. The discipline of a strong cloud migration strategy is applying them per application, not per company. A single portfolio will usually contain workloads that want four or five different treatments. Here is each one, what it means, and when it fits.
Rehost (lift and shift)
Rehosting moves an application to cloud infrastructure with as few changes as possible, typically onto virtual machines that mirror the existing servers. You keep the same operating system, runtime and configuration; you change where it runs.
Rehosting is the fastest and lowest-risk move, which makes it attractive when you have a hard deadline such as a data-centre lease expiry, when the application is stable and rarely changed, or when you simply want to exit owned hardware before optimising anything. The trade-off is that you inherit all the inefficiency of the original design. You are paying cloud prices for a workload that was never built to take advantage of the cloud, so rehosting is best treated as a first step rather than a destination. Many teams rehost to hit a deadline, then replatform or refactor the important workloads afterwards.
Replatform (lift, tinker and shift)
Replatforming keeps the application largely intact but swaps some components for managed cloud equivalents. The classic example is moving a self-managed database onto a managed database service, or containerising an app and running it on a managed orchestration platform, without rewriting the business logic.
This is the sweet spot for a great many workloads. You capture meaningful operational savings, patching, backups and failover become someone else’s problem, while keeping the effort and risk far below a full rewrite. Replatforming suits applications that are worth keeping and reasonably well built, but that carry operational burdens you would rather hand off. The main pitfall is scope creep: “just one small change” quietly turns into a refactor. Keep the boundary of the change explicit.
Repurchase (drop and shop)
Repurchasing means retiring your own application and replacing it with a commercial product, usually a software-as-a-service subscription. Moving from a home-grown CRM to a market-leading one, or from a custom email platform to a hosted service, are typical examples.
Repurchasing makes sense when the capability is not a competitive differentiator and a mature product already does it better than you ever will. Why maintain a bespoke payroll system when robust ones exist? The cost is loss of control and the migration of data and integrations into the new product, plus the ongoing subscription and any lock-in that comes with it. Repurchase your commodity functions; do not repurchase the thing that makes your business distinct.
Refactor (re-architect)
Refactoring, sometimes called re-architecting, means substantially changing the application to take full advantage of cloud-native capabilities. This can mean decomposing a monolith into services, adopting serverless functions, redesigning data storage around managed services, or rebuilding for horizontal scale.
Refactoring delivers the largest long-term gains in scalability, resilience and development speed, and it is the right move for the workloads that matter most to your business, the ones under active development, facing unpredictable load, or being held back by their current architecture. It is also the most expensive and highest-risk path, demanding real engineering investment and time. Reserve it for the workloads where the payoff justifies the spend, and resist the temptation to refactor everything at once. A cloud migration strategy that tries to re-architect the entire estate in one program almost always overruns.
Retain (revisit)
Retaining means deliberately leaving a workload where it is, at least for now. Not everything should move on the first pass, and sometimes not at all.
You retain a workload when it has hard data-residency or regulatory constraints, when it depends on hardware or latency that the cloud cannot match, when a planned decommission is close enough that migrating would be wasted effort, or when the business case simply is not there yet. Retaining is a legitimate decision, not a failure, and a mature strategy states plainly which systems stay behind and why. The trap is retaining by default through inertia rather than by choice; revisit these decisions on a schedule.
Retire
Retiring means switching a workload off entirely. A surprising share of any portfolio, often ten to twenty percent, turns out to be redundant, superseded or simply unused once you actually inventory it.
Every workload you retire is one you do not have to migrate, secure, test or pay for, which makes retirement the highest-return move on the list per unit of effort. Discovering what to retire is a strong argument for doing a thorough assessment before migrating anything: you cannot switch off what you never knew was running. Confirm that a system is genuinely unused, capture any data you are legally required to keep, and communicate with the handful of users who might still depend on it before you pull the plug.
How to plan a cloud migration
The 6 Rs tell you what to do with each workload; a plan tells you how to get there without breaking the business in the process. A dependable cloud migration strategy moves through five phases, and while later workloads can be in one phase while earlier ones are in another, no individual workload should skip a phase. The sequence is assess, plan, migrate, validate and optimise.
- Assess. Build a complete inventory of applications, servers, data stores and their dependencies. Map what talks to what, because the integrations are where migrations break. For each workload capture its business criticality, its performance profile, its compliance constraints and its rate of change. This phase is where you assign each workload one of the 6 Rs and where you find the systems to retire. Skimping here is the single most common cause of failed migrations; the surprises you did not discover in assessment become outages in production.
- Plan. Sequence the work. Start with low-risk, low-dependency workloads to build the team’s cloud muscles and prove the tooling, then move up to the harder ones. Define the target architecture, the landing zone with its accounts, networking and guardrails, the security baseline, and the success criteria for each wave. Decide your rollback approach for every workload before you move it, and set an explicit budget with alerts so cost does not surprise you mid-project.
- Migrate. Execute in waves rather than one big cutover. For each workload, replicate data, stand up the target environment, and run the two in parallel long enough to build confidence. Automate the moves you repeat so they are consistent and reversible. Keep the old environment running until the new one has earned trust; a cheap parallel-run period is far less expensive than an emergency rollback under load.
- Validate. Prove that each migrated workload works before you send real traffic to it. Test functionality, performance under realistic load, failover behaviour, backups and, critically, the integrations you mapped in assessment. Confirm data integrity by reconciling records between old and new. Only when a workload passes its success criteria do you cut over and retire the source, and even then keep a documented path back for a defined window.
- Optimise. Migration is the start, not the finish. Once workloads are stable, right-size instances that were provisioned generously, adopt managed and serverless services where they now make sense, tune autoscaling, and put cost governance in place. This is also where rehosted workloads graduate to replatform or refactor if the business case holds. Optimisation is continuous; the estate you migrate in month one is not the estate you should still be running in month twelve.
Two habits separate smooth migrations from painful ones. First, treat infrastructure as code from the assessment phase onward, so environments are reproducible and every change is reviewable. Second, keep a living decision log recording which R you chose for each workload and why, so that six months later, when someone asks why the reporting database was retained, the answer is written down rather than lost.
Risks and common pitfalls
Most migrations that go wrong do so for a small set of predictable reasons. Knowing them in advance is the cheapest insurance available, and a cloud migration strategy that names its risks openly is already ahead of one that assumes everything will go to plan.
- Skipping discovery. Teams that start migrating before they finish assessing hit undocumented dependencies, forgotten integrations and shadow systems mid-flight. The fix is boring and reliable: inventory everything first.
- Lift-and-shift as the whole plan. Rehosting the entire estate and stopping there produces a cloud bill higher than the data centre with none of the cloud benefits. Rehost to move fast, then optimise the workloads that matter.
- Underestimating data. Moving terabytes takes time and bandwidth, and keeping the source and target in sync during the transition is harder than moving the data once. Plan the data path, including the cutover, early.
- Ignoring the network. Latency, bandwidth and connectivity between cloud and any retained on-premises systems routinely surprise teams. A hybrid state usually persists longer than anyone plans for, so design for it deliberately.
- No rollback plan. When a cutover fails at 2am, the teams that recover are the ones who decided in advance how to fall back. Every wave needs a tested reverse path.
- Big-bang cutovers. Trying to move everything in a single weekend concentrates all the risk into one window with no room to react. Waves spread the risk and let you learn as you go.
- Treating migration as done at cutover. Without the optimisation phase, costs stay high and the promised benefits never fully arrive. Budget for the work that comes after the move.
None of these are exotic. They are the same handful of mistakes repeated across industries, which is precisely why a deliberate strategy and an experienced pair of hands are worth so much.
Cost considerations
The most persistent myth about the cloud is that it is automatically cheaper. It can be, and for elastic and bursty workloads it usually is, but a naive migration frequently costs more than the infrastructure it replaced. The reason is that owned hardware is a sunk cost you have already paid, while the cloud meters everything, and a workload sized for its worst day keeps costing you for that headroom every hour.
To keep a cloud migration strategy honest on cost, account for the things teams commonly miss:
- Data egress. Moving data out of a cloud provider, and sometimes between regions, carries charges that add up quickly for data-heavy or multi-cloud designs.
- Idle and oversized resources. Instances provisioned generously “to be safe” and never right-sized are the largest source of waste. Right-sizing in the optimise phase often recovers a substantial share of the bill.
- Managed-service premiums. Managed databases and platforms save operational effort but cost more per unit of compute than raw virtual machines. That trade is usually worth it, but price it deliberately.
- Commitment discounts. Reserved capacity and savings plans cut costs meaningfully for steady workloads, but they lock you in. Commit only once usage is predictable, which is another reason to sequence commitments after the migration settles.
- The migration project itself. Engineering time, parallel-running two environments during transition, and tooling all cost money up front, before any savings arrive.
The practical answer is to model total cost of ownership across a three-to-five-year horizon rather than comparing a monthly cloud invoice to a hardware purchase, to put budget alerts and tagging in place from day one, and to treat cost as an ongoing engineering concern rather than a finance report that arrives too late to act on. For larger organisations juggling many workloads and cost centres, the governance overhead is real, and our guide to enterprise software development covers the surrounding disciplines in more depth.
Security and compliance considerations
Security in the cloud rests on a shared responsibility model that catches teams out more often than any technical detail. The provider secures the underlying infrastructure, the physical facilities, the hardware and the virtualisation layer. You remain responsible for how you configure your services, for your data, for identity and access, and for your application code. The overwhelming majority of cloud incidents come not from providers being breached but from customers misconfiguring what they own, a storage bucket left public, over-broad permissions, an unencrypted database.
A sound cloud migration strategy therefore bakes security into every phase rather than bolting it on at the end. Concretely, that means:
- Least-privilege identity. Grant the minimum access each user and service needs, prefer short-lived credentials and roles over long-lived keys, and audit permissions regularly. Identity is the new perimeter.
- Encryption everywhere. Encrypt data at rest and in transit by default, and manage keys deliberately. This is table stakes and usually a compliance requirement.
- Network segmentation. Use private networking, security groups and segmentation so that a compromise in one workload does not open the whole estate. Expose only what genuinely needs to be public.
- Data residency and compliance. Know where regulated data is legally allowed to live, and choose regions accordingly. This is often the deciding reason a particular workload is retained rather than migrated.
- Continuous posture management. Configuration drifts. Automated scanning for misconfigurations, logging and monitoring, and alerting on anomalous access keep small mistakes from becoming breaches.
These concerns intensify when part of your team, or your migration partner, sits in another country, because you are extending trust across organisational and geographic boundaries. The controls that make that safe, from access governance to code and data handling practices, are worth understanding in their own right, and we cover them in our guide to data security in offshore development. Treated seriously, distributed delivery is not less secure; it simply demands that the controls be explicit rather than assumed.
Choosing a cloud migration partner
Few teams have spare in-house capacity with recent, hands-on migration experience across the full range of the 6 Rs, which is why most organisations bring in help for at least part of the journey. The partner you choose shapes the outcome as much as the strategy itself, so evaluate candidates on substance rather than logos.
Look for a partner who begins with assessment rather than jumping straight to a proposal to rebuild everything, because the ones selling a predetermined answer have not yet listened to your problem. Look for genuine depth across the 6 Rs, not just the refactoring that bills the most hours, and for the honesty to tell you when the right move is to retain or retire rather than migrate. Ask how they handle the unglamorous middle of a project, the data reconciliation, the parallel runs, the rollback rehearsals, because that is where migrations are actually won or lost.
Just as important, insist on clarity about what you own at the end. A trustworthy partner hands over source code, infrastructure definitions and documentation so that your team can operate and evolve the estate without being permanently dependent on them. If deliverables, intellectual property and the handover are vague in the contract, expect them to be vague in practice. For a fuller framework on vetting external teams, our guide on how to choose an offshore software development company applies directly to migration engagements as well as to greenfield build.
How CIT builds with this
CIT is a Vietnam-based software company, founded in 2015, with offices in Ho Chi Minh City (Thu Duc) and Dong Nai, working with clients across the United States, Singapore and beyond. On cloud migration engagements we start where a good strategy should, with a thorough assessment of your estate and its dependencies, and we assign each workload the right R rather than pushing a one-size answer. Sometimes that means telling a client that a workload is best retained for now, or retired outright, because our job is the outcome, not the invoice.
Our teams work in clear English on GMT+7, overlap deliberately with client hours, and treat infrastructure as code and security as first-class concerns from the assessment phase onward. Every engagement ends with full source-code handover and IP assignment on delivery, including the infrastructure definitions and documentation your team needs to run the migrated estate independently. Whether you need a partner to run the whole migration or an experienced team to augment your own, our software outsourcing in Vietnam model is built to slot in without the overhead that makes offshore delivery painful. The technology choices underneath all of this connect back to a coherent foundation, which our pillar guide, what is a tech stack, sets out in full.
Frequently asked questions
What is a cloud migration strategy?
A cloud migration strategy is the overall plan for moving your applications, data and infrastructure to the cloud, including how far you change each workload. It is expressed through the 6 Rs, rehost, replatform, repurchase, refactor, retain and retire, applied per workload, together with a phased plan to execute the moves safely and a clear view of cost and security.
What are the 6 Rs of cloud migration?
The 6 Rs are the six standard paths for each workload. Rehost lifts and shifts with minimal change. Replatform swaps some components for managed services. Repurchase replaces a workload with a commercial product. Refactor re-architects it to be cloud-native. Retain leaves it where it is. Retire switches it off. Most portfolios use several of these at once.
Is migrating to the cloud always cheaper?
No. The cloud can be cheaper for elastic and bursty workloads, but a lift-and-shift with no optimisation often costs more than the hardware it replaced, because everything is metered and oversized resources keep billing. Model total cost of ownership over three to five years, right-size after migrating, and treat cost as an ongoing engineering discipline.
How long does a cloud migration take?
It depends entirely on the size and complexity of the estate and how many workloads you refactor rather than rehost. A single straightforward application can move in weeks; a large portfolio with re-architecture can run well over a year. Migrating in waves, starting with low-risk workloads, gives you value early instead of waiting for one distant cutover.
What is the biggest risk in a cloud migration?
Skipping the assessment phase. Teams that migrate before fully mapping their applications, data and dependencies discover undocumented integrations and shadow systems in production, where the cost of a surprise is highest. A complete inventory, a workload-by-workload R assignment, and a tested rollback plan for every wave prevent most serious failures.
Should we migrate everything at once?
Almost never. A big-bang cutover concentrates all the risk into one window with no room to react. Migrating in waves, proving the tooling on low-risk workloads first and validating each wave before the next, spreads the risk, lets the team learn, and keeps the business running throughout.
Plan your cloud migration strategy with CIT
A cloud migration strategy is worth only as much as its execution, and execution is where an experienced team earns its place. If you are weighing a move to the cloud, partway through one, or unsure whether you chose the right paths for your workloads, CIT can assess your estate, assign each workload the right R, and run the migration in safe waves with full handover of everything we build. Reach out to CIT to talk through your migration and turn a plan on paper into a cloud estate you can trust.
