Cloud Migration Strategies (6R'S)

Within the field of cloud migration, there are different methods and ways of coping with it, so it can be very confusing for those who have no experience in the field or those who want to keep moving forward, but do not know that such movements exist.

However, the AWS cloud supports us with a series of different ways of coping with it, such as the 6 R's, which offer us a migration from different perspectives or points, that adapt to any type of infrastructure and need.

1. REHOSTING

Also known as “lift-and-shift”.

We found that many of the first cloud projects gravitate toward net new development that uses native cloud capabilities, but in a large legacy migration scenario where the organization seeks to scale its migration quickly to fulfill a business case, we found that most applications are rehosted. GE Oil & Gas, for example, found that, even without implementing any cloud optimization, it could save approximately 30% of its costs through rehosting.

Most rehosting can be automated with tools (for example, CloudEndure Migration, AWS VM Import/Export), although some customers prefer to do it manually while learning to apply their legacy systems to the new cloud platform.

We've also found that applications are easier to optimize/reorganize once they're already running in the cloud. In part because your organization will have developed better skills to do so, and in part because the difficult part - the migration of the application, data and traffic - has already been done.

The intention of this strategy is to achieve the business case in an accelerated manner.

RE-PLATFORM

In this case, some optimizations may be made in the cloud (or otherwise) to achieve some tangible benefit, but the main architecture of the application is not changed. You may be looking to reduce the amount of time you spend managing database instances by migrating to a database as a service platform, such as Amazon Relational Database Service (Amazon RDS), or migrating your application to a fully managed platform, such as Amazon Elastic Beanstalk.

A large media company we worked with migrated hundreds of web servers running on their premises to AWS and, in the process, moved from WebLogic (a container for Java applications that requires an expensive license) to Apache Tomcat, an open source equivalent. This media company saved millions in licensing costs, in addition to the savings and agility it obtained when migrating to AWS.

RE-PURCHASE

The most common is to see the repurchase as a switch to a SaaS platform. It's about changing a CRM for Salesforce.com, a human resources system for Workday, a CMS for Drupal, and so on.

Identify apps or servers that may already be offered by a third party.

For example, I have an On premise CRM that consumes a front end, a backend and a 2 or 3 database, consumes so many GB of storage, consumes so much licensing, and maybe it's nothing more for a niche of customers that I have very segmented and that with a third-party app of something that is offered as SaaS, that in Google you can put CRM and you will get several options and it can be combined for that type of use in particular

It is a service that I actually need or could be paying for it to a third party to maintain it and I just consume it like a SaaS

REFACTOR

Reimagine the architecture and development of the application, usually using cloud native features.

This is often motivated by a strong business need to add features, scale, or performance that would otherwise be difficult to achieve in the current application environment.

Are you looking to migrate from a monolithic architecture to a service-oriented (or serverless) architecture to boost agility or improve business continuity (I've heard stories of mainframe fan belts being ordered on e-bay)? This model tends to be the most expensive, but if it has a good product-market fit, it can also be the most beneficial.

This is very good as long as you are clear about your business objectives and where you want to go.

RETAIN

This usually means “reviewing” or doing nothing (for now).

Maybe you're still putting up with some depreciation, you're not ready to give priority to an application that has been recently updated, or, on the contrary, you're not willing to migrate some applications. You should only migrate what makes sense for the business; and, as the severity of your portfolio changes from on-premises to the cloud, you'll probably have less reason to retain it.

REMOVE

Get rid of.

Once you've discovered everything in your environment, you can ask each functional area who each application belongs to. We've found that up to 10% (I've seen 20%) of a company's IT portfolio is no longer useful, and can simply be deactivated. This savings can boost the business case, direct your team's scant attention to the things people use, and reduce the surface area you have to secure.

These are the migration strategies, from now on there is much more information on how to break down each one of them, this is just the tip of the iceberg and consider that there are options when migrating to the cloud, which is nothing more black or white, not only is everything in the cloud or everything On premise, the ideal is to have a mix or even have replication schemes in the cloud, in different regions.

Thanks to this, quite interesting schemes can be arrived at, and all thanks to migration strategies.

Contact us for any questions or comments you may have.