How to migrate an on-premise application to AWS Cloud?

How to migrate an on-premise application to AWS Cloud?

28 January 2021

What is AWS migration and why is it needed?

Before moving on to the process of migration, let’s talk about what it is and why it is needed. AWS migration is the procedure of moving data, applications, or other business components from an organization’s on-premises infrastructure to the cloud, or to move them from one cloud service to another. There are many reasons to move to the cloud and these are as follows:

  • To handle a high volume of traffic in the website/application
  • To implement and deploy the applications quickly.
  • To modernize current IT asset base
  • To prepare for future needs
  • To reduce infrastructure costs
  • To increase Business agility
  • For Disaster recovery and security

Phases of AWS Migration

Let’s now discuss about the various phases of Migration:

How_to_migrate_an_on-premise_application_to_AWS_Cloud_01

Phase 1: Discovery – Apps which can be moved to Cloud Discovery

Sometimes, we need not move our entire business to the cloud. This is where we need to segregate it. We need to identify the applications which can be migrated and which cannot. So, we start by finding out which applications can be migrated to the AWS cloud easily and which ones would need modifications. Then, we modify the application architecture to allow servers, networks, and data services to run and interact in the cloud computing environment.

Phase 2: Assessment – Choosing the Migration Method

Depending on the data, AWS provides several ways to migrate the application e.g. AWS Snowball, AWS Snowmobile, AWS Direct Connect, etc. Once we choose an appropriate way to move our data, we look for the resources we’ll need for it then. Let’s now explore the different ways of storing data on AWS Cloud in the next phase.

Phase 3: Proof of Concept for AWS Storage (POC)

Once we come to know how and what we are migrating, we have to find out how and where we will store it. The entire motive of moving to AWS is to reduce expenses. In this phase, we’ll test our workload and understand about AWS Storage Service, their benefits, disadvantages, and the necessary security controls.

Phase 4: Application Migration to AWS

Once we have all the prerequisites like the blueprint, migration tools, list of assignments, backups and its synchronization with our on-premises data repositories, we can finally migrate the project to the AWS Cloud. Once we have migrated our project to cloud, reliability, and durability are the added advantages that we get. There are 2 main application migration strategies:

  • Forklift Migration Strategy: This approach is used to serve the stateless applications, tightly coupled applications, or self-contained applications. Rather than moving parts of the system over time, forklift or “pick it all up at once” and move it to the cloud. Examples of these types of systems are self-contained Web applications that can be treated as single components and backup/archival systems that can be moved into the cloud using this strategy.
  • Hybrid Migration Strategy: A hybrid migration consists of taking some parts of an application and moving them to the cloud while leaving other parts of the application in place. Rather than moving the entire application at once, some parts can be moved and optimized one at once. The risk of unexpected behavior after migration is reduced due to this and is ideal for large systems that involve several applications.

Let’s now see the changes AWS brings to our architecture in the next phase.

Phase 5: Enterprise Cloud Operations

At this stage, we’ve already migrated to AWS, and it will bring updates that we’ll need to include in our existing architecture. Hence, we must ensure that we have a 24×7 support team keeping track of system maintenance and upgrades after the migration.

This was all discussion regarding the different phases of AWS Migration and how to implement it. Let’s see the strategies for AWS Migration.

Application Migration Strategies ‘The 6 R’s’

Depending on the architecture, Amazon was brought up with several different strategies which are commonly termed as 6 R’s. Let’s look into each of them:

  • Rehost: Once we have our application ready and working then we can simply rehost it on AWS. It is also referred to as “Lift and Shift”. We lift our services and applications from our hosting environment and shift them to cloud using a third party exporting tool.
  • Replatform: If we have an outdated version of our application running on our hosting environment, then we have to modify our application and then rehost it. Replatforming is a modification of “Lift and Shift”. It is about optimizing the cloud architecture to achieve the benefits without changing the core architecture of the application.
  • Repurchase: In case, there would be certain applications that won’t be compatible with the new architecture, then we need to purchase a new application for the new architecture. AWS Marketplace provides a wide range of services which are also with a “Pay as you Use” model. Repurchase is also called “drop and shop” where we upgrade, ease the implementation and accept the new architecture and make changes to the existing model.
  • Refactor: Now we wish to add up new features, scale up the limits of the existing business model and performance that are difficult with the existing environment. We reconsider our needs, though the solution is a bit expensive. Improving business by moving to a service-oriented architecture (SOA) will provide benefits to our business in the longer run.
  • Retire: After AWS Migration we can differentiate between useful and useless resources. Hence, we discard all the resources that are no longer useful to the business and build a strategy around the new resources. This removes the extra cost. With lesser things to worry about, now we can focus on maintaining the resources used by the new business model.
  • Retain: As we know, some sections of our project need migration. We can simply use any of the above mentioned strategies. Then, we build a strategy to retain those applications, which, according to our business model are yet not ready to be migrated to the cloud or the applications that were upgraded recently.

Request a quote