Please note that this post, first published over a year ago, may now be out of date.
We regularly help SaaS businesses migrating their applications to the cloud. Whether it is a migration from on-premises, Heroku, or another cloud provider, we advise clients on the best way to move their workloads to AWS.
Our clients want to migrate to the cloud for all sorts of reasons: the current platform is a limiting factor to their growth; running their own on-prem server farm is expensive, inefficient, and non-compliant; CTOs want to leverage cloud native features and consolidate cloud usage with a single cloud provider, etc.
Whatever your reason may be, start by asking yourself the question:
Why do I want to migrate to the cloud?
This is a useful exercise as it helps thinking about a migration strategy and preparing a business case and a cloud migration plan.
In this article we want to focus on the different migration strategies on AWS, define them, and give you practical examples when they may be appropriate for you based on our experience helping SaaS businesses migrate.
The 7 R Framework
The 7 R Framework is a methodology for categorizing workloads that need to be migrated. It was originally conceived by Stephen Orban, then head of Enterprise Strategy at AWS, and later expanded by AWS. The framework highlights the technical complexities and the opportunities of a cloud migration and helps you define a strategy for your migration plan. It uses the catchy name of 7 R because it identifies seven migration strategies starting with the letter R:
In the next sections we’re going to explain each strategy and how it may apply to your business.
Re-host
The re-host strategy is also referred to as lift and shift. The focus here is on completing the migration quickly: treat the (AWS) cloud like a data center, and run the workload there.
This is a great fit if you have a target or deadline to meet. For example, you might have a contract for colocation with an agreed break clause. Migrating to the cloud without rearchitecting lets you leave the old contract behind.
Re-platform
Sometimes referred to as lift, tinker, and shift, this builds on the re-host approach by making targeted adaptations to the new environment.
Imagine you have existing databases running in a data center context. With minimal changes to the core architecture, you can migrate the on-premises databases to a database-as-a-service platform like Amazon RDS and reduce the amount of time and effort your engineers spend managing, upgrading, and backing up your database instances.
Re-architect
The re-architect strategy is also referred to as refactoring, by analogy with code refactoring.
If you already did a simpler migration to the cloud, such as a lift and shift, the limitations of that old architecture can add up. Once there’s a case to be made, an internal migration lets you swap out the old architecture whilst staying on the same cloud provider. You can also switch provider at the same time; for example, if you need flexibility around regional service that the existing offering can’t provide.
With code refactoring, you use unit and other tests to make sure that the rewritten code still works how you expect. Re-architecting for a cloud migration, you typically use a different set of tests to achieve the same overall aim. Use the existing integration tests, or write new ones, to show that the new architecture works the same way that customers expect. In an ideal migration, you’re able to switch architectures without customers even noticing when you do.
Relocate
The relocate strategy allows to transfer servers and databases within the cloud with minimal impact or disruption.
A frequent example that we’ve encountered with our clients is the migration of an RDS instance to another VPC or AWS account (and possibly encrypting the database if it was previously unencrypted). Another example is migrating several VMware workloads to VMware Cloud on AWS.
The idea is that you simply relocate your workloads and services within the cloud by leveraging the migration services offered by AWS and without applying significant changes or causing major downtime.
Re-purchase
If you work on a SaaS product yourself, you’ll know this: it can pay to get somebody else to run it. That’s not just true for your customers it can work for your own business.
We’ll explain this with an example SaaS app. Let’s say the provider offer software for opticians. There’s a component that renders PDFs, and all it’s used for is to make a printable wall calendar that customers can order. You figure out that you can sign up for a PDF rendering API that costs pennies per click, and can get rid of some problematic code. The actual printing and shipping has always been outsourced so it’s an easy change.
You get less code to look after and fewer things to fix. Buying in an undifferentiated or widely-used API frees your team to focus on delivering value-added service to customers.
As a leading cloud provided, AWS offer a suite of services that might well replace something you already use—and at competitive prices. There are too many to list here; if you’re considering a migration, there’s a really good chance that you’ll find a good fit.
Retire
When you zoom in to look at specific components, you can move them as they are, you can re-architect them, and you can pay someone else to provide an equivalent.
Of course, you might not need to. If you’re using a cloud-native architecture, you can probably retire a custom service or application that you developed and that is now provided natively in the cloud.
Once you’ve modernised, you’ll probably find a few components you can stop using. These might be custom code like the PDF renderer or supporting infrastructure like a monitoring tool.
Cutting costs all the way to zero sounds appealing, right? It could well be an option.
Retain
The retain strategy is also referred to as ’re-visit’ or ‘do nothing’. If what you have isn’t broken, you don’t need to fix it. If it requires major refactoring before it can be moved and a large budget or timescale to re-architect it, park it for now and revisit it later.
This may also be your initial strategy for tackling complex and expensive migrations. Start your migration to the cloud with quick wins and low hanging fruits, e.g. migrating first what brings added value to our businesses and requires low effort. Once you’ve gathered experience within your team and demonstrated you can successfully migrate to the cloud, your CFO will be more likely to approve that expensive refactoring of a monolithic application that you’ve always wanted to do.
Our team knows how to manage the risks around moving data to the cloud. We also know how risky it can be if you don’t have a cloud copy of your critical data. Book a free chat to find out how we can help.
This blog is written exclusively by The Scale Factory team. We do not accept external contributions.
