Building data-driven migration plans with application dependency discovery
Large-scale enterprise cloud migration projects are quite complicated. For example, legacy applications can be highly dependent on operating systems and external services, as well as suffer from a lack of maintenance. This creates challenges for finding the dependencies among different applications. An inventory list of equipment may not be available or updated. Therefore, we don’t know where to locate the components of applications.
Some traditional 3-tier application architectures may depend on shared databases. In turn, moving any application may cause unknown impacts on other systems. To overcome these challenges in migration projects, you must build reliable migration plans that detail application dependencies and uncover the potential issues.
Customers usually collect this information from different channels and verify it with each other to increase coverage confidence. Three common sources include:
- Leveraging an existing configuration management database (CMDB)
- Conducting user and application owner interviews
- Deploying automatic discovery tools to dig out inventory and dependency data
The first two channels are traditional methodologies that involve manual processes. Collecting and verifying information across numerous applications and hundreds of machines manually requires months of human effort.
Furthermore, this might not produce complete details. Rapid data collection is essential in mass migration projects, as it helps you to identify major environmental obstacles and define your pilot migration scope early so that the plan can account for them. Equally important is the migration plan’s reliability, which makes sure that you can deliver the expected outcomes.
In this post, you’ll learn how to collect accurate inventory and application dependency data from hundreds or even thousands of machines in as short as two weeks with Cloudamize, a tool by CloudReach from the Amazon Partner Network (APN). You’ll utilize its reports to build reliable migration plans that increase the project’s effectiveness and overall success rate.
When and how can reliable migration plans help?
The AWS migration methodology is a three-phase process designed to help companies mass-migratate applications. In the Assess phase, you discover your organization’s current readiness for operating in the cloud, identify the desired business outcomes, and develop the business case for the migration. In the Mobilize phase, you create a migration plan and refine your business case. You’ll also address gaps in your organization’s readiness that were uncovered in the assessment phase, thereby focusing on building your baseline environment, driving operational readiness, and developing cloud skills. In the Migrate & Modernize phase, each application is redesigned, migrated, and validated. Refer to the Mobilize your organization to accelerate large-scale migrations prescriptive guidance for planning your migration.
In the Mobilize phase, a well-defined migration plan significantly increases the confidence in moving and operating applications in the cloud. A well-defined migration plan should be application-centric and address the following questions:
- What applications and components are you planning to migrate, such as servers, storage, and network?
- Who is responsible for that application stack?
- When should the application move, and what dependencies must migrate first?
- Where can you locate the corresponding components that comprise these applications?
- How should you approach migrating the application by choosing a rehost, replatform, or rearchitect methodology?
Gathering accurate data with automatic discovery
Cloudamize is a cloud computing analytics platform that improves the speed, ease, and accuracy of AWS migration. It performs automatic data collection, environment discovery, and traffic analysis for the monitored machines. The tool offers two approaches to collecting data: agent-based and agentless methods.
- In agent-based deployment, you must install software on every target machine and align the data collection rate with the process duration.
- In agentless deployment, you set up the Cloudamize Agentless Data Collector to discover and assess physical and virtual machines (VM) without installing software agents. Instead, you install the collector on a VM host. For more options and deployment prerequisites of the Cloudamize Data Collector, refer to their guidance in the Installation Prerequisites.
Cloudamize will observe your IT environment’s performance over two or more weeks. Once the data collection completes, Cloudamize will run analytics and deliver multiple reports on your total cost of ownership (TCO) within AWS. In addition, the Migration Planner also provides a topological view of your environment with an asset visualization that includes dependency mappings. Migration Planner helps you:
- Discover servers, storage, and applications
- Map application interdependencies and communications
- Build migration move groups by machines and applications
- Tag resources and examin the filtered analysis
Next, you’ll dive deep into leveraging the Cloudamize Migration Planner to build data-driven migration plans.
Building application groupings with the Migration Planner
Here you can see an example of the fine-tuning process. The following image is a screen capture of the Cloudamize Migration Planner. On the left is a list of discovered groupings that expands to show individual machines. Once you select a group, the summary of the processes running on all of these machines will appear on the right.
This post demonstrates how to build and fine-tune application groupings using a Customer Relationship Management (CRM) application. It verifies that no resources are missing for the delivery of the CRM application, and that the expected processes are running afterward. You can select the CRM grouping on the left. The CRM grouping consists of eleven machines, shown in the middle. The processes running in these machines are listed on the right-hand side. The next task is to study the dependency of the key process related to the CRM application.
At this point, you need some understanding of the application to locate the critical process that is related to the application. You’ll typically gather this information in interviews with users or application owners. Here we know that the process Web App (CERTSRV + DefaultApp listed on the right-hand side is the critical process for the CRM application. Select the application by selecting its checkbox to capture its dependency information. This feature is the visualization of application grouping. Ideally, all of these components migrate together to avoid performance or connectivity issues after migration.
In the subsequent screen capture, you can choose a yellow line to access the Planned Migration. It displays the dependency details, including all of the processes communicating between those two machines.
Now you must verify that all of the resources are included. Look for machines that compose the application and remove any erroneous results. In the previous screen capture, you discovered a yellow line linked with the Control System grouping. Suppose that you missed some servers with the current CRM grouping. In that case, use the “+” to add connections to the Control System grouping (refer to the following screen capture).
Here you found two machines were grouped as part of the Control System querying
machine.35.acme.com in the CRM grouping. Verify if these connections are for the CRM application delivery. Then, select the yellow line between
machine.21.acme.com and check the connection details. From the right-hand side, you found four processes running on
machine.35.acme.com, and the information is evidence that
machine.21.acme.com should be included in the CRM grouping and migrate all together in a wave.
Now you know that the CRM group contains
machine.22.acme.com. Next, update this new grouping decision. In the Migration Planner, select the “Move Interconnected” button at the top. This view enumerates the group members’ relationships. You can see
machine.22.acme.com here grouped to Control System under the Asset Name. Update the CRM grouping by selecting these two machines with all of the original CRM grouped machines in the checkboxes at the left, choose the Asset Name as CRM at the top, and then save your new groupings.
Advanced migration strategies
You can use this information to verify if other essential processes are communicating between the machines that may introduce overlapped grouping. The Cloudamize Migration Planner shows dependencies with visualization, thereby enabling you to discover these overlapped groups more effectively. You must use special strategies to handle situations where multiple critical applications run in the same machine group.
These strategies may include moving all of the applications and all related machines in the same migration wave, or partially migrating the components at the application level in different waves. Suppose two applications are dependent on the same database machine and the two applications must be migrated in other waves, which may be due to the application or environment. In that case, you may need to migrate the table-level database and rebuild them
separately on two different target database machines.
Building application groupings are iterations. You must repeat the above exercise group-by-group and fine-tune the groupings in every iteration according to the processes discovered. You may find missing machines in later iterations and return them to previous groupings. Alternatively, you may decide to separate some grouped machines into other groups due to an application or environmental behavior.
Ultimately, Cloudamize helps you capture the group information for all of the machines in your environment. You can export the data into a spreadsheet as shown in the following image, and use these to build the migration plan further.
Completing the Migration Plan
At this point, Cloudamize has helped you obtain a solid grouping of machines and applications based on the discovered dependency data. To build a complete migration plan, you must decide on suitable strategies to migrate discovered applications with priorities.
An example plan is shown in a spreadsheet in the following image to illustrate the idea. The second column, Apps, refer to the Asset Group in the previous Cloudamize exported spreadsheet. You can map the machines accordingly using the Cloudamize result. From interviews with application owners, collect business units’ (BU) information, environment type, and application criticalities, then finally come up with migration priority, strategy, and wave planning. With this data-driven, executable migration plan, you can answer the Who, What, When, Where, and How questions of migration projects.
Large-scale enterprise cloud migration is complicated. You learned how to perform automatic discovery to collect accurate data and build reliable migration plans leveraging Cloudamize. Automatic discovery helps you save manpower from months of human effort in interviews versus days in Cloudamize provisioning and configuration, shorten the data collection time from months to two weeks using Cloudamize, and obtain accurate data to build reliable migration plans that increase the effectiveness in project execution and the overall success rate. Visualization in the Migration Planner also helps you define application groupings more easily and effectively, thereby enabling you to make faster migration decisions. However, we have only covered how to build a data-driven migration plan. There’s so much to consider in executing the plan. You can learn more from AWS large-migration strategy and best practices, based on AWS Professional Services’ experiences helping a wide range of customers. Furthermore, it provides real-world examples of lessons learned during customer migrations to AWS.
And don’t hesitate to talk to your AWS account manager or solutions architects for advice on creating plans according to your business and technical needs. They can help you create business cases to gain insights and accelerate their decision-making. Moreover, AWS helps customers understand their current cloud-readiness strengths and weaknesses, as well as provide action plans to resolve the identified gaps.
Learn more from a case study of Finnair’s Swift Migration to AWS Drives Savings and Agility to see how AWS and our partner conducted a full total cost of ownership (TCO) evaluation and business case for Finnair, as well as identified the potential for substantial savings in both capacity and license costs. Migrate with AWS to accelerate your modernization goals, reduce costs, and gain easier access to data now!
About the author: