Cloud Migration in Seven Steps (7 R’s)

by

You can download the slides as a PDF here:

AWS-Migration-StrategiesDownload

Hi, everyone. Thushyanthan here. In this tutorial, I want to share with you some cloud migration strategies for how to move your on-premise workloads to the cloud. 

Many people are familiar with the top three cloud vendors and they are AWS, Azure and Google Cloud Platform.

Other players in the public cloud arena are vendors like Rackspace, Linode, Heroku, and a variety of others. They have services that differentiate themselves from the top three major players.

The rest of this presentation will focus on the migration process and the 7R strategies developed by AWS in their best practices white papers. 

Migration Event Considerations 

When a migration happens to an organization that is an extremely significant event, not just for the organization itself, but for the people that make up the organization. Here are just a few considerations for when a migration might be triggered. 

Some examples of these triggers are things like leases for your data center. Your organization may wish to reconsider renewing your lease depending upon other factors and considerations outside of just cost.

Other considerations could be upgrades to your aging hardware, or it could be licensing, or it could be compliance due to the industry changes or governmental regulation changes.

Additionally, there may be other new opportunities that may warrant consideration of a migration to the cloud.

Some things are additional funding streams, or a few other opportunities that are not listed here.

In addition to the opportunities that may trigger a migration event consider also that there may be threats, internal or external, that may cause the organization to consider migrating to the cloud.

Cloud Migration Steps 

AWS has developed a two-pronged approach to cloud migration and that is with its 7R strategies for cloud migration, as well as the bigger migration process and the workflow.

The 7Rs are listed in the yellow boxes and they are: Retain, Retire, Relocate, Rehost, Replatform, Repurchase, or Refactor.

The migration and process workflow begins with planning, making a decision on whether or not you are going to migrate the application to the cloud, doing the actual migration, and then validating the migration, testing it ensures that it meets your business requirements and then finally deploying it into production. This is a continual process that needs to be undertaken for every application that is in your business’ portfolio or in your business unit’s portfolio.

Before I continue, I want to talk about the two Rs that don’t necessarily warrant moving into the cloud. And they are determined by the question whether or not you’re going to actually migrate the specific application into the cloud. 

If you choose not to, there are two options that you have. You can ask yourself another question, whether or not this application is needed for your business.

  • If it’s not needed, then a very valid approach is to “Retire” the application in full and then stop this process for this particular application.
  • If the application is needed for whatever business purposes or business processes, then you might want to consider retaining that application and then revisiting whether or not, it needs to migrate to the cloud at a future point. 

For all the other applications that you are going to be moving to the cloud, you have the choice of five different options: whether you’re going to Relocate, whether you’re going to Rehost, whether you’re going to Replatform, whether you’re going to Repurchase, or whether you’re going to Refactor.

Let’s take a look at some of these options now. 

Relocate 

The first option that you may wish to consider is the relocation option.

Now, this is relatively new because AWS has had a strong partnership with VMware. And because of this partnership, AWS and VMware is very confident that you can spin up your vSphere workloads directly on the cloud using bare metal instances.

One advantage to this is that you can use your existing licensing for on-premises and migrate directly to the cloud. This is one opportunity for you to get out from the physical data center that you may have to manage, that you may have to lease, and onto the cloud, where a lot of this overhead of management is already taken care of.

Rehost 

The next option that you have is to rehost your application.

This is known as lift and shift. The lift and shift process can either be a manual or managed migration.

One of the benefits to lift and shift is that, not only does it provide you with faster migration, it allows you, depending upon which workload you migrate, it allows your team to quickly get up to speed, have a lot of learning and develop experience and expertise in migrations so that future applications can be migrated with less overhead.

This strategy allows for cloud optimizations at a future point when the business needs determines it.

Rehost – AWS Application Migration Service 

An example of an automated lift and shift strategy is provided by AWS’s application migration service.

The gist of it is you install an agent onto your source servers, and then you will enable the replication automatically and then, from the dashboard, you can choose to launch your instance into the cloud, after which you will perform your tests and then finally execute cutover and do what else you need to do.

This is a really nice way to take care of relatively modern hardware and relatively modern operating systems and migrate them in an automated fashion and simplify your workflow that way.

Replatform 

Another strategy that may be viable for the application might be to replatform.

This is also known as lift, tinker, and shift. It’s very similar to rehosting, which is lift and shift, but you are optimizing for some cloud-native functionality.

An example of this is the database migration to a cloud-native platform.

The immediate benefit to replatforming as a strategy is the fault tolerance that you get from a cloud platform, things like multi-AZ.

Additionally, updates and automated backups are already taken care of for you freeing your team to focus on other business objectives 

As you can see, it is relatively straightforward to migrate an Oracle database from your on-premise workloads by using the AWS data migration service. This will create an Amazon RDS instance for your database.

Other databases are supported such as MySQL database to Aurora database. Once again, the benefits are immediate; fault tolerance, updates, and automatic backups.

Repurchase 

Next, we’ll get into the repurchase option.

This option is essentially moving your self-hosted, on-premise workloads into a Software as a Service or commercially off-the-shelf applications.

In a similar way to replatforming, this will also free up your team to focus on more immediate business needs and offload the management of commonly used applications such as office suites, communication platforms, ticketing platforms, or video conferencing platforms.

This gives your team a lot more flexibility and a lot more capacity to focus on the needs of the business during the migration.

Refactor 

Now we get into the refactor strategy. This is also known as rearchitecting the application.

For some members of the team, or of the business, this can be fun. This is where you and your team get to redesign the application and ensure that it works in a cloud-native format.

One of the caveats to this is that the business must understand that refactoring an application, whether it’s modern or legacy, is often more complex than it is anticipated. 

What organizations typically find is that there is a significant investment in time, money, and team development that’s needed for a full refactor of the application into its cloud-native format.

Not only do you have to adopt the full software development life cycle, but you also have to ensure that it integrates with existing business processes, whether they are legacy or modern.

Refactor – Migration Hub Refactors Spaces 

AWS has recently introduced a service known as AWS Migration Hub Refactors Spaces.

This allows your team to take your legacy application and refactor it into a more manageable cloud-native type of service. What this does is it allows you to ensure that you can migrate your legacy applications with the minimum number of overhead and control for a lot of external factors. 

You and your team will need to have three accounts where the first account takes care of the legacy application. The second account will host the new microservice. And the third account is the refactored environment.

And it’s this refactored environment that provides a unified networking, transit gateway orchestration, it provides VPC orchestration, and resource access manager orchestration so that your legacy application will act like the legacy way however, it will be containerized as a microservice.

This is a very exciting new addition to AWS’s services and if you can take advantage of it, your cloud migration experience will be much smoother.

Summary 

To summarize, these are the cloud migration strategies also known as the 7Rs.

They are retain, retire, relocate, rehost, replatform, repurchase, and refactor. Of these seven retain and retire are not for cloud workloads.

However, they are very valid options if an application is no longer needed, in which case you’re going to retire it. And if an application is currently in use, but there’s no need to migrate to the cloud at this point.

The migration process begins with your portfolio discovery followed by prioritization. This is in the backdrop of a planning cycle.

Then once you decide whether or not you’re going to go to the cloud, you get to choose from the following five options of relocating it, rehosting it, replatforming it, repurchasing it, or refactoring the code at which point you’ll enter the design cycle and the validation cycle where you and your team are going to redesign for the cloud and ensure that it works as it did so that it can meet your business needs.

And if everything works out, okay, you’ll get it out into production. And once one application is done, your team has built knowledge, your team has built experience, and then the next iteration of the next migration will go much faster.

References 

What follows is a list of references that I used in making this presentation for you.

You’ll notice that they are all AWS assets. I’d encourage you to read some of them and get an idea of what would best suit your business, what would best suit your application prior to your migration to the cloud. So take care of yourselves, have a beautiful day, and I’ll see you in the next video. Bye-bye for now.