Moving your business to the cloud is rarely as simple as lifting everything across and hoping for the best. The reality is that different workloads have different needs, different risk profiles, and different costs – and treating them all the same is one of the most common mistakes we see when advising on cloud migration strategies.
That’s where the 7 Rs framework comes in. Originally developed by Gartner and later adopted by AWS, the 7 Rs give you a structured way to think about how each application or workload in your environment should be handled during a migration.
1. Retire
Some applications simply don’t need to move. If a system is rarely used, no longer fit for purpose, or has been replaced by another tool, the right answer is often to decommission it entirely. Migration is a good opportunity to audit what you actually use – and cut the dead weight.
2. Retain
Not everything should move to the cloud right now. Some workloads have regulatory constraints, hardware dependencies, or simply aren’t ready. Retaining them on-premise – at least temporarily – is a legitimate strategy, not a failure. A good migration plan acknowledges this rather than forcing everything across at once.
3. Rehost
Often called “lift and shift,” rehosting means moving an application to the cloud with minimal changes. It’s fast, relatively low risk, and can deliver quick wins – particularly useful when you’re under time pressure or working to a tight budget. The trade-off is that you’re not taking full advantage of cloud-native features.
A lift and shift migration can significantly reduce infrastructure costs in the first year, simply by moving away from on-premise hardware refresh cycles to a pay-as-you-go model. However, without right-sizing your instances at the point of migration, you can end up paying for more compute capacity than you actually need. AWS Compute Optimizer can analyse your usage and recommend the right instance types before you go live.
4. Relocate
Similar to rehosting but specific to moving workloads between cloud environments – for example, migrating from one hypervisor platform to AWS without changing the operating system or application layer. It’s a fast path that preserves your existing setup while changing where it runs.
5. Repurchase
This means moving from a current application to a different product – typically replacing a legacy on-premise system with a SaaS equivalent. A common example is moving from an on-premise CRM to Salesforce, or from a local email server to Microsoft 365. It requires change management but often delivers significant long-term benefits.
6. Replatform
Sometimes called “lift, tinker, and shift,” replatforming involves making a small number of optimisations during migration without changing the core architecture. For example, moving a database to a managed cloud database service to reduce administration overhead, without rewriting the application itself. You get some of the cloud benefit without the cost of a full rebuild.
Moving a self-managed database to a service like Amazon RDS or Aurora can eliminate the majority of routine database administration work – patching, backups, failover, and replication are all handled automatically. For small and medium businesses without a dedicated DBA, this is often one of the highest-value changes in a migration, and it requires far less rearchitecting than most people expect.
7. Refactor / Re-architect
This is the most ambitious option – redesigning an application from the ground up to take full advantage of cloud-native features. It typically delivers the best long-term performance, scalability, and cost efficiency, but it requires the most time, skill, and investment. It’s the right choice when an application is genuinely strategically important and the existing architecture is holding you back.
Applications rebuilt as microservices and deployed using containers – such as via Amazon ECS or EKS – can be scaled at the individual component level rather than as a whole. This means a spike in one part of your application, such as a checkout process during a busy period, doesn’t require you to scale your entire infrastructure. Done well, this can significantly reduce both cost and response time under load.
Which Cloud Migration Strategies are right for you?
The honest answer is that most migration projects use several of them. A well-planned migration maps each workload to the most appropriate strategy – retiring what’s redundant, rehosting what’s time-sensitive, and refactoring what matters most to the business.
In our experience, the biggest risk isn’t choosing the wrong R – it’s not having a clear strategy at all. Migrations that start without a workload-by-workload plan tend to run over time, over budget, and with more disruption than necessary.
If you’re starting to think about cloud migration and aren’t sure where to begin, Base3 can help you map your environment and define a cloud migration strategy that’s practical, phased, and built around your business. Get in touch to start the conversation.