Rehost on-premises workloads in the AWS Cloud: migration checklist
Created by Srikanth Rangavajhala (AWS)
Summary
Rehosting on-premises workloads in the Amazon Web Services (AWS) Cloud involves the following migration phases: planning, pre-discovery, discovery, build, test, and cutover. This pattern outlines the phases and their related tasks. The tasks are described at a high level and support about 75% of all application workloads. You can implement these tasks over two to three weeks in an agile sprint cycle.
You should review and vet these tasks with your migration team and consultants. After the review, you can gather the input, eliminate or re-evaluate tasks as necessary to meet your requirements, and modify other tasks to support at least 75% of the application workloads in your portfolio. You can then use an agile project management tool such as Atlassian Jira or Rally Software to import the tasks, assign them to resources, and track your migration activities.
The pattern assumes that you're using AWS Cloud Migration Factory to rehost your workloads, but you can use your migration tool of choice.
Amazon Macie can help identify sensitive data in your knowledge bases, stored as data sources, model invocation logs, and prompt stores in Amazon Simple Storage Service (Amazon S3) buckets. For more information, see the Macie documentation.
Prerequisites and limitations
Prerequisites
Project management tool for tracking migration tasks (for example, Atlassian Jira or Rally Software)
Migration tool for rehosting your workloads on AWS (for example, Cloud Migration Factory)
Architecture
Source platform
On-premises source stack (including technologies, applications, databases, and infrastructure)
Target platform
AWS Cloud target stack (including technologies, applications, databases, and infrastructure)
Architecture
The following diagram illustrates rehosting (discovering and migrating servers from an on-premises source environment to AWS) by using Cloud Migration Factory and AWS Application Migration Service.

Tools
You can use a migration and project management tool of your choice.
Epics
Task | Description | Skills required |
---|---|---|
Groom the pre-discovery backlog. | Conduct the pre-discovery backlog grooming working session with department leads and application owners. | Project manager, Agile scrum leader |
Conduct the sprint planning working session. | As a scoping exercise, distribute the applications that you want to migrate across sprints and waves. | Project manager, Agile scrum leader |
Task | Description | Skills required |
---|---|---|
Confirm application knowledge. | Confirm and document the application owner and their knowledge of the application. Determine whether there's another point person for technical questions. | Migration specialist (interviewer) |
Determine application compliance requirements. | Confirm with the application owner that the application doesn't have to comply with requirements for Payment Card Industry Data Security Standard (PCI DSS), Sarbanes-Oxley Act (SOX), personally identifiable information (PII), or other standards. If compliance requirements exist, teams must finish their compliance checks on the servers that will be migrated. | Migration specialist (interviewer) |
Confirm production release requirements. | Confirm the requirements for releasing the migrated application to production (such as release date and downtime duration) with the application owner or technical contact. | Migration specialist (interviewer) |
Get server list. | Get the list of servers that are associated with the targeted application. | Migration specialist (interviewer) |
Get the logical diagram that shows the current state. | Obtain the current state diagram for the application from the enterprise architect or the application owner. | Migration specialist (interviewer) |
Create a logical diagram that shows the target state. | Create a logical diagram of the application that shows the target architecture on AWS. This diagram should illustrate servers, connectivity, and mapping factors. | Enterprise architect, Business owner |
Get server information. | Collect information about the servers that are associated with the application, including their configuration details. | Migration specialist (interviewer) |
Add server information to the discovery template. | Add detailed server information to the application discovery template (see | Migration specialist (interviewer) |
Publish the application discovery template. | Share the application discovery template with the application owner and migration team for common access and use. | Migration specialist (interviewer) |
Task | Description | Skills required |
---|---|---|
Confirm server list. | Confirm the list of servers and the purpose of each server with the application owner or technical lead. | Migration specialist |
Identify and add server groups. | Identify server groups such as web servers or application servers, and add this information to the application discovery template. Select the tier of the application (web, application, database) that each server should belong to. | Migration specialist |
Fill in the application discovery template. | Complete the details of the application discovery template with the help of the migration team, application team, and AWS. | Migration specialist |
Add missing server details (middleware and OS teams). | Ask middleware and operating system (OS) teams to review the application discovery template and add any missing server details, including database information. | Migration specialist |
Get inbound/outbound traffic rules (network team). | Ask the network team to get the inbound/outbound traffic rules for the source and destination servers. The network team should also add existing firewall rules, export these to a security group format, and add existing load balancers to the application discovery template. | Migration specialist |
Identify required tagging. | Determine the tagging requirements for the application. | Migration specialist |
Create firewall request details. | Capture and filter the firewall rules that are required to communicate with the application. | Migration specialist, Solutions architect, Network lead |
Update the EC2 instance type. | Update the Amazon Elastic Compute Cloud (Amazon EC2) instance type to be used in the target environment, based on infrastructure and server requirements. | Migration specialist, Solutions architect, Network lead |
Identify the current state diagram. | Identify or create the diagram that shows the current state of the application. This diagram will be used in the information security (InfoSec) request. | Migration specialist, Solutions architect |
Finalize the future state diagram. | Finalize the diagram that shows the future (target) state for the application. This diagram will also be used in the InfoSec request. | Migration specialist, Solutions architect |
Create firewall or security group service requests. | Create firewall or security group service requests (for development/QA, pre-production, and production). If you're using Cloud Migration Factory, include replication-specific ports if they're not already open. | Migration specialist, Solutions architect, Network lead |
Review firewall or security group requests (InfoSec team). | In this step, the InfoSec team reviews and approves the firewall or security group requests that were created in the previous step. | InfoSec engineer, Migration specialist |
Implement firewall security group requests (network team). | After the InfoSec team approves the firewall requests, the network team implements the required inbound/outbound firewall rules. | Migration specialist, Solutions architect, Network lead |
Task | Description | Skills required |
---|---|---|
Import the application and server data. |
If you aren't using Cloud Migration Factory, follow the instructions for setting up your migration tool. | Migration specialist, Cloud administrator |
Check prerequisites for source servers. | Connect with the in-scope source servers to verify prerequisites such as TCP port 1500, TCP port 443, root volume free space, .NET Framework version, and other parameters. These are required for replication. For additional information, see the Cloud Migration Factory Implementation Guide. | Migration specialist, Cloud administrator |
Create a service request to install replication agents. | Create a service request to install replication agents on the in-scope servers for development/QA, pre-production, or production. | Migration specialist, Cloud administrator |
Install the replication agents. | Install the replication agents on the in-scope source servers on the development/QA, pre-production, or production machines. For additional information, see the Cloud Migration Factory Implementation Guide. | Migration specialist, Cloud administrator |
Push the post-launch scripts. | Application Migration Service supports post-launch scripts to help you automate OS-level activities such as installing or uninstalling software after you launch target instances. This step pushes the post-launch scripts to Windows or Linux machines, depending on the servers identified for migration. For instructions, see the Cloud Migration Factory Implementation Guide. | Migration specialist, Cloud administrator |
Verify the replication status. | Confirm the replication status for the in-scope source servers automatically by using the provided script. The script repeats every five minutes until the status of all source servers in the given wave changes to Healthy. For instructions, see the Cloud Migration Factory Implementation Guide. | Migration specialist, Cloud administrator |
Create the admin user. | A local admin or sudo user on source machines might be needed to troubleshoot any issues after migration cutover from the in-scope source servers to AWS. The migration team uses this user to log in to the target server when the authentication server (for example, the DC or LDAP server) is not reachable. For instructions for this step, see the Cloud Migration Factory Implementation Guide. | Migration specialist, Cloud administrator |
Validate the launch template. | Validate the server metadata to make sure it works successfully and has no invalid data. This step validates both test and cutover metadata. For instructions, see the Cloud Migration Factory Implementation Guide. | Migration specialist, Cloud administrator |
Task | Description | Skills required |
---|---|---|
Create a service request. | Create a service request for the infrastructure team and other teams to perform application cutover to development/QA, pre-production, or production instances. | Migration specialist, Cloud administrator |
Configure a load balancer (optional). | Configure required load balancers, such as an Application Load Balancer or an F5 load balancer | Migration specialist, Cloud administrator |
Launch instances for testing. | Launch all target machines for a given wave in Application Migration Service in test mode. For additional information, see the Cloud Migration Factory Implementation Guide. | Migration specialist, Cloud administrator |
Verify the target instance status. | Verify the status of the target instance by checking the bootup process for all in-scope source servers in the same wave. It may take up to 30 minutes for the target instances to boot up. You can check the status manually by logging in to the Amazon EC2 console, searching for the source server name, and reviewing the Status check column. The status 2/2 checks passed indicates that the instance is healthy from an infrastructure perspective. | Migration specialist, Cloud administrator |
Modify DNS entries. | Modify Domain Name System (DNS) entries. (Use NoteMake sure that there are no DNS conflicts between on-premises and AWS Cloud servers. This step and the following steps are optional, depending on the environment where the server is hosted. | Migration specialist, Cloud administrator |
Test connectivity to backend hosts from EC2 instances. | Check the logins by using the domain credentials for the migrated servers. | Migration specialist, Cloud administrator |
Update the DNS A record. | Update the DNS A record for each host to point to the new Amazon EC2 private IP address. | Migration specialist, Cloud administrator |
Update the DNS CNAME record. | Update the DNS CNAME record for virtual IPs (load balancer names) to point to the cluster for web and application servers. | Migration specialist, Cloud administrator |
Test the application in applicable environments. | Log in to the new EC2 instance and test the application in the development/QA, pre-production, and production environments. | Migration specialist, Cloud administrator |
Mark as ready for cutover. | When testing is complete, change the status of the source server to indicate that it's ready for cutover, so users can launch a cutover instance. For instructions, see the Cloud Migration Factory Implementation Guide. | Migration specialist, Cloud administrator |
Task | Description | Skills required |
---|---|---|
Create production deployment plan. | Create a production deployment plan (including a backout plan). | Migration specialist, Cloud administrator |
Notify operations team of downtime. | Notify the operations team of the downtime schedule for the servers. Some teams might require a change request or service request (CR/SR) ticket for this notification. | Migration specialist, Cloud administrator |
Replicate production machines. | Replicate production machines by using Application Migration Service or another migration tool. | Migration specialist, Cloud administrator |
Shut down in-scope source servers. | After you verify the source servers’ replication status, you can shut down the source servers to stop transactions from client applications to the servers. You can shut down the source servers in the cutover window. For more information, see the Cloud Migration Factory Implementation Guide. | Cloud administrator |
Launch instances for cutover. | Launch all target machines for a given wave in Application Migration Service in cutover mode. For more information, see the Cloud Migration Factory Implementation Guide. | Migration specialist, Cloud administrator |
Retrieve target instance IPs. | Retrieve the IPs for target instances. If the DNS update is a manual process in your environment, you would need to get the new IP addresses for all target instances. For more information, see the Cloud Migration Factory Implementation Guide. | Migration specialist, Cloud administrator |
Verify target server connections. | After you update the DNS records, connect to the target instances with the host name to verify the connections. For more information, see the Cloud Migration Factory Implementation Guide. | Migration specialist, Cloud administrator |
Related resources
Attachments
To access additional content that is associated with this document, unzip the following file: attachment.zip