Growth in digital transformation brings with it a growing need for agility and innovation in the technology sector. As a result, by 2020, it is projected that 83 percent of the corporate workloads will be run in the cloud. When it comes to maintaining your IT burden, if you haven’t regarded cloud computing as a viable option, it’s time to rethink about your strategy.

In light of current IT trends and corporate expectations, domain experts in the industry believe that Cloud Migration is the most effective method to stay up with the Digital Transformation and fulfill the ever-changing customer demands as fast and efficiently as possible.

Idexcel is an AWS Advanced Consulting Partner having more than 100 AWS certified specialists on staff. Such specialists assist with AWS migration to help you save a significant amount of time and money, by transferring your workload to the AWS cloud with Idexcel.

Three Phases of Cloud Migration Process

This process is designed to help organizations in migrating tens, hundreds, or thousands of applications. This is an iterative process, as you migrate more applications you will be able to accelerate repeatability and predictability in the AWS Migrations. Let us, deep-dive, into each of the migration processes:

Assess

At the start of the migration journey, the first thing the organization needs, is to identify all the assets in the data center that can be migrated into the cloud. The organization also needs to understand its current readiness to operate in the cloud. Most importantly, you need to identify the desired business outcomes and develop the business case for migration to the cloud.

AWS has tools to assess your on-premises resource and build a right-sized and optimized cost projection for running applications in AWS. To get started, the Migration Evaluator tool provides a total cost of ownership (TCO) projection for running the workloads on AWS based on your actual utilization of resources. This helps organizations to optimize compute, storage, database, networking, and software licenses on AWS. It also helps to estimate the cost of migrations.

This stage usually means deploying various monitoring tools such as Migration Evaluator, Migration Hub, or third-party tools like RISC Networks, which helps gather information about the applications dependency.

Once the business use case is created, migration and modernization strategies are designed based on the AWS Well-Architected Framework.

Mobilize

As a part of mobilizing phase, we create a detailed migration plan and address gaps that were uncovered in the Assess phase, with a focus on building your baseline environment (landing zone) and drive operational readiness.

A good migration plan starts with a deeper understanding of the inter-dependencies between applications and evaluates migration strategies to drive successful migration. Based on the data collected by tools deployed in the assessment phase, we place the application into various migration paths/strategies. Here is the list of migration paths

1. Re-Host: It is the most straightforward path cloud migration strategy. It simply means that you lift servers, applications, virtual machines & operating systems from current data centers to Cloud. Once done, the dependencies need to be rewired to the new host in the cloud. It is typically done by a tool like CloudEndure, SMS (Server Migration Service). Amongst all the migration strategies, this is the fastest The big drawback is that cloud-native features are not efficiently utilized like CI/CD automation, self-healing, automated recovery, monitoring systems, etc.
2. Re-Platform: It is called a lift tinker and shift. Here you might make a few cloud and other optimizations to achieve some tangible benefit, but you aren’t otherwise changing the core architecture of the application. Example: This can be moving from the proprietary web servers to open-source Tomcat server post-migration.
3. Re-Purchase: Moving to a different product. Example: This can be moving a CRM application from one vendor to another vendor depending on business needs.
4. Re-Factoring/Re-Architecting: Re-imagining how the application is architected and developed, typically using cloud-native features. This is typically driven by a strong business need to add features, scale, or performance that would otherwise be difficult to achieve in the application’s existing environment. It typically entails migrating from a monolithic architecture to a service-oriented/server-less architecture to boost agility or improve business continuity.
5. Re-Tire: Get rid of. Once all the applications are discovered, there will be few applications for which nobody takes responsibility. Since nobody takes responsibility for these servers, the server is stopped to check if that impacts any team. If there are no alarms raised by anybody, then they can be forwarded for decommissioning process.
6. Re-Tain: This means do nothing. There may be applications that are tied to hardware in on-premise like a Fax machine. These servers need to be hosted in data centers.

Migrate and Modernize

During the migrate and modernize phase, each application is planned, migrated, and validated. Based on the inputs from the above two phases, the migration is meticulously planned and executed. This phase can be sub-divided into 3 phases pre-migration, migration, and post-migration phase.

Pre-Migration:

1. It starts with setting up a meeting with stakeholders and assigning the responsibilities to the concerned person
2. Starting the replication/launching new instances based on the migration path
3. Opening the connectivity between all the dependencies
4. Creating the change request. The change request needs to be approved and all the pre-work, like intimation to business users regarding the downtime needs to be addressed. The changes need to be tracked as part of the change management process

Migration:

1. It starts with a cutover window
2. The On-premise server is stopped
3. Launching the cloud instance
4. Changing the hostname
5. Validation of the application

Post-Migration:

1. Enabling termination protection
2. Setting up backup and patching policies
3. Starting the decommissioning process for the on-premise server

Key Challenges to Scale Migrations

Every transformation task comes with its own set of challenges. These challenges are not faced by all the applications but on an average, it is observed that 20-25% of applications face this challenge.

1. CMDB is not very accurate. Even if we find all the data in the CMDB tool, many times we see that this data is not accurate and underlying assets in these applications are changed. In this case, we need to redo the planning based on current/correct assets.
2. If the organization doesn’t have CMDB tool. The application team is supposed to fill in the discovery data. It is found that many times the Application team takes a lot of time to fill this data as they have to source the data from multiple places.
3. Production systems have a limitation of when we can migrate. If the migration is not executed in that specific time frame, sometimes the migration gets delayed by months.
4. Migration road maps run parallel to the product feature roadmap. As a result, migration gets lower priority and gets pushed back.
5. The technical depth of the Application team. Many times, the applications are used by support teams and the people who developed the application are long gone. Hence there is a challenge in migrating and validating such applications.

Migration Acceleration with Idexcel

Based on the above challenge we encountered with the migrations we have developed processes and tools to migrate the application effectively.

1. Inventa Discovery Tool: This tool is built to speed up the discovery process. Many of the fields are auto-populated so that the Application team focuses on the data that is most important for migration. It also gives full visibility of the applications being discovered. This tool provides a self-service dashboard where stakeholders can view the status of their application discovery. It provides information about all the applications that are running in the organization. With Inventa, we get an idea about the number of applications being in progress and those being blockers. It also provides a drill-down where the user can navigate through each application to view the blockers and see why they are blocked and when it is likely to be resolved or any action needs to be taken to unblock the issues.
2. 2/2 Migration Execution Model: The migrations are typically done at a time when the load on the servers is minimum, usually on weekends or Friday evenings. It is often the case that there is more than 1 migration happening at the same time. If both the application migration is handled by the same migration engineer, then one of the migrations may need to be pushed back.
3. AWS Migration Hub: One of the key reasons for the success of migration is identifying the application dependencies. It is often found that the application team is not fully aware of all the dependencies. We leverage AWS Migration Hub to identify these dependencies and proactively addressing them.
4. Idexcel Configuration management tool: This tool is built on top of AWS Migration Factory and CloudEndure which automates the migration execution process. This tool is developed to speed up re-host migrations. Using this tool, tasks like installing the CloudEndure Agent on the source system or removing any software post cutover of servers can be done with a single click of a button. This brings down the application downtime considerably. It provides a dashboard for all the applications in scope for migration cutover. Stakeholders can view how many application migrations are completed and how many migrations are in progress. It shows a wave-wise breakdown of all applications being migrations.

Schedule for your Free Migration Readiness Assessment Program