Cloud Migration Strategy: How to Apply the 7 Rs Workload by Workload

Most migration plans fail at the same spot. Someone draws one arrow from "our server room" to "the cloud" and calls it a cloud migration strategy. Then the ERP database, the label printer server and the intranet nobody opens all get treated the same way.

Short answer: a cloud migration strategy isn't one decision. It's a separate decision for every workload, picked from seven options called the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform and refactor. Work through them in that order, cheapest exit first, write down why each workload got its R, and only refactor when the architecture itself is the problem.

This guide gives you the decision order we'd use on a real server list, a worked example with nine workloads, and the Canadian rules that can flip an answer, like Quebec's Law 25 and the way Azure pairs its two Canadian regions.

Holding Quebec personal information? Take our free Quebec Law 25 readiness check before you pick a cloud region. It takes a few minutes and shows the gaps a privacy impact assessment will ask about.

What is cloud migration?

Cloud migration is moving applications, data and servers from where they run today (a server room, a colocation rack or another cloud) into a cloud provider such as AWS or Azure. It also covers the move between clouds, and the reverse trip back on premises.

The "on premise to cloud migration" most Canadian firms mean is simple to describe. Your servers stop living in a closet in Mississauga or Laval. They run in a provider's data centre in Canada, and you pay for what you use instead of buying hardware every five years.

What is a cloud migration strategy?

A cloud migration strategy is the written decision about what happens to each workload: move it, change it, replace it, keep it or switch it off. AWS describes a migration strategy as "the approach used to migrate a workload into the AWS Cloud." Note the singular. One workload, one approach.

That's the part generic guides skip. Your company doesn't get a strategy. Each workload does. The company-level document is just the table that collects those decisions, plus the reasons behind them.

The benefits of cloud migration are real, but they're uneven. Moving a stable file share buys you less patching and no hardware refresh. Moving a database to a managed service can remove backup and patching jobs your team runs by hand. Moving a fragile custom app as-is buys you very little, because the fragility comes along. That's why the choice has to happen per workload.

What are the 7 cloud migration strategies?

The seven cloud migration strategies are the 7 Rs from AWS's prescriptive guidance. Here's what each one changes and when it fits.

AWS's own guidance names rehost, replatform, relocate and retire as the common strategies for large migrations (AWS Prescriptive Guidance). That's worth sitting with. Four of the seven involve little or no code change.

What are the 5 Rs (and the 6 Rs) of cloud migration?

The 5 Rs are the original model from Gartner: rehost, refactor, revise, rebuild and replace. The 6 Rs came from AWS. In a 2016-11-01 post, Stephen Orban described six strategies that "build upon the 5 R's that Gartner outlined" (AWS Executive in Residence blog). AWS later added relocate to make seven. Microsoft uses eight.

Sources disagree on the dates. The AWS post and the trade press of the time put Gartner's list in 2011, IBM says 2010, and IBM also claims AWS added retain in 2017, even though the 2016 AWS post already lists it. The names matter less than the mapping, so here it is in one table.

Three quick reads of that table. First, watch the word "refactor." In Gartner's original wording it meant moving an app onto a provider's platform (PaaS), which is closer to what AWS now calls replatform. Mix the two vocabularies in one plan and people will argue about the wrong thing. Second, the "6r cloud migration strategy" you'll see in older courses is just the 7 Rs minus relocate. Third, Microsoft splits AWS's single refactor bucket three ways: refactor (tidy the code), rearchitect (change the design) and rebuild (start over cloud-native) (Microsoft Cloud Adoption Framework). If your team works in Azure, that split is more useful. It stops a two-week code clean-up and a full rewrite from sharing one label.

Which cloud migration strategy requires the most work to perform?

Refactor, also called re-architect, requires the most work. AWS calls it "the most complex and costly of the migration strategies because you modernize the application during the migration." Even in 2016, the original AWS post said it "tends to be the most expensive."

If you use Microsoft's eight, rebuild sits at the far end. It means rewriting the workload from scratch on cloud-native services.

Here's the practical rule. For a large move, AWS recommends you rehost, relocate or replatform first and modernise after the migration is done. Refactor during the move only when the other options aren't acceptable. Doing both at once doubles the number of things that can break on cutover night.

How do you pick the right R for each workload?

Ask seven questions in a fixed order, and stop at the first yes. The order runs from cheapest exit to most work, so you only spend effort where nothing lighter fits.

Does anyone still use it? (Retire)

Start by killing things. AWS gives concrete signals: average CPU and memory use under 5% is a "zombie," 5 to 20% over 90 days is "idle," and no inbound connection for 90 days is a strong hint too. Pull those numbers from your monitoring before anyone argues from memory. Every retired server is one you don't have to migrate, secure or document.

Is there a reason it can't move yet? (Retain)

Retain is a valid answer, not a failure. AWS lists data residency, special hardware with no cloud equivalent (a plant-floor machine, a label printer cluster), a system you upgraded last year, and a vendor whose SaaS version isn't out yet. Write the reason and a review date beside it. "Retain until 2027-06" is a plan. "Retain" on its own is a shrug.

Does a SaaS product already do this job? (Repurchase)

Email, HR, CRM and file sharing rarely deserve a migration project now. If a SaaS product covers the job with little customisation, buy it and migrate the data instead of the server. The real work is in data mapping, single sign-on and training, so budget time for those.

Is it staying on VMware? (Relocate)

Relocate moves whole groups of servers at the hypervisor level to a cloud version of the same platform. AWS's guidance stresses that it needs no new hardware, no rewrite and no change to how you operate. It's the fastest route if you've decided to keep your virtualization platform.

The trigger is often a support date. VMware vSphere 7 and vSAN 7 reached end of general support on 2025-10-02 (Broadcom KB 415405). If you're still on 7, you're deciding anyway: upgrade in place, relocate, or rehost onto native cloud VMs and leave VMware behind. Our virtualization team can help you make that call before the servers move.

Will it stay unchanged for two years? (Rehost, the "lift and shift")

Rehost is lift and shift: the same server, the same OS, now on cloud VMs. Microsoft's test is a good one. Rehost only when you're confident the workload won't need modernising within two years, and "don't rehost problematic workloads," because their problems move with them.

On AWS, the replication tool for this is now called AWS Transform MGN. It was renamed from Application Migration Service on 2026-06-08 (AWS announcement). On Azure, it's Azure Migrate.

Would a managed service remove work you do by hand? (Replatform)

Replatform keeps the application but swaps the parts you babysit. The classic case is a SQL Server database moving to a managed database service, so patching and backups become the provider's job.

This is where rehost vs replatform gets decided. If your team patches that database every month and restores it twice a year, replatform. If it's quiet, rehost it and revisit later. One date makes the choice urgent: SQL Server 2016 reached end of extended support on 2026-07-14 (Microsoft lifecycle). A 2016 database that's still in service is a replatform candidate right now, not in two years.

Is the architecture itself the problem? (Refactor)

Refactor last, and only with a business reason. Good reasons from AWS's list: a monolith that's slowing every release, a legacy app nobody can maintain, test coverage so low that every change is a gamble. "It would be nice to use containers" isn't one of them.

The decision order isn't a scoring model, and it won't replace a dependency map. But it does make every answer explainable to a CFO in one sentence. If you'd rather have senior engineers run it on your inventory, that's what our cloud migration services start with.

What does a workload-by-workload plan look like?

Picture a 70-person distributor with offices in Mississauga and Laval. It's a composite, not a client. It runs a small server room, a VMware 7 cluster and a mix of Windows servers. Here's how the decision order sorts its nine workloads.

Look at what didn't happen. Only one workload is a refactor candidate, and even that one waits. Three workloads never become migration projects at all. That's how the decision order trims scope. If your own list sits in a GTA server room, our Toronto team can walk it with you on site.

The portal row is where Canadian law steps in, which brings us to the next question.

Where do Canadian rules change the strategy?

Three Canadian factors can change the R, not just the paperwork: who's accountable for the data, which province it's leaving, and which region the provider copies it to behind the scenes.

PIPEDA keeps you accountable. The federal privacy commissioner's guidance treats a transfer to a service provider for processing as a "use," not a disclosure. Your organisation stays accountable for the information, and you must tell people their data may be processed in another country and could be accessed by that country's authorities (OPC guidelines on processing personal data across borders). Picking a Canadian region doesn't remove that duty if any part of the service, like support or logging, runs elsewhere.

Quebec's Law 25 adds a step before data leaves Québec. Section 17 of Quebec's private-sector privacy act says a business must do a privacy impact assessment "before communicating personal information outside Québec." It must weigh the data's sensitivity, the purposes, the protection measures and the legal framework where the data goes, and then sign a written agreement (LégisQuébec, P-39.1). Toronto counts as outside Québec. So a Laval firm putting Quebec customer data in a Toronto region needs that assessment first. Our privacy impact assessment team runs these, and our Montreal engineers work the Quebec side.

Region pairing can move data without anyone deciding to. Azure's two Canadian regions are Canada Central in Toronto, with three availability zones, and Canada East in Quebec, with none. Each is the other's pair (Azure regions list). Choose Canada East to keep Quebec data in Quebec, then switch on geo-redundant backup, and your copies replicate to Toronto. AWS has Canada (Central), on by default, and Canada West (Calgary), which you must opt into (AWS Regions).

So how do these rules change the R? Sometimes they turn a rehost into a retain until the assessment is done. Sometimes they push a workload to a region without availability zones, which changes the resilience design. And sometimes they make a SaaS product (repurchase) impossible, because the vendor can't commit to Canadian hosting. Check residency before you assign the R, not after. Federal departments have their own cloud rules, which our Ottawa government IT team handles separately.

On funding: we don't know of a federal grant aimed at cloud migration today. If the move is part of a genuine innovation project, ask an NRC IRAP advisor about intake rather than counting on it.

What are the five phases of cloud migration?

There's no single official five-phase model. AWS uses three phases: assess, mobilize, and migrate and modernize. Microsoft's Cloud Adoption Framework uses seven: strategy, plan, ready, adopt, govern, secure and manage (Microsoft CAF overview).

When people ask for five phases, they usually mean this grouping:

1. Assess. Inventory every server and app, collect real usage data, map dependencies.
2. Plan. Assign an R to each workload and group them into waves.
3. Prepare the landing zone. Accounts, identity, network, security policies and logging in your chosen Canadian region.
4. Migrate. A low-risk pilot wave first, then the rest in groups, each with a rehearsed cutover and a rollback plan.
5. Optimise and run. Right-size after a full business month, switch off the old servers, then modernise what you rehosted.

The 7 Rs live inside phase 2. That's why a weak assessment in phase 1 poisons the whole plan.

What are the 7 steps of a cloud migration model?

The 7 steps aren't a formal standard either. Here's a seven-step version that works as a cloud migration checklist for one workload at a time:

1. Name the owner. One business person who can say yes to downtime.
2. Measure use. At least 30 days of CPU, memory and connection data.
3. Map dependencies. What it talks to, and what talks to it.
4. Check residency. What personal information it holds, from which province, and where backups and logs will land.
5. Assign the R and write why. One sentence. If you can't write it, you haven't decided.
6. Plan the cutover. Data sync method, test plan, rollback trigger, rollback owner.
7. Close it out. Confirm backups restore in the new home, then decommission the old server and update the inventory.

Run those seven steps for every workload, and the five phases above take care of themselves.

What usually goes wrong with a cloud migration strategy?

Four cloud migration challenges cause most of the pain, and each one traces back to a skipped step above.

• Undocumented dependencies. A report server that quietly reads the ERP database at 2 a.m. breaks the morning after cutover. Step 3 catches it.
• Data bigger than the window. Copying 2 TB over a 500 Mbps link running flat out takes about 9 hours, before any retries. Sync the bulk early and move only the changes on the night.
• Rehosting the broken. Microsoft's warning is blunt: a problematic workload rehosted is still problematic, now with a cloud bill.
• Modernising mid-move. Mixing a refactor into the migration wave is the most common way schedules slip. AWS's advice to modernise after the move exists for this reason.

Before go-live, run a cloud security assessment checklist against the new environment, and confirm your backup and disaster recovery design covers the cloud copies, not just the old server room.

FAQ

Rehost vs replatform: what's the difference?

Rehost moves the server unchanged. Replatform moves it and swaps one or more parts for a managed service, usually the database. Rehost is faster. Replatform removes ongoing work. If the part you'd swap needs constant hand care, replatform.

Is lift and shift a bad strategy?

No. It's the right call for stable workloads that won't change for a couple of years, and AWS lists it among the common strategies for large migrations. It's the wrong call for fragile workloads or anything you plan to rewrite soon.

Can a hybrid cloud migration be the end state?

Yes. Retain is one of the 7 Rs for a reason. Plenty of Canadian firms keep plant-floor systems, special hardware or residency-bound data on premises and run everything else in the cloud. Plan the network and identity links between the two as permanent, not temporary.

Does the strategy change between AWS and Azure?

The decision order doesn't. The labels do: AWS uses seven Rs and Microsoft uses eight. The tools differ too (AWS Transform MGN on AWS, Azure Migrate on Azure). The regions differ as well, which matters for the residency questions above. If you're comparing the two for a small estate, our guide to choosing a cloud server for small business covers the trade-offs. If you're already on AWS, start with our AWS consulting page.

What happens after the migration?

Someone has to run it. Either your team takes over with the documentation from the move, or a provider runs it for you. Our guide to managed cloud services covers what's included and when to keep cloud in-house.

Bottom line

A cloud migration strategy that fits on one slide is usually wrong. Pick an R for each workload, in order from retire to refactor, and write one sentence on why. Check Canadian residency before you assign the R. And keep refactoring out of the migration wave unless the architecture is the thing that's broken.

Want a second opinion on your server list? Send it our way. A senior engineer, not a salesperson, will read it and tell you which workloads should move, which should stay, and which should be switched off. Contact SMEnode to start.