AWS Cloud Migration 201

After obtaining a quick overview of cloud migration in the last post, let’s go into the weeds with cloud migration principles. It’s time to talk about cloud migration strategies. A well-aligned migration strategy, supported by a business case and a well-thought-out migration plan, lays the framework for successful cloud adoption.

Collecting application portfolio data and rationalizing it into what AWS refers to as the 6 R’s: Re-host, Re-platform, Re-factor/Re-architect, Re-purchase, Retire, and Retain is a vital element of establishing a migration plan. This is a way for identifying what is in the environment, what the interdependencies are, the technical difficulty to migrate, and how each program or collection of apps will be migrated. Migration of current applications varies in complexity based on factors such as architecture, current license agreements, and business requirements.

Let’s talk about 6 most common application migration strategies:

‘Re-host’ or ‘Lift and Shift’

Move apps without making any modifications. Large-scale legacy migrations need enterprises to move swiftly in order to satisfy business objectives. The vast majority of these apps are re-hosted. GE Oil & Gas discovered that re-hosting may save it up to 30% of its costs even if no cloud improvements were implemented. The majority of re-hosting may be automated using tools. As they learn how to deploy their old systems to the new cloud platform, some clients opt to do this manually.

‘Re-platform’ or ‘Lift, tinker, and shift’

Make a few cloud optimizations to see a noticeable improvement. There will be no changes to the application’s basic architecture. A multinational media firm moved hundreds of on-premises web servers to AWS. It switched from WebLogic to Apache Tomcat, an open-source alternative. This media firm saved millions of dollars in licensing expenses by switching to AWS, as well as enhanced savings and agility.

‘Re-factor’ or ‘Re-architect’

Rethink how the application is designed and built utilizing cloud-native capabilities. This is motivated by a compelling business requirement to add features, size, or performance that would be difficult to achieve in the application’s current environment. This is the most expensive strategy, but it may also be the most effective if there is a solid product-market fit.

‘Re-purchase’

Shift away from perpetual licenses and toward a software-as-a-service approach. For example — Change from a customer relationship management (CRM) system to Salesforce.com, an HR system to Workday, or a content management system (CMS) to Drupal.

‘Retire’

Applications that are no longer required should be removed. After you’ve finished discovering your surroundings, find out who owns each program. As much as 10% to 20% of a business IT portfolio is no longer needed and can be switched off. These savings can help your business case by directing your team’s attention to the applications that people use and reducing the number of apps that you must protect.

‘Retain’ or ‘Re-visit’

Keep apps that are vital to the company but require extensive restructuring before migration. You may go back and review all of the applications in this category at a later time.

Larger-volume patterns, such as re-hosting, provide the chance to specify techniques and tools for transferring data and application components. Every application in the execution phase of a migration, on the other hand, follows the same six-step process: Discover, Design, Build, Integrate, Validate, and Cutover.

Discover — The application portfolio analysis and planning backlog are used in the Discover stage to understand the present and future architectures. Discover Business Information (DBI) and Discover Technical Information (DTI) are the two types of information.

Design — The desired state is established and recorded during the Design stage. The AWS architecture, application architecture, and supporting operational components and procedures are all part of the desired state. A sprint team member and an engineering team member utilize the knowledge gathered during the Discover stage to develop the application for the desired AWS environment.

Build — The migration design developed during the Design stage is performed during the Build stage. The migration teams are provided with the necessary people, resources, and reusable templates. The migration strategy for the application is used to choose a migration team.

Integrate — During the Integrate step, the migration team creates the application’s external connections. The migration team collaborates with external service providers and application users to establish connections or service calls to the application. Before the program is ready for the Validate step, the team runs it to demonstrate its functionality and functioning.

Validate — Each application goes through a series of particular tests at the Validate step before being finished and released for the Cutover step. Application-specific rollback methods are described inside a rollback playbook, which includes an operations communication strategy for users and identifies integration, application, and performance consequences.

Cutover — The migration team implements the cutover strategy agreed upon by the migration team and application owners during the Cutover stage. Perform a user acceptability test at this point to ensure a smooth transition. If the migration fails, follow the rollback method mentioned in the cutover plan.

Migration is only the tip of the iceberg in terms of what is feasible. Once you’ve migrated an application, think of your migration expertise as a skill you can put to use during the project’s optimization phases.

Thank You !!!