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.

The post Cloud Migration Strategies: The 7 Rs Explained appeared first on Base3 Solutions Ltd.

AWS has a lot of partners. Not all of them are the same.

Amazon Web Services operates one of the largest partner networks in the world. Thousands of companies globally carry some form of AWS partner status – from global system integrators with tens of thousands of staff, to smaller specialist firms working with SMEs.

The AWS Partner Network (APN) has different tiers and specialisations, and the requirements to achieve and maintain them are not trivial. Partners are assessed on technical capability, certified staff, and – critically – customer outcomes. It isn’t a badge you buy. It’s a status you earn and maintain.

So what does it mean in practice for your business?

Working with an AWS Partner rather than a generalist IT provider means a few specific things:

Verified technical expertise. AWS Partners are required to maintain a minimum number of certified engineers. Those certifications aren’t easy to obtain – they require deep, demonstrable knowledge of AWS services, architecture, and best practice.

AWS currently offers over 12 specialisations within its Partner Network, covering areas including DevOps, security, data and analytics, and migration. Achieving a specialisation requires partners to demonstrate not just certified staff, but validated customer success stories reviewed by AWS – meaning the specialisation reflects real delivery experience, not just theoretical knowledge. You can explore the full AWS Partner Network and verify partner status directly at aws.amazon.com/partners.

Access to AWS resources. Partners have direct relationships with AWS, including access to technical support, architectural guidance, and in some cases, funding programmes that can offset the cost of migration or proof-of-concept work for eligible customers.

Accountability. AWS monitors partner performance and customer satisfaction. A partner that consistently delivers poor outcomes risks losing their status. That accountability doesn’t exist with an uncertified provider.

Up-to-date knowledge. AWS releases hundreds of new features and services every year. Certified partners are required to keep their knowledge current – which matters when you’re making decisions about how to architect your cloud environment.

The difference between knowing AWS and working in AWS

This is something we talk about openly at Base3. The AWS certification path is rigorous and valuable – it gives engineers a thorough grounding in how AWS services work and how they’re designed to be used together.

But certifications teach you what the services are called and what they do. Real environments teach you what trade-offs actually matter.

Many of the issues we encounter in AWS environments aren’t caused by a lack of knowledge. They’re caused by things like over-engineering, unclear ownership, and security decisions that were deferred until later and then never revisited. AWS gives you enormous flexibility and a huge number of tools – but good architecture is often about restraint. Choosing the simplest thing that works, and being clear about responsibility and security from day one.

That perspective only comes from experience. It’s what separates a partner that can pass an exam from one that can genuinely help your business make good decisions.

What to look for when choosing an AWS Partner

Not every AWS Partner will be the right fit for your business. When evaluating options, it’s worth asking:

• Do they have experience with businesses of a similar size and complexity to yours?
• Can they explain their approach in plain language, without hiding behind jargon?
• Do they take time to understand your business before recommending a solution?
• Are they transparent about cost, timeline, and risk?
• Do they have references or case studies from comparable organisations?

A good AWS Partner should feel like an extension of your team – not a vendor trying to sell you the most complex solution possible.

Base3 is an AWS Partner in the UK

As an AWS Partner in the UK, Base3 has completed the full certification path and brings real-world experience to every cloud project we work on – whether that’s a first migration, an architecture review, or ongoing cloud management.

But more than the certifications, we bring real-world experience of what works in practice for UK businesses. If you’re considering AWS and want to talk through your options without any obligation, we’d be happy to help.

The post What It Means to Work With an AWS Partner in the UK appeared first on Base3 Solutions Ltd.