Cloud Migration Strategy — On-Premises to Cloud

Let’s discuss — what are the cloud migration strategies to move the on-prem resources/servers/applications/systems to the cloud.

What is Cloud Migration?

When an organization is planning to shift its data servers and applications hosted on on-premises servers to the cloud.

And now this triggers a thought that who/what is this cloud?

Cloud — In simple terms can be understood as — Way of delivering different services through the Internet, it may be Infra (Infra as a service), or Software (software as a service), or platform (platform as a service) or be it everything or anything as a Service. :-)

Who provides these facilities?

— There are various cloud service providers in the market and the top 3 cloud service providers listed in the Gartner quadrant are — AWS (Amazon), Azure (Microsoft), and GCP (Google).

Which cloud service provider to opt for?

— It usually depends on the types of cloud services we are looking for and how one is offering in terms of benefits and ease of use, and obviously, cost factor linked to various cloud services provided by the cloud service providers. This is a vast topic in itself, I will cover this in another blog.

Without deviating from the topic — cloud migration strategy, let’s see what it takes to move to the cloud.

When we plan to move the app and data servers to the cloud, we need to define the strategy that includes Assessments, specifically in terms of Business, technical, financial, security and compliance, and regulatory.

The well-defined strategy which was discussed in one of the AWS summits is the 6 R’s strategy.

What is 6 R’s Migration Strategy to the cloud?

6 R’s are as follow —

1. Retain
2. Retire
3. Rehost
4. Replatform
5. Refactor
6. Repurchase

Let’s see what these individual R’s are —

1. Retain — This means let’s not move anything to the cloud, and we will use on-prem servers (maybe for data or IT resources or Applications). Or maybe the OS on which the server is currently hosted is not supported on Cloud services, so we cant move these systems from on-prem to the cloud. If we see in terms of cost, this has almost no cost for moving on to the cloud but we may pay some good amount of bucks to dev’s or support group people for maintaining it on on-premises. But if we need to connect to these on-prem systems to/from the cloud-hosted applications, we might need to set up a Site-Site VPN connection.
2. Retire — Something that is marked as “Not required anymore”, or in another term, Decommissioning. These can also be Disaster recovery servers, as once we move to the cloud, we can actually take benefit of the Cross-Region strategy. Also, I learned a very good example, especially for the applications that are duplicated in terms of features it provides, for the organization when mergers and acquisitions happen in organizations. And we can actually decommission either organization's application.
3. Rehost — Often known as Lift and Shift — As simple as migrating the application to EC2 instance — in terms of AWS, or virtual machine in terms of Azure, and Compute Engine in terms of GCP. So in simple words, just getting a new Host in the cloud. This takes minimal cost, obviously depending on the size of the instance, we opt for hosting the entire application. And this takes minimal time for migrating the app manually, or by using some automated migration tools provided by cloud service providers.
4. Replatform — Also termed as Lift and Reshape — We can think of this as — to move the on-prem application to the cloud using ECS in terms of AWS, Azure container service in terms of Azure and Google Kubernetes Engine in GCP. So as simple as making some adjustments to the application and push it to the cloud, but the important thing to note is the architecture of the application remains the same. Another example can be changing on-prem oracle database to something as RDS — Database as a service offered by AWS. This takes more time and cost than Rehost. But has its own benefits of horizontal or vertical scaling as per needs. It also offers one of the benefits of moving to the cloud in terms of Reliability.
5. Refactor — This is something complex :-), with this strategy, we re-build our entire application i.e. code changes are involved and need those to be tested carefully to avoid regressions. We will surely get the benefits of cloud services for example auto-scaling, reliability, or move some of the servers to Serverless architecture (Function as a service — Something like Lambda functions, or Azure functions) for cost-savings, and many more features of the cloud services. This strategy takes a maximum of cost (due to development time) and time to completely move the application to the cloud, but if we see it in the long term, this definitely has more rewards. By using this strategy we will utilize most of the benefits of moving to the cloud.
6. Repurchase — This is where we try to look for an already available product — normally a SAAS-based offering, to serve the similar features or may provide bigger benefits as well. For example, the HR system on-prem app can be moved to Workday which is Software as a service. This has balanced cost and time but requires more effort on finalizing the product based on the needs, and migration or porting related activities for data. And after we have replaced the application with any SAAS product we also need to test all the business functionalities. But if we notice the best part here is, we do not have to maintain the infrastructure, and we pay for what we will be using.

I hope this gives a brief insight into the cloud migration strategies. Thank you for staying tuned. :-)

References: One of the AWS Summits and AWS documentations to get the understanding on same.