Seven common patterns for AWS migration: “The 7 R’s”

There’s more than one way to migrate an app. Common migration patterns usually follow one of six basic patterns—but when you migrate to AWS, you’ll gain a seventh option (relocate), rounding out what AWS refer to as “The 7 R’s.”

Creating a detailed strategy that identifies the best pattern(s) for your workloads is essential to accelerating your journey into the cloud and achieving your desired business objectives. Below are the details on each of these seven patterns as AWS see them adopted most often by customers.

1. Rehost – Also known as “lift-and-shift”

In a large-scale migration scenario, where you need to migrate and scale quickly to meet a business case—such as a data centre lease termination – the majority of workloads are rehosted.
Most rehosting can be automated with tools such as AWS Application Migration Service.

2. Re-platform – Sometimes referred to as “lift-tinker-and-shift”

This entails making a few cloud optimisations in order to achieve tangible benefits but without changing the core architecture of the application. For example, if you’re managing a messaging broker today, you can easily replace seven common patterns for migration: “The 7 R’s” with the fully managed Amazon MQ service—without rewriting your applications or paying for third-party software licenses. Or, if you’re migrating a Windows-based application that requires file storage, you can use the fully-managed Amazon FSx for Windows File Server.

To reduce the amount of time you spend managing database instances, you can move to a database-as-a-service offering such as Amazon Relational Database Service (Amazon RDS). When moving from one database source or version to a new platform or software version, AWS Database Migration Service keeps the source database fully operational during the migration, enabling near-zero downtime during the cutover.

3. Refactor – Change the way the application is architected and developed.

This is usually done by employing cloud-native features such as building a data lake. Typically, refactoring (or rearchitecting) is driven by a strong business need to add features, scale, or improve performance that would otherwise be difficult to achieve in the application’s existing environment.

If your organisation is looking to boost agility or improve business continuity by moving to a service-oriented architecture (SOA), this strategy may be worth pursuing—even though it is often the most expensive solution.

4. Relocate – Move vSphere-based applications to AWS without application changes

VMware Cloud on AWS allows you to quickly relocate hundreds of applications virtualized on vSphere to the AWS Cloud in just days and to maintain consistent operations with your VMware Cloud Foundation-based environments. Once in the AWS Cloud, your applications are easier to optimise or rearchitect to take advantage of the breadth and depth of AWS services.

5. Repurchase – Replace your current environment, casually referred to as “drop and shop”

This is a decision to move to a newer version of software or purchase an entirely new solution. You may also be looking for a new software licensing model that allows you more flexibility to match your business needs. As an example, Amazon Connect can be purchased to replace your current contact centre application.

6. Retain – Do nothing, for now

You may have portions of your IT portfolio that you are not ready to migrate or believe are best kept on-premises. Keep in mind that, as more of your portfolio moves to the cloud, allocation of data centre expenses across fewer workloads may eventually drive a need to revisit the retained workloads.

For workloads that remain on-premises, AWS Outposts brings the same hardware and software in the AWS Cloud, the same services and APIs, the same management tools, and the same support and operating model to virtually any data centre, co-location space, or on-premises facility. With AWS Outposts, you have a truly consistent hybrid cloud, so you can develop once and deploy across AWS Outposts on-premises or in the AWS Cloud without having to recertify your applications.

7. Retire – Decommission or archive unneeded portions of your IT portfolio

During the Assess phase, you may come across applications that are no longer being used. By rationalising your IT portfolio and identifying assets that are no longer useful and can be turned off, you can strengthen your business case and direct your team’s attention toward maintaining the resources that are more widely used.

Start your cloud migration journey today. Contact FITTS and speak to an expert.

James Haworth

James has 20 years of experience working within global businesses to deliver strategic digital and infrastructure transformations. With clients spanning Financial Services, Energy, Telecoms, Aerospace and Defence he has a broad array of knowledge and experience across multiple sectors. With a specialisation in security, James has been instrumental in defining, delivering and overseeing the delivery of digital strategies and is a sought-after advisor in a CIO/CTO advisory capacity.
As one of our founders, and our managing director, James focuses his time on delivering the FITTS mission, vision and value promise. James’ visionary and forward-thinking approach is valued by our partners and customers alike. He participates on strategic product boards to help define the future roadmap of existing platforms, alongside new products and services.
As well as our technology and strategy delivery, James is passionate about Diversity and Inclusion and partnering with organisations to ensure that their digital platforms are not just innovative but prioritise people-first.