NEW - You can now accelerate your migration and modernization with AWS Transform. Read [Getting Started](https://docs.aws.amazon.com/transform/latest/userguide/getting-started.html) in the *AWS Transform User Guide*. # Launching test and cutover instances Launching test and cutover instances AWS Application Migration Service (AWS MGN) allows you to launch test and cutover instances in AWS. Prior to launching instances, you must configure your Launch settings. The following documentation explains how to configure Launch settings and how to launch Test and cutover instances using the configured settings. Launch settings determine how your test and cutover instances are launched in AWS. Through Launch settings, you can fully customize your test and cutover instances by configuring key metrics, such as the subnet within which the instance is launched, the instance type to be used, licence transfers, replication status, and a variety of other settings. AWS MGN ensures that your test and cutover instances constantly abide by the latest AWS security, instance, and other updates by utilizing EC2 launch templates. EC2 launch templates always use the latest EC2 instance and technology. They integrate with Application Migration Service in order to give you full control over every single setting within your test and cutover instance. Once you have configured your instance's launch settings, you can launch them directly through the AWS MGN console. During the launch process, either during test or cutover instance launch, the AWS replication agent is removed from the test or cutover instance, and does not run on it. **Topics** + [ # Preparing for test and cutover instance launch ](launch-preparation.md) + [ # Launch settings ](launch-settings.md) + [ # Launching test instances ](launching-test-servers.md) + [ # Launching cutover instances ](launch-cutover.md) + [ # Review launch history ](jobs.md) # Preparing for test and cutover instance launch Prior to launching your instances, you must ensure that your environment is set up properly to ensure successful launches. Check the following prior to continuing: + Prepare your subnets for launch - Plan which subnets you will use to launch your test and cutover instances. You use these subnets in your EC2 launch template when you configure your Launch settings. + Create security groups within the subnets - Create the Security groups you want to use within your prepared subnets. You set these Security groups in your EC2 Launch template when you configure launch settings. **Note** Customers that want to run a proof of concept can skip this step. AWS Application Migration Service automatically uses the default subnet and Security groups. Make sure that you have not deleted your default subnet. # Launch settings The launch settings include two sections: the general launch settings, and the EC2 launch template, which determine how a test or cutover instance is launched for each source server in AWS. Launch settings, including the EC2 launch template, are automatically created each time you add a source server to AWS Application Migration Service. The launch settings can be modified at any time, including before the source server has completed its initial sync. **Note** Any changes made to the launch settings only affect newly launched test and cutover instances. **Note** For many customers, there is no need to modify the launch settings or the EC2 launch template in order to launch test or cutover instances. Launch settings can only be changed for one server at a time though the AWS Application Migration Service console. **Note** You can modify launch settings for multiple servers at a time by using the AWS Application Migration Service API. You can access the launch settings of a specific source server through the server details view by choosing its Hostname from the **Source servers** page. Within the individual server view, navigate to the **Launch settings** tab. The **Launch settings** tab is divided into two sections: + General launch settings + EC2 launch template # General launch settings The **General launch settings** section allows you to control a variety of server-specific settings. Click **Edit** to change the general settings. Make your changes and then choose **Save settings** to finalize your changes. **Topics** + [ # Instance type right-sizing ](right-sizing.md) + [ # Start instance upon launching ](start-launch.md) + [ # Copy Private IP ](copy-private.md) + [ # Operating system licensing ](os-licensing.md) + [ # Transfer server tags ](transfer-tags.md) + [ # Boot mode ](boot-mode.md) # Instance type right-sizing AWS Application Migration Service launches a new instance type after every change of configuration on the source server, for example, added/removed disks, and added/removed RAM. When you use the instance type right-sizing feature Application Migration Service launches a test or cutover instance type that best matches the OS, CPU, and RAM of your source server. Set this feature to **On** to enable or to **None** to disable, in which case Application Migration Service launches the instance type as configured in your Amazon EC2 launch template. Enable instance type right-sizing if you want to determine the instance type that is launched in AWS for all your test or cutover servers. **Important considerations:** + The AWS instance type selected by AWS Application Migration Service when this feature is activated overwrites the instance type defined in your EC2 launch template. + Hardware changes and the resulting AWS instance type change may take up to 90 minutes to be processed by AWS Application Migration Service. + The T family instance type is not supported for right-sizing. If you want to use the T family, avoid using right-sizing. + The available capacity for each Amazon EC2 instance type varies by Availability Zone and Region, and may be subject to your specific AWS account limits. For mission-critical workloads consider using [Reserved Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html) to guarantee capacity for specific instance types. Note that additional costs apply when reserving capacity. + The right-sizing instance type selected by AWS Application Migration Service appears on the **Server details** tab. **Supported instance families:** The service provides recommendations from these instance families, which are available in most target Regions: + c5 + m5 + c4 + m4 + r5 + r4 + i3 + d2 **Supported instance families for the Thailand and Malaysia Regions:** The *Asia Pacific (Thailand) *, and *Asia Pacific (Malaysia) * Regions support only these instance families: + C6i + m6i + r6i # Start instance upon launching Choose whether you want to start your test and cutover instances automatically upon launch or whether you want to launch them in a stopped state. If you choose **Yes**, the test or cutover AWS instances are launched and started automatically upon test or cutover launch. If you choose **No**, the instances are launched in a stopped state and you have to start the test or cutover AWS instance manually from the Amazon EC2 console. # Copy Private IP Choose whether you want AWS Application Migration Service to ensure that the private IP used by the test or cutover instance matches the private IP used by the source server. AWS Application Migration Service monitors the source server on an hourly basis to identify the private IP. Application Migration Service uses the private IP of the primary network interface. The **No** option is chosen by default. Click **No** if you do not want the private IP of the test or cutover instance to match that of the source machine. Click **Yes** if you want to use a private IP. The IP is shown in brackets next to the option. **Note** Private IP is not supported for IPv6. Removing a private IP from a specific server's settings does not remove it from the launch template. If you chose **Yes**, ensure that the IP range of the subnet you set in the EC2 launch template includes the private IP address. If the both the source server and the test or cutover instance shares the same subnet though a VPN, then the source private IP is already in use, and the **Copy private IP** option should not be used. # Operating system licensing Choose whether you want to Bring Your Own Licenses (BYOL) from the source server into the test or cutover instance. Choose the **BYOL** option if you are migrating a Linux server. All Linux licenses are BYOL by default. Any RHEL, SUSE or Debian licenses are transferred in their current form to the migrated instance. Make sure to ensure that the terms of your licenses allow this license transfer. Choose the **BYOL** option if you want to BYOL your Windows licenses. This sets up a dedicated host. All the licenses from the source Windows source server are automatically transferred to the Test or Cutover instance. [Learn more about dedicated hosts.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-hosts-overview.html) **Important** If you activate BYOL licensing for Windows, you have to change the **Placement.tenancy** type in the EC2 launch template to **Host**. Otherwise, instance launch fails. **Note** Windows Desktop Editions require BYOL – [note the specific restrictions for AWS Provided Licenses](https://aws.amazon.com/windows/faq/#buy-win-cl). If you are using Windows Servers datacenter: Azure addition, [note the specified restrictions for BYOL](https://www.microsoft.com/licensing/terms/productoffering/WindowsServerStandardDatacenterEssentials/EAEAS#UseRights). # Transfer server tags Choose whether you want AWS Application Migration Service to transfer any user-configured custom tags from your source servers onto your test or cutover instance. If you choose **Yes**, server tags are transferred. These tags are attached to all source servers, all launched test and cutover instances, and all of the ephemeral resources that are created on your AWS Account during the normal operation of AWS Application Migration Service. These resources include: + EC2 instances + Conversion groups + Security groups + EBS volumes + Snapshots **Note** AWS Application Migration Service automatically adds system tags to all resources. **Note** Transfer server tags only copies tags associated with the source servers in the AWS Application Migration Service console, and does not copy the EC2 source server tags (in case of AWS to AWS migration) If you choose the **No** option, server tags are not transferred. You can always add tags from the Amazon EC2 console as described in [this EC2 article.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#tag-resources)%5C) **Note** Tags that are added on the EC2 launch template take precedence over tags that are transferred directly from the source server. # Boot mode Choose the boot mode for the test or cutover instance. You can either choose the **Legacy BIOS**, **UEFI** or **Use source boot mode**. By default, the boot mode is set to **Use source boot mode**. When this option is selected, MGN launches the test or cutover instance using the same boot mode as the source server. **Note**: When the BIOS option is chosen, Application Migration Service converts any non-BIOS instance type to BIOS. As such, the server is limited to four partitions that cannot equal more than 2TiB due to BIOS limitations. **Note** You must choose the **UEFI** boot mode for any BYOL source server that is UEFI, as Application Migration Service is unable to convert BYOL source servers that boot in UEFI to BIOS. **Note** UEFI boot is only available for Nitro instances. All Nitro based instance types can also run on UEFI instead of Legacy BIOS. UEFI is not supported in CentOS 6 and Rhel 6. Refer to [this page for a list of supported instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html). # EC2 launch template AWS Application Migration Service utilizes EC2 launch templates to launch test and cutover EC2 instances for each source server. The EC2 launch template is created automatically for each source server that is added to AWS MGN upon the installation of the AWS Replication Agent. **Note** AWS MGN selects defaults to provide the best performance while migrating your servers to AWS. We recommend you review the EC2 launch template to ensure the selected templates are suitable for your use case. You cannot use the same template for multiple servers. The Launch template can only be edited from the Amazon EC2 console. Many EC2 launch template settings can be changed, but some may not be used by the AWS MGN launch process and some may interfere with IT. [Learn more about individual launch template settings.](detailed-considerations.md) **Important** You must set the EC2 launch template you want to use with AWS MGN as the **default** launch template. The EC2 launch template does not automatically set a specific subnet. As such, EC2 attempts to launch in a subnet within the default VPC. If you have removed your default VPC, EC2 fails to launch any instance for which there is no valid subnet specified. Ensure that you specify a subnet if that is the case, or AWS MGN instance launch fails. The AWS MGN EC2 launch template panel shows a summary of the key template values. To view all the values or to change any of them: 1. Click **Modify**. 1. When the **About modifying EC2 launch templates** dialog appears, click **Modify**. This redirects you to **EC2 > Launch templates > Modify template** in a new tab, where you'll be able to make any necessary changes. Learn more about EC2 launch template settings and configuration options in [this EC2 article](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html). # Selecting the default template AWS MGN uses the version of the Launch template that is marked as default. In order to select the default launch template, on the **Modify template (Create new version)** page, under the **Launch template name and version description** category, open the **Source template** menu and choose the EC2 launch template you want to use as the default template from the drop-down menu. Every time you modify the Launch template, a new version of the launch template is created. You are notified that the Launch template has been modified and that a new version (version number) has been created. Make sure to take note of the version number and the **Launch template ID** so that you could easily identify your launch template and version. **Note** It's good practice to delete versions of the launch template that you no longer need. To set the new version of your launch template as the default: 1. Navigate back to the main **EC2 > Launch templates** page. 1. Choose your launch template by selecting the toggle to the left of the **Launch template ID**. 1. Open the Actions menu and choose **Set default version**. 1. Select the **Template version** from the drop-down menu and then choose **Set as default version**. The Amazon EC2 console confirms the version change. # Launch template cleanup and fixing AWS Application Migration Service (AWS MGN) runs a mechanism every hour to ensure that the settings selected are correct. This mechanism can fix issues such as an incorrect instance type, but it cannot fix other settings and augmentations. Ensure that you follow the instructions in the following sections and do not change or edit any fields that should not be changed. If you encounter any issues with the launch template, you can negate all of your changes and fix all issues rapidly by choosing the original default launch template that was first automatically created by Application Migration Service upon Agent installation. # Launch template key considerations There are several key considerations when configuring your EC2 launch template. Review these key considerations as well as the [full launch settings](detailed-considerations.md) before creating your launch template. 1. **Instance Type** – Ensure that you select an instance type that matches the hardware requirements of your source server. AWS Application Migration Service always utilizes the instance type that is set on the Amazon EC2 launch template unless the **Instance right-sizing** feature is activated. **Note** If you change your instance type and do not deactivate the instance right-sizing feature, then AWS Application Migration Service uses the instance type determined by the **Instance right-sizing** feature and not the instance type you chose in the EC2 launch template. Application Migration Service verifies the instance type once per hour, as a result, if you did not deactivate the instance right-sizing feature, the first time instance launch may still utilize the instance type you set in the EC2 launch template, but any subsequent launches use the right-sizing instance. The available capacity for each Amazon EC2 instance type varies by Availability Zone and Region, and may be subject to your specific AWS account limits. For mission-critical workloads consider using [Reserved Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html) to guarantee capacity for specific instance types. Note that additional costs apply when reserving capacity. 1. **Subnet** – You can select an existing subnet or create a new subnet. **Note** Customers that do not have a default VPC must modify the EC2 launch template and explicitly define the subnet in which to launch. Failure to do so results in errors when launching test or cutover instances. 1. **Private IP** – If you use the **Copy private IP** feature, then do not add your own IP to the EC2 launch template. Private IP is not supported for IPv6. 1. **Private IP and Subnet** – Each subnet contains a CIDR block of IP ranges. If you use the **Copy private IP** feature, then ensure that this IP is included in the CIDR block range. Otherwise, instance launch fails. 1. **Private IP and ENI** – Make sure that you deactivate the **Copy private IP** feature if you wish to define an ENI to use on the EC2 launch template. 1. **Network interfaces** – The EC2 launch template only supports two network interfaces. If you require more than two network interfaces, you need to define them after the test or cutover instance has been launched. This can be done through a post launch action. If you wish to use an Elastic IP, you must create an ENI to specify the IP and then edit the Network interfaces to use the ENI. Learn more about working with Amazon Elastic Inference in [this Developer Guide article.](https://docs.aws.amazon.com/elastic-inference/latest/developerguide/working-with-ei.html) 1. **Networking platform** – AWS Application Migration Service only supports **Virtual Private Cloud (VPC)**. EC2-Classic is **not** supported. Do **not** add any security groups under the network platform. 1. **Custom device name** – Do not alter this field. AWS Application Migration Service uses the device name as defined on the source server in order to map disks on the test or cutover instance. You can use this field to identify your disks. 1. **Disks** – You cannot add disks to the EC2 launch template. Any disks that are added that do not exist on the source machine are ignored by AWS Application Migration Service. 1. **Launch template name** – Do not alter this field. AWS Application Migration Service automatically names this field. 1. **System tag** – Do not alter this field. Application Migration Service automatically adds system tags that match the EC2 launch template to the specific source server. You can recognize which source server the launch template is matched with by the **ID** field. 1. **Automatic cleanup** – Application Migration Service deletes the EC2 launch template and launch configuration for machines that have been disconnected from AWS Application Migration Service or machines for which the cutover has been finalized 90 minutes after disconnect or cutover finalization. This aids in ensuring that your account does not surpass the AWS 5000 EC2 launch template limit. 1. **Volumes** – For each EBS volume, the service uses the user-selected values. If no matching volume exists in the launch template, the service uses the default value. If the launch template includes a volume that does not exist in the source server, the system disregards the specific volume. If you delete the EC2 launch template, the service creates a new one with default values. **Note** If you wish to set a KMS key, you should do so through the [EBS Encryption ](replication-server-settings.md#ebs-encryption)section of the replication settings within the AWS Application Migration Service console. # Full launch template setting review This section reviews the entire EC2 launch template and identifies which fields should and should not be changed in order for the EC2 launch template to work with Application Migration Service. Editing or changing any fields that are marked as "do not edit" or "do not change" can cause AWS Application Migration Service to not function. + **Launch template name** – This name is automatically generated when the template is first created upon Agent installation. The name cannot be changed. + **Template version description** – You can give the template any description you wish. + **AMI** – Customers do not typically choose a specific AMI to include in the launch template. If you edit the launch template to use an existing AMI, the contents of the AMI are not used by AWS Application Migration Service. If the AMI is not configured properly (licensing, flags, and more), then this may prevent the test or cutover instance launched from booting correctly or from being properly licensed. + **Instance type** – You can select any instance type you want. The launch template shows the instance type suggested by AWS Application Migration Service. + **Key pair (login)** – **Do not** alter this field. Do not include a key pair with the launch template. + **Networking platform** – Be sure to select **Virtual Private Cloud (VPC)**. **EC2-Classic** is **not** supported. + **Security groups** – **Do not** add Security group here. This field should remain blank. You can add security groups later under **Network interface**. + **Storage (volumes)** – This section shows all of the disks that you chose to replicate from your source server upon AWS Replication Agent installation. **Important** Initial settings for EBS volumes are not derived from activity on the Source Server. Default values are chosen to give maximum performance on first launch. Each disk is composed of the following fields: + **Storage type** – Shows the default volume type (EBS). This cannot be changed. + **Device name** – **Do not** change or edit this field. The device name shown here corresponds to the disk name on the source server. This field allows you to identify which disk is which. + **Snapshot** – **Do not** change or edit this field. Snapshots should not be included in the launch template. + **Size** – **Do not** change or edit this field. + **Volume type** – You can select any volume type you want to use. AWS Application Migration Service automatically sets **General Purpose SSD (gp3)** as the default. You may want to change the volume type in order to reduce costs. Ensure that you read the caveats in the [EBS documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html#initialize). + **IOPS** – Set the number of I/O operations per second that the volume can support. You can select any number as long as it matches the [EBS guidelines](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html). + Provisioned IOPS SSD (io1) : 50 IOPS per GiB of storage + Provisioned IOPS SSD (io2) : 500 IOPS per GiB of storage + General Purpose SSD (gp3) : 500 IOPS per GiB of storage AWS Application Migration Service automatically provisions the maximum IOPS possible for the volume, based on the above ratio. This is to minimize the impact of the [performance penalty](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSPerformance.html#initialize) when working with EBS volumes created from snapshots. + **Delete on termination** – Do **not** change or edit this field. This should not be included in the launch template. + **Encrypted** – **Do not** change or edit this field. This should not be included in the launch template. + **Key** – **Do not** change or edit this field. This should not be included in the launch template. + **Add volume** – **Do not** use this functionality. You cannot add volumes to the source server through the launch template. + **Remove (volume)** – **Do not** use this functionality. You cannot remove volumes from the source server through the launch template. If you do, AWS MGN automatically creates a volume using the default volume settings. + **Resource tags** – You can add up to 50 tags. These are transferred to your test and cutover instances. Note that these tags may interfere with other tags that have already been added to the source server. Launch template tags always take precedence over tags set in the AWS MGN console or tags manually assigned to the server. + **Network interfaces** – The network interface is created by default based on your replication template. The network interface section is composed of the following fields: + **Device index** – **Do not** change or edit this field. The value should always be "**0**". + **Network interface** – Use this option only if you want use a pre-existing ENI (Elastic Network Interface). The Launch Template overwrites certain ENI settings. Use this if you want to add an Elastic IP. You have to attach the Elastic IP to the ENI. **Note** When selecting an pre-existing ENI, you must change the **Auto-assign public IP** value to **Don't include in launch template** for a successful target launch. + **Description** – Add an optional description for the network interface (if chosen). + **Subnet** – Choose the subnet. This is the subnet within which the network interface is located and the test or cutover instance is launched. AWS Application Migration Service selects the default VPC subnet by default (if one exists). + **Auto-assign public IP** - Choose whether you want the public IP to be auto-assigned. + **Primary IP** – Use this field if you wish to utilize a private IP. The private IP you set in the **Copy private IP** field in the AWS MGN launch settings is copied to this field. + **Secondary IP** - Define a secondary IP, if needed. + **IPv6 IPs** – Define IPv6 IPs if needed. + **Security groups** – Choose a security group. If no security group is chosen, then the default VPC security group is used by default. + **Delete on termination** – We suggest choosing "**Yes**". Choosing "**No**" makes this network interface a permanent ENI. + **Elastic Fabric Adapter** – **Do not** change or edit this field. + **Network card index** – **Do not** change or edit this field. + **Add network interface** – Note that the EC2 launch template only supports two network interfaces. If you require more than two network interfaces, you need to define them after the test or cutover instance has been launched. This can be done through a post-launch action. + **Advanced details** – In this section, we focus on the fields you should **not** change or edit in order to allow AWS Application Migration Service to function properly. **Do not** change or edit any of the following fields: + RAM disk ID + Kernel + Nitro Enclave + Metadata accessible # Saving your EC2 launch template Once you have finished editing your template, save it by choosing **Create template version** at the bottom of the template. # Launching test instances After you have added all of your source servers and configured their launch settings, you are ready to launch a test instance. It is crucial to test the migration of your source servers to AWS prior to initiating a cutover in order to verify that your source servers function properly within the AWS environment. **Important** It is a best practice to perform a test at least two weeks before you plan to migrate your source servers. This time frame allows you to identify potential problems and solve them, before the actual cutover takes place. After launching test instances, use either SSH (Linux) or RDP (Windows) to connect to your instance and ensure that everything is working correctly. When launching a test or cutover instance, you can launch up to 100 source servers in a single operation. Additional source servers can be launched in subsequent operations. You can test one source server at a time, or simultaneously test multiple source servers. For each source server, you are informed of the success or failure of the test. You can test your source server as many times as you want. Each new test first deletes any previously launched Test instance and dependent resources. Then, a new test instance is launched, which reflects the most up-to-date state of the source server. After the test, data replication continues as before. The new and modified data on the source server is transferred to the Staging Area Subnet and not to the test instances that were launched during the test. **Note** Windows source servers need to have at least 2 GB of free space to successfully launch a test instance. Take into consideration that once a test instance is launched resources are used in your AWS account and you will be billed for these resources. You can terminate the operation of launched Test instances once you verify that they are working properly without impact in order to data replication. **Topics** + [ # Review ready for testing indicators ](ready-for-testing.md) + [ # Starting a test ](starting-test.md) + [ # Reverting a test ](revert-finalize-test.md) + [ # Marking as Ready for cutover ](finalizing-test.md) # Review ready for testing indicators Ready for testing indicators Prior to launching a Test instance, ensure that your source servers are ready for testing by looking for the following indicators on the **Source servers** page: 1. Under the **Migration lifecycle** column, the server should show **Ready for testing**. 1. Under the **Data replication status** column, the server should show the **Healthy** status. 1. Under the **Next step** column, the server should show **Launch test instance** # Starting a test To launch a test instance for a single source server or multiple source servers: 1. Go to the **Source servers** page. 1. Check the box to the left of each server for which you want to launch a test instance. 1. Open the **Test and cutover** menu. 1. Under **Testing**, choose the **Launch test instances** option to launch a test instance for this server. 1. When the **Launch test instances for X servers** dialog appears, click **Launch** to begin the test. The AWS Application Migration Service console indicates **Launch job started** when the test has started. Choose **View job details** on the dialog to view the specific job for the test launch in the **Launch history** tab. ## Successful test launch indicators You can tell that the test instance launch started successfully through several indicators on the **Source servers** page. 1. The Alerts column shows the **Launched** status, indicating that a Test instance has been launched for this server. 1. The **Migration lifecycle** column shows **Test in progress**. 1. The **Next step** column shows **Complete testing and mark as 'Ready for cutover'**. # Reverting a test After you have launched your test instances, open the Amazon EC2 console and SSH or RDP into your test instances in order to ensure that they function correctly. Validate connectivity and perform acceptance tests for your application. If you encounter any issues and want to launch new Test instances, or if you are performing a scheduled test and plan to perform additional tests prior to cutover, you can revert the test. This reverts your source servers' **Migration lifecycle** status to **Ready for testing** , indicating that these servers still require additional testing before they are ready for cutover. During a revert, you also have the option to delete your Test instances for cost-saving purposes. To revert a test: 1. Check the box to the left of every source server that has a launched Test instance for which you want to revert the test. 1. Open the **Test and cutover** menu. 1. Under **Testing**, choose **Revert to "ready for testing"**. 1. The **Revert testing for X servers** dialog appears. Select whether you want to terminate the launched instances used for testing. It is recommended to terminate these instances, as you will be charged for them even though you no longer need them. Check the **Yes, terminate launched instances (recommended)** box and choose **Revert**. The AWS Application Migration Service console indicates that testing has been reverted. The selected source servers' **Migration lifecycle** column shows the **Ready for testing** status, the **Next step** column shows **Launch test instance** and the launched Test instances are deleted if that option was selected. # Marking as Ready for cutover If you are completely done with your testing and are ready for cutover, you can finalize the test. This changes your source servers' **Migration lifecycle** status to **Ready for cutover**, indicating that all testing is complete and that these servers are now ready for cutover. You also have the option to delete your Test instances for cost saving purposes. To finalize a test: 1. Check the box to the left of every source server that has a launched Test instance for which you want to finalize the test. 1. Open the **Test and cutover** menu. 1. Under **Testing**, choose **Mark as "Ready for cutover"**. 1. When the **Mark X servers as "Ready for cutover"** dialog appears, select whether you want to terminate the launched instances used for testing. It is recommended to terminate these instances, as you will be charged for them even though you no longer need them. Check the **Yes, terminate launched instances (recommended)** box and click **Continue**. The AWS Application Migration Service console confirms that the servers were marked as ready for cutover. The AWS Application Migration Service console indicates that testing has been finalized. The selected source servers' **Migration lifecycle** column shows the **Ready for cutover** status and the launched Test instances are deleted if that option was selected. The **Next step** column shows **Terminate launched instance; Launch cutover instance**. You can now terminate the launched Test instance directly from the Amazon EC2 console as that instance is no longer needed (if you have not done so already through the AWS MGN console). You can quickly access the Test instance by navigating to the specific servers > **Server details > Migration dashboard > Lifecycle > Launch status** and choosing **view in EC2 console**. The Amazon EC2 console automatically searches for and displays the Test instance. Select the instance, open the **Instance state** menu, and choose **Terminate instance**. Click **Terminate**. # Launching cutover instances Once you have finalized the testing of all of your source servers, you are ready for cutover. You should perform the cutover at a set date and time. The cutover migrates your source servers to the cutover instances on AWS. **Important** It is a best practice to perform a test at least two weeks before you plan to migrate your source servers. This time frame allows you to identify potential problems and solve them, before the actual migration takes place. After launching Test instances, use either SSH (Linux) or RDP (Windows) to connect to your instance and ensure that everything is working correctly. You can cutover one source server at a time, or simultaneously cutover multiple source servers. For each source server, you are informed of the success or failure of the cutover. For each new cutover, AWS Application Migration Service first deletes any previously launched Test instance and dependent resources. Then, it launches a new cutover instance which reflects the most up-to-date state of the source server. After the cutover, data replication continues as before. The new and modified data on the source server is transferred to the staging area subnet, and not to the cutover instances that were launched during the cutover. **Topics** + [ # Ready for cutover indicators ](ready-for-cutover.md) + [ # Starting a cutover ](starting-cutover.md) + [ # Reverting a cutover ](revert-finalize-cutover.md) + [ # Finalizing a cutover ](finalizing-cutover-2.md) # Ready for cutover indicators Prior to launching a cutover instance, ensure that your source servers are ready for cutover by looking for the following indicators on the **Source servers** page: 1. Under the **Migration lifecycle** column, the server should show **Ready for cutover** . 1. Under the **Data replication status** column, the server should show the **Healthy** status. 1. Under the **Next step** column, the server should show **Terminate launched instance; Launch cutover instance** if you have not terminated your latest launched test instance. 1. Alternatively, the Next step column shows **Launch cutover instance** if you have terminated your latest launched test instance. # Starting a cutover To launch a cutover instance for a single source server or multiple source servers, go to the **Source servers** page and check the box to the left of each server you want to cutover. Open the **Test and cutover** menu. Under **Cutover**, choose the** Launch cutover instances** option. The **Launch cutover instances for X** servers dialog appears. Choose **Launch** to begin the cutover. In the **Source servers** page, the **Migration lifecycle** column shows **Cutover in progress** and the **Next step** column shows **Finalize cutover**. The AWS Application Migration Service console indicates **Launch job started** when the cutover has started. Choose **View job details** on the dialog to view the specific job for the cutover launch in the** Launch history** tab. ## Successful cutover launch indicators You can tell that the cutover instance launch was started successfully through several indicators on the **Source servers** page. 1. The **Alerts** column displays **Launched**. 1. The **Migration lifecycle** column displays **Cutover in progress**. 1. The **Data replication status** displays **Healthy**. 1. The **Next step column** displays **Finalize cutover**. # Reverting a cutover Once you have launched your cutover instances, open the Amazon EC2 console and SSH or RDP into your cutover instances in order to ensure that they function correctly. Validate connectivity and perform acceptance tests for your application. **Note** You should turn on Termination Protection after you have completed your testing and before you are ready to finalize the cutover. Learn more about enabling termination protection in [this Amazon EC2 article](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/terminating-instances.html#Using_ChangingDisableAPITermination). If you encounter any issues and want to launch new cutover instances, you can revert the cutover. This reverts your source servers' **Migration lifecycle** status to **Ready for cutover**, indicating that these servers have not undergone cutover. During a revert, you also have the option to delete your Cutover instances for cost-saving purposes. To revert a cutover take the following steps: 1. Check the box to the left of every source server that has a launched cutover instance you want to revert. 1. Open the **Test and cutover** menu. 1. Under **Cutover**, choose **Revert to "ready for cutover"**. 1. This reverts your source servers' **Migration lifecycle** status to **Ready for cutover**, indicating that these servers have not undergone cutover. When the **Revert cutover for X servers** dialog appears, click **Revert**. # Finalizing a cutover If you are completely done with your migration and performed a successful cutover, you can finalize the cutover. This changes your source servers' **Migration lifecycle** status to **Cutover complete**, indicating that the cutover is complete and that the migration has been performed successfully. In addition, this stops data replication and causes all replicated data to be discarded. All AWS resources used for data replication are terminated. To finalize a cutover: 1. Check the box to the left of every source server that has a launched cutover instance you want to finalize. 1. Open the **Test and cutover** menu. 1. Under **Cutover**, choose **Finalize cutover**. 1. The **Finalize cutover for X servers** dialog appears. Choose **Finalize**. This changes your source servers' **Migration lifecycle** status to **Cutover complete**, indicating that the cutover is complete and that the migration has been performed successfully. In addition, this stops data replication and causes all replicated data to be discarded. All AWS resources used for data replication are terminated. The AWS Application Migration Service console indicates **Cutover finalized** when the cutover has completed successfully. The AWS Application Migration Service console automatically stops data replication for the source servers that were cutover in order to save resource costs. The selected source servers' **Migration lifecycle** column shows the **Cutover complete** status, the **Data replication** status column shows **Disconnected**, and the **Next step** column shows **Mark as archived**. The source servers have now been successfully migrated into AWS. 1. You can now archive your source servers that have launched cutover instances. Archiving removes these source servers from the main **Source servers** page, allowing you to focus on source servers that have not yet been cutover. You are still able to access the archived servers through filtering options. To archive your cutover source servers: 1. Check the box to the left of the of each source server for which the **Migration lifecycle** column states **Cutover complete**. 1. Open the **Actions** menu and choose **Mark as archived**. 1. When the **Archive X server** dialog appears, click **Archive**. 1. To see your archived servers, open the **Preferences** menu by choosing the gear button. Toggle the **Show only archived servers** option and click **Confirm**. You are now be able to see all of your archived servers. Untoggle the **Show only archived servers** option to show non-archived servers. # Review launch history Launch history The **Launch history** tab allows you to track and manage all of the operation performed in AWS Application Migration Service. You can access the Launch History by choose **Launch history** on the left-hand navigation menu. ## Overview The Launch History tab shows all of the operations (referred to as "Jobs") performed on your account. Each Job corresponds to a single operation (for example, Launch cutover instance, Launch test instance, etc.) Each Job is composed of one or more servers. The main Launch History view allows you to easily identify all key Job parameters, including: + ** Job ID** – The unique ID of the Job. + **Job type** – The type of Job (Launch or Terminate) + **Initiated by** – The command or action that initiated the job (for example, Launch cutover instances or Terminate launched instances) + **Status** – The status of the Job (Pending, Completed, or Started) + **Servers** – The number of servers that are included in the Job. + **Start time** – The time the job was started. + **Completed time** – The time the Job was completed (blank if the job was not completed). You can sort the launch history by any column by clicking the column header. (for example, sorting by **Job ID**). You can search for specific Jobs by any of the available fields within the **Find launch history by property or value** search bar. ## Job details To view a detailed breakdown of each individual job, choose the **Job ID** of the specific job. The **Job details** view is composed of 3 sections: **Topics** + [ ### Details ](#job-detials) + [ ### Job log ](#job-joblog) + [ ### Jobs – Source servers ](#job-sourceservers) ### Details The **Details** section shows the same information as the main Job log page, including the **Type, Status, Initiated by, Start time,** and **Completed time**. ### Job log The Job log section shows a detailed log of all of the operations performed during the job. Use this section to troubleshoot any potential issues and determine in which step of the launch process they occurred. Use the **Filter job log by property or value** search bar to filter the job log. You can filter by a variety of properties, including **Time, Event, Source server Id, Source server hostname, Conversion server instance IS, Test/cutover instance ID**, and **Error**. You can filter by multiple values at once. ### Jobs – Source servers The **Source servers** section shows a list of all source servers involved in the job and their status. You can use the **Filter source servers by property or value** search bar to filter by **Source server name** or **Status**. Choose the **Source server name** of any of source server from the list to open the Server Details view for that server. [Learn more about server details.](server-details.md)