The framework
Six decisions, one application at a time
The 6 R's are not six things you do to your IT estate. They are six answers to a single question that you ask about every application you own: what happens to this one? Rehost it, replatform it, repurchase it, refactor it, retire it, or retain it. Amazon Web Services formalised the list, building on the 5 R's that Gartner published in 2010, and it has since become the default vocabulary for cloud migration strategies across AWS, Azure and Google Cloud alike.
The value of the framework is that it forces the conversation to happen before anyone touches infrastructure. A company with 60 applications does not have one migration. It has 60 small decisions, and the cost of the whole programme is set by how honestly those 60 decisions are made. Get them right and the cloud bill drops. Get them wrong and you have paid to move a problem from a rack in your office to a rack you rent by the hour.
The six strategies at a glance
Rehost
Lift and shift. The application moves to a cloud virtual machine unchanged. Fastest path, lowest risk, least cloud benefit.
Replatform
Lift, tinker and shift. The core code stays, but the database or runtime moves to a managed service.
Repurchase
Drop and shop. You stop running the software and subscribe to a SaaS product that already does the job.
Refactor
Rearchitect the application for the cloud: containers, microservices, serverless. Highest cost, highest ceiling.
Retire
Switch it off. Nobody logs in, nobody reads the report, and it has been costing you a licence for years.
Retain
Leave it where it is, on purpose. Compliance, hardware dependencies or timing say not yet, and that is a valid answer.
Each strategy, and when it is the right one
Below is the practical version of each R: what it means in engineering terms, the kind of application it fits, and the price you pay for choosing it.
Rehost
You take the workload running on a server in your office and move it, unchanged, to a virtual machine in AWS, Azure or Google Cloud. The operating system, the middleware and the binaries all come across as they are. The application never learns it has moved. Tooling such as AWS Application Migration Service or Azure Migrate can move fleets of virtual machines in weeks. A typical example: a Dubai trading company running a Windows Server ERP on a box under the stairs, moved to a cloud VM before the lease on the server room ends. It is the right call when the deadline is hard, the application is stable, and nobody on the team has cloud-native experience yet. The cost of that speed is that you inherit every inefficiency you had, and you now rent it by the hour.
Replatform
Same application, better foundations. You keep the code but swap the parts underneath it for managed services: a self-managed SQL Server becomes Azure SQL Database or Amazon RDS, a file share becomes object storage, a hand-rolled load balancer becomes a managed one. A clinic in Bur Dubai moving its patient records system to a managed database, so backups and patching stop being someone's Thursday evening job, is replatforming. It is the sweet spot for most SMEs: real cloud benefits without a rewrite, and a manageable amount of testing. The trap is scope creep. Teams start tinkering and end up refactoring by accident, three months over budget.
Repurchase
You do not migrate the application at all. You cancel it and buy a SaaS product that does the same job. On-premises Exchange becomes Microsoft 365. A licensed CRM becomes a subscription. This is often the cheapest and most successful "migration" in the whole programme, because the vendor absorbs the infrastructure work. Our walkthrough of an Office 365 migration done step by step without downtime shows what that looks like in practice for a UAE business. The cost is control: you accept the vendor's roadmap, the vendor's data handling, and a licence fee that never ends.
Refactor
Rearchitecting. The monolith becomes services, the services go into containers, the batch job becomes a function that runs when a file lands. This is the only R that unlocks the full economics of the cloud, elastic scaling, pay only for what runs, deploy several times a day. It is also the most expensive, the slowest, and the easiest to get wrong. Refactor when the current architecture is measurably holding the business back: the platform cannot scale for the peak, releases take a fortnight, or a feature the market wants is impossible to build. If none of that is true, refactoring is engineering for its own sake.
Retire
The most underrated R, because it is the only one that makes the migration smaller. Every portfolio assessment turns up applications nobody uses: a reporting tool whose output goes to an inbox nobody reads, an integration for a system replaced two years ago, a departmental app built for a project that ended. Retiring them cuts migration scope, cuts licence spend and shrinks the attack surface. The blocker is rarely technical. It is that somebody sponsored that application once and does not want to be the person who killed it. Usage data settles the argument faster than a meeting does.
Retain
Deliberately leaving a workload where it is. Sometimes the reason is regulatory: the UAE Personal Data Protection Law, Federal Decree-Law No. 45 of 2021, governs how personal data of UAE residents is stored, processed and moved across borders, and sector rules go further. Health data has localisation requirements, and the Central Bank requires local storage of customer and transaction data for banks. Sometimes it is physical: a machine on a factory floor that no cloud has an equivalent for. Sometimes it is timing, you upgraded that hardware last year and the payback has not landed. Retain is not failure. It is the reason most UAE estates end up hybrid rather than all-in.
Comparing the six across the things that actually cost you money
| Strategy | Cost to execute | Complexity | Downtime risk | Performance gain | Scalability | Long-term maintenance |
|---|---|---|---|---|---|---|
| Rehost | Low | Low | Low, cutover only | Little to none | Limited, vertical only | High, debt travels with you |
| Replatform | Low to medium | Medium | Medium, needs a test cycle | Moderate | Good on the managed layers | Lower, cloud handles patching |
| Repurchase | Low upfront, ongoing licence | Low technically, high on change management | Low, data migration is the risk | Vendor-dependent | Handled by the vendor | Minimal for you |
| Refactor | High | High | Managed via parallel running | Large | Elastic, the point of the exercise | Low per unit, but you own the architecture |
| Retire | Near zero, saves money | Low technically, political in practice | None if dependencies are mapped | Not applicable | Not applicable | Removed entirely |
| Retain | No migration cost | Low now, deferred later | None | Status quo | Capped by your hardware | Unchanged, you still run it |
Decision checklist
Ten questions that pick the R for you
Run this per application, not per department. If you cannot answer a question, that gap is your next piece of discovery work.
- Who logged into it in the last 90 days? If the answer is nobody, the R is Retire.
- Does a credible SaaS product already do this job? If yes, price Repurchase before anything else.
- Does any regulator, contract or licence require the data to stay in the UAE?
- Does it depend on hardware, a dongle or a device that has no cloud equivalent?
- Is the vendor still supporting the version you run?
- What breaks if it is offline for four hours on a Friday night?
- What is it actually consuming: CPU, memory, storage, licences, and what does that cost today?
- Which other systems read from it or write to it?
- Is the current architecture blocking something the business has asked for?
- Does anyone in the team know how it works, or has that person left?
The assessment that comes before the decision
Discover
Inventory every server, application and licence, using automated discovery rather than a spreadsheet built from memory. Hidden dependencies live here.
Map and classify
Draw the dependency graph, classify data by sensitivity, and flag anything with a residency obligation before it reaches an architecture diagram.
Assign an R
Run Retire and Retain first: they shrink the scope for free. Whatever survives gets Rehost, Replatform, Repurchase or Refactor with a written reason.
Sequence the waves
Move something low-risk first to prove the runbook. Each wave needs success criteria, a rollback plan and a named owner in the business.
Why the sixth R behaves differently here
Most guides to the 6 R's are written for a company that can put its workload anywhere. In the UAE, geography is part of the architecture. Azure runs UAE North and UAE South regions, AWS operates a Middle East region, and where your data physically sits determines which of the six R's is even available to you.
- Classify data against the Personal Data Protection Law before you assign a single R.
- Check the service catalogue of the UAE region, not the global one, before you commit a wave to it.
- Healthcare, banking and government workloads often land on Retain or an in-country Replatform, not on a global public cloud.
- Hybrid is the normal outcome here, not a compromise.
The same six R's across AWS, Azure and Google Cloud
AWS
The framework originated here, and AWS added Retire in 2016 and Retain in 2017 to Gartner's original list. Rehost maps to EC2 and Application Migration Service, Replatform to RDS and Elastic Beanstalk, Refactor to ECS, EKS and Lambda. Large migrations here lean on Rehost and Replatform, with refactoring deferred until after the estate has landed.
Microsoft Azure
Microsoft's Cloud Adoption Framework uses the same vocabulary and splits Refactor further into Rearchitect and Rebuild. Rehost lands on Azure VMs via Azure Migrate, Replatform on Azure SQL and App Service, Repurchase usually on Microsoft 365. For most UAE SMEs already on Windows and Office, this is the shortest path.
Google Cloud
Same six decisions, different service names: Compute Engine for Rehost, Cloud SQL for Replatform, GKE and Cloud Run for Refactor. If you are still weighing platforms, our comparison of cloud platforms available in the UAE is the place to start.
Where migrations go wrong, and what to do instead
- Rehost becomes the default for everything, and the estate arrives in the cloud with all of its old inefficiency intact.
- Nobody runs the retirement conversation, so dead applications get migrated and billed.
- Cost is modelled on the monthly compute price, ignoring egress, support, licensing and idle resources.
- Data residency is treated as a checkbox at the end, and the programme stalls in review.
- The team has no cloud experience and learns on the production cutover.
- The R assigned in month one is treated as permanent.
- Rehost is chosen deliberately for wave one, with named candidates for refactoring in wave two.
- Retire and Retain are run first, because scope control is the cheapest saving available.
- Total cost of ownership is modelled over five years, with a FinOps owner watching spend from day one.
- Data classification and residency are designed in before the first architecture diagram.
- Skills gaps are closed with training or a partner before cutover, not after the incident.
- The portfolio is reclassified annually as the business and the platforms change.
One habit separates the migrations that land from the ones that drift: writing down why each application got the R it got. A one-line reason per workload turns an argument into a document, and it is the thing you will thank yourself for eighteen months later when someone asks why the payroll system is still on-premises.
Migration is also not a single event. A workload rehosted this year is a refactoring candidate in two years, and the discipline of ongoing managed IT services is what keeps that second conversation from being forgotten. Plan for backups and a tested rollback path at every wave, ideally with disaster recovery as a service in place before cutover rather than after.
Frequently asked questions
Is it 5 R's, 6 R's or 7 R's?
All three are the same idea at different levels of detail. Gartner published five in 2010. AWS added Retire in 2016 and Retain in 2017, which gives the seven you will see in AWS documentation. The 6 R's model, Rehost, Replatform, Repurchase, Refactor, Retire and Retain, is the version most teams use, because it covers every real decision without splitting hairs. IBM and Microsoft each publish slight variants, adding Relocate or separating Rearchitect from Rebuild. Pick one list, define the terms for your team, and stay consistent.
Which R is cheapest?
Retire, by a wide margin, because it removes cost rather than moving it. After that, Rehost is the cheapest to execute but often the most expensive to live with, since you keep paying for inefficiency every month. Refactor is the most expensive upfront and usually the cheapest to run at scale. The honest answer is that cost depends on the timeframe you measure: model five years, not the first invoice.
Can we mix strategies in one migration?
You almost certainly will. A typical UAE SME portfolio ends up with email and file sharing repurchased onto Microsoft 365, a handful of line-of-business servers rehosted, a database or two replatformed onto a managed service, a few forgotten applications retired, and one or two systems retained on-premises for residency or hardware reasons. A portfolio approach is the norm, not an exception.
How long does a migration take?
Assessment usually takes weeks rather than days, because dependency mapping is where the surprises live. Rehosting a fleet of virtual machines can then move quickly with the right tooling. Refactoring is measured in quarters. The variable that stretches timelines most is not technology, it is decision-making: how quickly the business can answer who owns each application and what it is for.
What are the biggest risks?
Data exposure during transfer, misconfigured access controls after cutover, unmapped dependencies that break something downstream, and cost overrun from unplanned egress and idle resources. Each has a standard control: encrypt in transit and at rest, apply role-based access and multi-factor authentication from day one, map dependencies with automated discovery, and put someone in charge of watching the bill weekly.
Do we have to keep our data in the UAE?
It depends on your sector and the data itself. The UAE Personal Data Protection Law governs the personal data of UAE residents wherever the controller sits, and specific sectors go further: health data carries localisation requirements and the Central Bank requires local storage of customer and transaction data for banks. Classifying your data before you choose a region, rather than after, is what keeps a migration out of a stalled regulatory review.
When does refactoring actually pay off?
When the current architecture is measurably costing the business something: the platform cannot handle peak load, releases are too slow to respond to the market, or a feature customers want is impossible to build on the existing design. If you cannot name that cost, refactoring is usually over-engineering, and a rehost now with a refactor later is the better sequence.
Do we need an external partner?
Not always, but the gap is rarely tooling. It is experience of the failure modes. If your team has not run a portfolio assessment before, has no cloud-native skills in house, or is working under a hard deadline such as a data centre exit, a partner who has done it repeatedly will pay for themselves in the mistakes you do not make.
Working out which R fits your estate?
Rounak Computers has been assessing and migrating UAE workloads since 2004, as a Gold partner of Microsoft, Huawei and Amazon, with certified in-house engineers and vendor-neutral advice. If you want a second opinion on your portfolio before you commit, start with our cloud migration services in Dubai.
