Which one is right for you for migrating your applications and databases to cloud?
Refactor (Re-Architect)
Replatform
Rehost
Repurchase
Retain
Retire
1. Refactor (Re-Architect)
Re-architect your application to provide cloud native features with latest updated technology stack.
For example -
Java application running in a traditional server(on-premise) connects to database, also it archives some files to the local storage. This is our simplistic architecture, but this is monolithic application and its legacy application.
I would like rethink and use cloud native features in order create microservices deployment. Imagine I have decided to move towards AWS. In AWS, if I relate to each of the on-premises services, I can use S3 Object Store for application files, S3 Glacier to Archive the files so that I can save some cost, and then for databases, I can use Amazon DynamoDB to store metadata, Amazon RDS - MySQL or Arora or PostgreSQL for my database workloads, because I don't want to pay huge licensing cost for Oracle. To hosting my web services, I can use amazon elastic container services with scalability and other integrated features within the AWS ecosystem.
This is one example of how you will be rearchitecting or refactoring your application, so that you will have to invest a lot of time in terms of recreating this application from scratch and rewriting it so the major cost here is going to increase because the time to deliver for your product will be more, so that involves the cost right so you have to pay for the resources, you have to pay for the time which you are going to take in order to deliver this particular application into cloud, but what do I get as a benefit, in the long run its going to easy for me to maintain this particular application because you are already using the cloud native features and you have already rearchitected so it's going to edge well so if an application fits into this kind of bill you can definitely tag that particular application as a refactor stretegy and that's when you have to go for refactor stretegy.
2. Replatform
This is another common stretegy which lot of companies try to go to so that they can get less cost-effective option. In the previous option we have to put lot of time and effort in terms of re-architecting, re-platforming, re-factoring your application.
In the re-platform stretegy we are going to lift application from traditional server, reshape it or tinker it, basically change something within the application a little bit and then shift it to the cloud. Most of the time this involves very less configuration changes and environment specific changes, and it doesn't involve business specific changes or changes to the application.
Let's take an example, we have a traditional server and when I do replatform, I am going to deploy the traditional web application, which I am running it on traditional server into something like elastic Kubernetes servers where I can leverage the platform's capability to deploy microservices and use the scalability aspect within the Kubernetes ecosystem to enhance it and get the cloud native features. So I am just slightly changing my application so that I can move it the cloud unlike the refactor stretegy. I don't have to do majority of my refactoring within the application, instead I can containerize my application into a traditional docker based image and then I can deploy that image inside an elastic Kubernetes service. This is the classic example of replatforming, so why would one want to do replatforming. compared to the previous strategy this is going to be cost effective, I wouldn't say this is the best methodology but obliviously there will be a stage where you will be running your compute inside eks but without cloud native features, so you will have to spend some time in the long run to maintain it and also to refactor it later, but you can use replatform as a strategy, when you want to quickly migrate to cloud , leverage come of the features and you don't want to invest more time and cost on refactoring your application that's when you go for the replatform strategy and you have to use continuous improvement strategy in terms of modifying this application and make it better and better.
3. Rehosting
Rehosting is nothing but lifting and shifting the application and migrating it onto the cloud.
For example. if you have a traditional server, you just pick the application within the traditional server, get all runtimes, necessary softwares which you have installed within the traditional server, install it within amazon EC2 instance and deploy the applications within that. This is one of the easiest strategy which you can take in terms lifting the application from a traditional server and then shifting it into EC2.
Most of the time you will have to leverage some of the platform specifics, for example for load balancing you will have to use elastic load balancer and other services but when you do lifting and shifting you may not directly just lift and shift. You might have to use some of the services within the AWS ecosystem.
If you are willing to spend more time in refactoring your application little bit then you can obviously choose the replatform stretegy so the confusion happens when you want to choose between replatform and rehost, so choose wisely which one you are okay with and which one your application fits in. Now if you look at the advantages and the disadvantages of this particular strategy the cost is going to be effective because you are just going to lift and shift your application but in the long run you will have to maintain this application. You will not get the scalability aspect of cloud because if EC2 instance goes down then your application goes down, similar to how a traditional server had been behaving, but since commodity hardwares are running behind the cloud you can expect failures anytime, so choose wisely which strategy you want to choose whether you want to choose replatform or rehost based on your budget.
4. Repurchase
Repurchase is similar to scrapping your existing product and then buying a new product from the marketplace. this could be something similar to how you buy a salesforce CRM or something similar to Zoho or Freshworks which are the new players in the SAAS space where you don't want to invest a lot on your product instead you just scrap the product which you wrote long back and these are legacy products and then you don't want to maintain them, instead you go to the market and buy a software as a service product where you just pay only for the usage. A common example for these kinds of tools would be the BI tools and the reporting tools. You don't have to create reporting engines again, instead you can go to the market and buy some of them. For example, Zoho analytics is one common reporting tool which you can leverage.
Now let's take use cases, where I have some applications which are already creating some reports. I need to send these reports to some other downstream systems, or I need to send something as email or I have some customer relationship software which I am running on on-prem . Now I want to migrate that on to AWS. You can definitely leverage services something like Amazon Simple Email Service (SES) using which you can send email notification to the recipient and also you can leverage amazon connect to understand the customer dynamics and then you can replace your customer relationship software with amazon connect. These are some examples of how you can leverage repurchase as a stretegy to replace your existing applications. Obviously, what do you get along with it, you get lot of cost benefits because you don't have to spend much time in creating these softwares instead you are leveraging the platform specific services and you just pay for whatever you use and also in the long run this would scale well because you don't have to worry about the scalability and you can leverage the software provider to provide all these features. This could be one smart strategy if you think your software can be replaced with an existing software which is available in the market.
5. Retain
Imagine a state where you don't have any budget at this point of time, and you don't want to invest much on your application for migrating it into cloud. Then you can tag your application as a retained strategy, or you can otherwise call it as revisit because you will have to revisit your application to migrate it onto the cloud at some point in time so you can either call it retain or revisit.
This is another stretegy where people just keep the application and then don't touch it until the next assessment comes. Obviously if you are running your application on a traditional server it is going to stay there forever until you revisit the stretegy. So what do I get out of it ? I am going to have to maintain the existing traditional server so the cost is going to be the same and in the long run it is going to be difficult for me to maintain because other applications are moving to the cloud, this particular application is not moving to the cloud right so I will have to rethink and revisit my stretegy so that currently the disadvantage would be the cost and the long run maintenance for these type of applications .
6. Retire
Retirement stretegy, this is one of the last stretegy which people would choose because decommissioning an application is not that easy however if single application is split into multiple applications and you already replaced it or you have bought some part of it or you have rehosted or re-platformed some things or the other, then you can definitely retire your application that it can be safely decommissioned and you don't have to worry about maintaining this application forever so this is similar to how you have a traditional server and remove the application out of the traditional server and then just shut it down.
These are some common stretegy which people use, and they are called as six R's because there are six different strategies.
Let me summarize with an example from Amazon's Whitepaper (link mentioned below)
https://docs.aws.amazon.com/whitepapers/latest/aws-migration-whitepaper/welcome.html
Just to summarize what we have discussed; you need to analyze and assess your application and prioritize what kind of cloud migration stretegy you want to choose for that particular application. There are six different R's, the first one is
Rehosting - is just lifting and shifting an application so you don't have to invest much on refactoring an application.
Replatforming - is lifting and reshaping your application so that you can make it work for the platform and leverage some of the features.
Repurchasing - is completely replacing your applcation with software as a service(SAAS) product or something you can purchase with the licesne and you can set it up.
Refactoring - where you will have to rewrite your application in such a way that you can leverage all the latest technology stack with cloud native features and write decoupled applications on the cloud. This will be the costliest stretegy because it involves lot of time and effort in terms of refactoring your application.
Retaining - Basically not changing anything in application and not moving it out of your traditional server.
Retiring - it makes sense when you have already taken bits and pieces of that particular application and created a separate application. You think that this application not needed anymore.
