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
Source platform
Target platform
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.
Groom the pre-discovery backlog.
Conduct the pre-discovery backlog grooming working session with department leads and application owners.
Conduct the sprint planning working session.
As a scoping exercise, distribute the applications that you want to migrate across sprints and waves.
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.
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.
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.
Get server list.
Get the list of servers that are associated with the targeted application.
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.
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.
Get server information.
Collect information about the servers that are associated with the application, including their configuration details.
Add server information to the discovery template.
Add detailed server information to the application discovery template (see mobilize-application-questionnaire.xlsx in the attachment for this pattern). This template includes all the application-related security, infrastructure, operating system, and networking details.
Publish the application discovery template.
Share the application discovery template with the application owner and migration team for common access and use.
Confirm server list.
Confirm the list of servers and the purpose of each server with the application owner or technical lead.
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.
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.
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.
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.
Identify required tagging.
Determine the tagging requirements for the application.
Create firewall request details.
Capture and filter the firewall rules that are required to communicate with the application.
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.
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.
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.
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.
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.
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.
Import the application and server data.
If you aren't using Cloud Migration Factory, follow the instructions for setting up your migration tool.
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.
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.
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.
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.
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.
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.
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.
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.
Configure a load balancer (optional).
Configure required load balancers, such as an Application Load Balancer or an F5 load balancer with iRules.
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.
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.
Modify DNS entries.
Modify Domain Name System (DNS) entries. (Use resolv.conf or host.conf for a Microsoft Windows environment.) Configure each EC2 instance to point to the new IP address of this host.
Note: Make 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.
Test connectivity to backend hosts from EC2 instances.
Check the logins by using the domain credentials for the migrated servers.
Update the DNS A record.
Update the DNS A record for each host to point to the new Amazon EC2 private IP address.
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.
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.
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.
Create production deployment plan.
Create a production deployment plan (including a backout plan).
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.
Replicate production machines.
Replicate production machines by using Application Migration Service or another migration tool.
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.
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.
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.
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.
To access additional content that is associated with this document, unzip the following file: attachment.zip
Reduce homogeneous SAP migration cutover time Set up Multi-AZ infrastructure for a SQL Server Always On FCI Did this page help you? - YesThanks for letting us know we're doing a good job!
If you've got a moment, please tell us what we did right so we can do more of it.
Did this page help you? - NoThanks for letting us know this page needs work. We're sorry we let you down.
If you've got a moment, please tell us how we can make the documentation better.
