Customers want to begin their cloud migration journey, but taking that first step and starting with Amazon Web Services (AWS) may sound like a complex set of tasks. This post shows how easy it is to move your first workload to AWS using AWS Migration Hub’s features.

AWS Migration Hub provides a central location to collect server and application inventory data for the assessment, planning, and tracking of migrations to AWS. Migration Hub can also help accelerate application modernization following the initial migration.

Overview of solution

The described solution will take you through the journey of discovering a workload, determining the right-sized AWS server configurations based on your utilization patterns, making sure that all the dependent servers will be moved together, and organizing your first migration wave. Migration Hub is used to track the activities during the journey.

The following diagram illustrates the process covered in this post.

Figure 1 – Architecture diagram for the solution

Here are the three steps necessary to migrate your first workload:

1. Use AWS Application Discovery Service to discover the workload environment, gather performance data and network connectivity details. This data will be sent to Migration Hub.
2. Use Migration Hub to analyze the collected data, identify and tag dependencies, group servers as applications, and generate recommendations for shared and dedicated Amazon Elastic Compute Cloud (Amazon EC2) environments.
3. Replicate onprem servers using AWS Application Migration Service and databases data using AWS Database Migration Service (AWS DMS) to move the workload to AWS. Migration Hub can be used to track the progress of the whole migration.

Prerequisites

For this walkthrough, you should have the following prerequisites:

• An AWS account
• An AWS console user with FullAccessprivileges to the services mentioned in the “Walkthrough – Services used” section below
• Basic command line interface knowledge to install software packages
• Hands-on experience^* with services mentioned in the “Walkthrough – Services used” section

^* Get hands-on experience by completing the Migration Immersion Day labs in your own AWS account. They offer step-by-step instructions guidance available in English, Portuguese, Spanish, Korean, Japanese.

Walkthrough

Let’s start your journey to the cloud using AWS Migration Hub as your guide.

1- Discover the workload environment

It is important to understand your environment before planning a migration. Application Discovery Service (ADS) makes it easy to gain a comprehensive snapshot of on-premises inventory, performance, and communication patterns. By using facts instead of assumptions about the environment, you can feel confident that Amazon EC2 configuration recommendations will support the needs of the servers to be migrated.

Application Discovery Service (ADS) provides three ways of collecting data: 1/ importing existing performance data from a file using this template, 2/ using an agentless collector (available for VMware environments) or, 3/ using an agent (available for Linux and Windows). This post includes reviewing server to server connection data to understand dependencies, and will focus on using the Discovery Agent. Customers primarily interested in infrastructure sizing can start with import or agentless options, then deploy agents where needed to gain deeper insight.

1. Create a dedicated programmatic access user in the AWS Identity and Access Management (IAM) console with the AWSApplicationDiscoveryAgentAccess policy. Application Discovery Service agent will use this user to collect data. Take a note of the Access Key ID and Secret Access Key, as they will be required shortly.
2. Go to the Migration Hub console. If this is the first time, a home region needs to be set. The home region provides a single repository of discovery and migration planning information for your entire portfolio. The data stored in the home region is used to track the progress of your migrations regardless of the migrating application’s target AWS region.
3. Install the Application Discovery agent on your source servers using the keys created in IAM. Data collection will begin automatically and is encrypted using TLS. You can check collection status and other additional information on Migration Hub console, then Data Collectors page, and Discovery Agents tab. You can also stop the data collection by selecting the servers and clicking the button on the top right corner of this screen.

2 – Analyze collected data, identify dependencies, group servers, and generate recommendations

When planning your migration, it is critical to understand the dependencies between servers, applications, and their related services. Dependent applications and servers are typically grouped together when moving to AWS.

Application Discovery Service (ADS) is instrumental in this task, as it gathers data about resource consumption and the network connectivity between servers and can help you to analyze server dependencies.

The Application Discovery Service agent will start reporting after 15 minutes and follow this interval until stopped. You can collect data for as long as needed, capturing specific stress periods for the workload. Generally, a 14-days is recommended.

Now it is time to analyze the collected data, size the environment and map the dependencies:

1. 1. In the Migration Hub console, choose Discover, then Servers.
   2. Clicking on a server name takes you to a more detailed view of the server’s resources. Note that average and maximum usage are available to help understand the real consumption and future state sizing.

   

   Figure 2 – Checking the server performance information with Migration Hub

   3. Click on the Network tab to discover the server dependencies. Notice there is a clear link between the Ofbiz-DB and Ofbiz-Web servers, used as example here. If servers with a “?” icon are present, this indicates they don’t have an agent installed but there is communication. Note on the bottom right corner the Inbound ports that are in use, this comes in handy when planning the future security groups to allow only necessary traffic.

   

   Figure 3 – Using Migration Hub to determine the server dependency mapping

   4. Now that you identified a connection between servers, you can group them as an application to facilitate planning and tracking. Go to Discover and choose Servers, then select the related servers and choose Group as application.
   5. It looks like you have everything to start migrating. But wait! Which Amazon EC2 instance type and size should you choose for each server? This can be easily answered by going to the Migration Hub console and clicking on Assess, then EC2 Instance Recommendations. Select the sizing preference (average or maximum), the region where your environment will be located, the tenancy, and pricing model. Upon clicking Export recommendations, Migration Hub creates a CSV file. Check the EC2.Instance.Model column to see the recommendation. You can generate multiple scenarios and make an informed decision.

   

   Figure 4 – Generating EC2 instance recommendations

   3- Replicate onprem servers

   AWS offers different strategies to move your workloads, the methods described below are related to these approaches: Re-host for the application servers and Re-platform for the databases.

   3.1 – Using AWS Application Migration Service

   Application Migration Service migrates servers to AWS bringing high level of automation, encrypted replication, and non-disruptive testing capabilities. It relies on a replication instance for replicating data from physical servers, virtual machines, and other cloud providers to AWS and storing it on Elastic Block Storage (EBS) volumes, think of it as the bridge between the current environment and AWS. Application Migration Service usage is free for 90 continuous days, however note you will incur charges for any AWS infrastructure provisioned by Application Migration Service like replication instances and EBS volumes.

   1. Migration Hub tracks the migration progress. To enable this integration in the Migration Hub console, under Migrate, select Tools, then Connect to link Migration Hub to Application Migration Service and allow server migration status to be shared.
   2. When accessing the Application Migration Service console for the first time, it sets up the necessary IAM roles and a replication instance template automatically. If you need to change the Replication template, go to Settings, then Edit template. Make sure to use a subnet that communicates with the source environment and select the appropriate routing options for VPN, DirectConnect, or VPC peering under Data routing and throttling.
   3. Application Migration Service is agent-based, to install the agent select Add servers. There is a handy wizard that will create the necessary IAM user (click Create IAM user) and assembles the download and installation commands to deploy in every single source server. There is also an agentless option for VMware, which is snapshot-based and available if agent installation is not preferred or for compliance reasons.

   

   Figure 5 – AWS Replication Agent installation command

   4. After installing the agent the replication will start automatically. You can track the progress by going to the AWS Migration Hub console and under Migrate, selecting Updates.
   5. While the replication is in progress, it is a good time to customize the EC2 launch templates. By default, Application Migration Service does some right-sizing on its own, still you may want to override that suggestion by assigning the appropriate Amazon EC2 instance type according to Migration Hub’s EC2 recommendations generated on step 5 from the 2 – Analyze collected data, identify dependencies, group servers, and generate recommendations section. Also, don’t forget to set the latest template version as default to be used by Application Migration Service. To do this, select a server and go to Launch settings, then Modify the EC2 Launch Template.

   

   Figure 6 – Customizing EC2 Launch Template settings

   6. When the replication progress reaches 100% you can perform a test to verify the migrated server will run as planned (is the security group configured with the necessary ports open?). You can also give the application owner access to perform a user validation test. As a bonus, testing helps to establish how many minutes the environment will take to be online on AWS, which helps negotiate the application migration window.
   7. Once the testing is complete, it is time for the migration cutover, following which you can decommission the source server. Notice that you can check the status at any time by going to the Migration Hub console under Migrate and selecting Updates.

   3.2 – Using AWS Database Migration Service (DMS)

   AWS DMS helps move your database and analytics workloads to AWS, supporting over 20-plus engines and allowing for homogeneous (same engine) or heterogeneous (between different engines) migrations.

   Now let’s go through the necessary steps to make your first homogeneous database migration. AWS DMS documentation has a comprehensive list of prescriptive step-by-step walkthroughs for other scenarios, including heterogeneous migrations.

   1. Migration Hub continues to guide your journey, this time tracking the database migration progress. To enable this integration in the Migration Hub console, go to Migrate, select Tools, then Connect to link Migration Hub to AWS DMS, so updates can be shared.
   2. Create a replication instance to establish a bridge between the source environment and AWS. On the AWS DMS console, under Migrate data, access Replication instances. Make sure to select a VPC with routing to the source environment and check the costs associated with the replication instance picked.

   

   Figure 7 – Creating a replication instance for AWS DMS

   3. Go to Migrate data and access Endpoints to create both source and target endpoints. An endpoint will be used for the source environment outside AWS and target environment at AWS. You can test the connection to both sides to guarantee the replication will be successful.

   

   Figure 8 – Defining Source and Target database endpoints

   4. Finally, create a task to start moving the database by going to Migrate data and accessing Database migration tasks. You can perform a full, partial, or continuous data replication of the existing database. The task allows for filtering content and transformations during the migration and you can also perform a premigration assessment to identify potential issues, along with data validation to confirm no record was left behind. Notice that at any time you can check the status by going to the Migration Hub console under Migrate, selecting Updates.

   

   Figure 9 – Creating a database migration task on AWS DMS

   Conclusion

   Following these steps, you had a successful first-time journey to AWS using Migration Hub as a central location to understand the server environment, plan the migration, and track progress. Migration Hub helped you Discover (to gather performance and dependency data), Assess (to get the Amazon EC2 instance recommendations and map servers to applications), and Migrate (to track the server and database migration progress).

   Additional Reading:

   Migration Hub also has additional features that I invite you to explore. Check the Strategy section (to generate migration and modernization strategy recommendations), and Orchestrate section (to automate the migration of servers, SQL databases, and SAP NetWeaver environments at scale). These functionalities from Migration Hub will help expedite your migration and modernization journey after this initial experience.

    About the Author

Erico Penna is a Migration Partner Solutions Architect based in the USA who has experience in the storage, backup, disaster recovery, and virtualization areas.   For over 5 years he has been helping customers and partners enhance their migration and modernization practices by facilitating the move of their workloads to the cloud.