Tag Archives: CloudEndure

Field Notes: Choosing a Rehost Migration Tool – CloudEndure or AWS SMS

Post Syndicated from Ebrahim (EB) Khiyami original https://aws.amazon.com/blogs/architecture/field-notes-choosing-a-rehost-migration-tool-cloudendure-or-aws-sms/

Field Notes provides hands-on technical guidance from AWS Solutions Architects, consultants, and technical account managers, based on their experiences in the field solving real-world business problems for customers.

For customers that choose a rehost migration strategy (also known as lift-and-shift) for their large-scale workloads, the recommendation is to select a tool that will orchestrate, automate and schedule the migration with minimum downtime. CloudEndure Migration and AWS Server Migration Service (AWS SMS) are two services provided by AWS that both automate rehost migration, but customers often struggle determining which service is a best fit for their migration use case.

CloudEndure Migration is a block-level replication tool that simplifies the process of migrating applications from physical, virtual, and cloud-based servers to AWS.

CloudEndure Migration

Figure 1 – CloudEndure Migration

AWS Server Migration Service is an agentless migration service to migrate on-premises virtual machines to AWS using virtual appliance.

AWS Server Migration Service

Figure 2 – AWS Server Migration Service

In this post, I provide some considerations and patterns where it’s recommended based on your migration requirements to choose one tool over the other.

What type of infrastructure are you migrating?

First, consider your source infrastructure:

CloudEndure Migration supports any source infrastructure as long as it runs on x86 operating systems supported by Amazon Elastic Cloud Compute (EC2). This includes physical servers, P2V (virtual servers converted from physical), VMware, Hyper-V, and other cloud providers like Azure, GCP, IBM, or Oracle (see  Supported Operating Systems). Be aware of some limits that are specific to some the operating systems. For example, dynamic type Windows disks that have GPT partitions are not supported. For more information, see How do I determine if my disks are GPT or dynamic?

AWS SMS supports migrations of virtual machines from VMware, Hyper-V or Microsoft Azure. AWS SMS doesn’t currently support physical infrastructure or other public cloud provider except Microsoft Azure. For a full list of supported operating systems, see Operating Systems Supported by AWS SMS.

If your source environment includes bare metal servers, and you can install agents (more on agents in the next section), the recommendation is to use CloudEndure Migration. You can use a combination of CloudEndure Migration and AWS SMS in an environment that has a mix of physical and virtual servers, but this approach adds unnecessary complexity to your operation– you must maintain both as opposed to having a unified solution that works for all sources.

Do you require agent or agentless solution?

CloudEndure Migration requires that you install CloudEndure Agent individually on each server or virtual machine with root/admin access. CloudEndure Agent is a lightweight software (utilizes approximately 5% CPU and 250MB of RAM) and non-disruptive. CloudEndure Agent performs an initial block-level read for the content of the volumes attached to the server and replicates it to the replication server. After the initial sync is complete, the agent then captures only the writes and synchronizes any block-level modification to the replication server. For handshake, monitoring, and management purposes, the agent requires egress access on TCP port 443 with the CloudEndure User Console. For communicating with the replication server in your account in AWS, it requires egress access on TCP port 1500. For list of networking requirements, see Networking and Ports.

AWS SMS doesn’t require an agent on each VM. Instead, it uses the Server Migration Connector (SMS Connector), which is a pre-configured FreeBSD virtual machine that you install on your on-premises virtualization environment, on the hypervisor level, before the migration can start. The format of the SMS Connector varies based on your source environment (see Install the Server Migration Connector for types). The SMS Connector is responsible for taking snapshots, sending them to AWS SMS, and converting them to an Amazon Machine Image (AMI).

In some situations you can’t meet some of the agent requirements. For example, you may not be able to have admin access on source machines to install the agent, or maybe you just prefer an agentless solution that requires less administration tasks on the operating system level. In such cases, assuming you have the necessary access to the hypervisor (or Azure Portal), AWS SMS is a better fit.

How frequently do you require source environment to be replicated?

With CloudEndure Migration, once the agent is installed and activated, it begins initial replication, reading all of the data on source machines at the block level and replicating it to a staging environment in the customer’s individual account in their preferred target region on AWS. The initial replication can take anywhere from several minutes to several days, depending on the amount of data to be replicated and the bandwidth available between the source and target infrastructure. After the initial replication is complete, the source machines are continuously monitored to ensure constant synchronization, up to the last second. Any changes to source machines are continuously and asynchronously replicated into the “staging area” in the target infrastructure. The replication at this point enters a Continuous Data Replication (CDR) state.

The block-level replication can be performed on any type of disk as long as it’s presented to CloudEndure Migration as a block device. This includes physical disks, disks hosted on Storage Area Network (SAN), VMDK, VHD and iSCSI.

The continuous, asynchronous, block-level replication maintains the data on AWS up-to-date with sub-second latency, and that enables you to achieve a cutover time between 5-20 minutes, depending on the operating systems and network latency. When the replication reaches the CDR state, you can launch a target machine in Test mode. Once you complete all your testing and are ready to fully transition your machine to the target cloud, you can perform the Cutover mode action. This process is fully automated. The following image shows the steps CloudEndure Migration performs during the conversion. For more details, see Performing a Migration Cutover.

 

CloudEndure Target Machine Launch

CloudEndure Target Machine Launch

Figure 3 – CloudEndure Target Machine Launch

The block-level replication and CDR make CloudEndure Migration a better fit for use cases where you require near real-time replication (i.e., the data in the destination environment is replicated sub-seconds behind the source environment.)

AWS SMS replication is done by taking snapshots of source machines. After you configure the SMS Connector in the virtualized environment and you create the replication job, the replication job starts and performs the following steps:

  1. Take a snapshot for the source VM
  2. Export VM to VMDK/VHD file for vCenter/Hyper-V respectively
  3. Upload VMDK /VHD to the S3 bucket
  4. Clean the snapshot
  5. Convert VMDK/VHD file to EBS Snapshot using VM import/export
  6. Delete the VMDK/VHD file in the S3 bucket
  7. Create an AMI

These steps are fully automated and are repeated for each recurrence of the replication job. Since AWS SMS uses snapshot-based replication, the subsequent snapshot is taken incrementally and, unlike CloudEndure Migration, there is no need for a staging area to receive the replication data.

Currently, the minimum time between reach replication in SMS is 1-hour, and the maximum is 24-hours. Using this setup, you still can build the migrated environment in minutes, but the migrated environment is at least 1-hour behind the source environment. If your migration requirements tolerate the 1-hour window, then AWS SMS can be a good fit, otherwise you should use CloudEndure Migration.

Do you require migration to be managed entirely from AWS Console?

Currently, CloudEndure Migration is a SaaS offering that you administer in the CloudEndure Console outside of the AWS Management Console, so you need two separate accounts, an AWS account and a CloudEndure account.

CloudEndure Console

Figure 4 – CloudEndure Console

AWS SMS is a managed AWS service, so you operate it entirely from inside your AWS account without having to use an external portal or additional accounts.

If you have such a requirement to operate centrally from within AWS Console, currently, AWS SMS is the right choice.

What level of customization do you require after launching target environment?

In many cases, customers run discovery tools (like TSO Logic) to gather information about on-premises data centers. This information includes server utilizations, dependency mapping, or Total Cost of Ownership (TCO) estimate. Most discovery tools provide rightsizing for on-premises servers and recommend instance types and configurations when migrating these servers to Amazon EC2 on AWS. Both CloudEndure Migration and AWS SMS include these capabilities in different ways.

CloudEndure Migration uses Blueprint, which is a set of instructions on how to launch a target machine for a selected source machine. The Blueprint settings serve as the base settings for the creation of the Target machine. Using Blueprint, you can customize EC2 properties like: machine type, launch type, subnet, security group, private or public IP, disks type (standard, SSD or provisioned SSD) and others. CloudEndure Migration can also do the rightsizing by launching target machines that best match the current hardware (RAM, CPU, Cores) on source machine.

 

CloudEndure Blueprint Configurations

Figure 5 – CloudEndure Blueprint Configurations

In some cases, you may want to import the recommendations from a discovery tool without having to customize the blueprint manually. This is also supported by CloudEndure Migration using the mass blueprint setter script which takes the inventory and rightsizing configurations in csv format and imports them into the blueprint configurations using CloudEndure API. The configuration is then used to launch target machines. For more details, see CloudEndure API.

AWS SMS supports similar functionality when choosing Application Migration. Whereas server migration is accomplished by replicating a single server as an Amazon Machine Image (AMI), application migration replicates all of the servers in an application as AMIs and generates an AWS CloudFormation template to launch them in a coordinated fashion.

The following steps launch and migrate an application:

  1. Create a new application (i.e. SharePoint)
  2. Add servers to the application (i.e. database and application servers)
  3. Configure replication settings (i.e. license type)
  4. Configure launch settings: this defines how the application will be launched on EC2 instances. Some of the configurations you can specify: order of launch (launch database server first and then app server), instance type, VPC, subnet, security group, whether the application is publicly accessible or not and, optionally, you could add post launch scripts.

AWS SMS Target Instance Configurations

Figure 6 – AWS SMS Target Instance Configurations

From there, you start the replication and launch the application as per the configuration above. AWS SMS generates a CloudFormation template for the application settings that you can download, edit, and use for later launches. See also Migrating a SharePoint application using the AWS Server Migration Service on the AWS Compute Blog.

If you have a requirement to import your discovery and right-sizing data and use them to launch your target machines, then CloudEndure Migration is the right tool. If you have a requirement for generating a reusable CloudFormation template of migrated environment, then AWS SMS is the right tool.

Cost

You can use both CloudEndure Migration and AWS SMS at no charge. You are only charged for the resources each tool creates in your account to complete the migration.

Additional charges for each tool are as follows:

CloudEndure Migration uses a staging area to receive replication data. The staging area contains low-cost resources to keep your cost minimum. By default, CloudEndure Migration uses the t3.small EC2 instance type for replication server and EBS magnetic for its attached volumes as long as the volume is less than 500 GB in size. There is a one-to-one mapping between each EBS volume attached to the replication server, and a disk attached to a server in your source environment. You should also consider that depending on the number of disks you replicate from your source, you may need to have more than one replication server. The typical ratio of volumes to replication server is 15:1.

CloudEndure Migration also incurs charges for storing the snapshot it takes for each volume. There are 5-7 internal snapshots needed to replicate each disk. Frequency and exact number depend on various factors, such as change rate on the Source machine and network stability. Snapshots that are no longer needed, for example, after a source server has been migrated, are deleted automatically.

The AWS SMS is similar in incurring charges for storing snapshots it takes for every replication. The number of snapshots depends on frequency of the replication job (from 1 to 24 hours). To prevent additional charges, delete snapshot copies you no longer need. AWS SMS also replicates server volumes from your on-premises environment to Amazon S3 temporarily and purges them from Amazon S3 right after creating Amazon EBS snapshots, incurring a transient charge for S3.

Encryption

CloudEndure Migration supports encryption at rest and in transit. For encryption in transit, CloudEndure Migration uses Advanced Encryption Standard (AES-256) to encrypt replication traffic between agents in the source environment and the replication server. The traffic is passed using TCP port 1500. When the CloudEndure agent is installed on each source server, CloudEndure Migration generates a separate encryption key and passes it along to the designated replication using Transport Layer Security (TLS). The key is kept there in memory (confirm) for decryption.

For encryption at rest, CloudEndure Migration gives you the option to store your volumes encrypted in the staging area. You do that by checking Enable volume encryption in the project’s replication settings. From there, you choose either the default encryption key, or a custom KMS CMK key. Note that CloudEndure Migration doesn’t support OS-based disk encryption features such as BitLocker. These should be disabled before using any CloudEndure services.

CloudEndure Volume Encryption

Figure 7- CloudEndure Volume Encryption

AWS SMS creates an Amazon S3 bucket in the Region on your behalf, with server-side encryption enabled and a bucket policy to delete any items in the bucket after seven days. When you configure a replication job you have the option to enable AMI encryption. If you do so, AWS SMS encrypts the generated AMIs. Your default CMK is used unless you specify a non-default CMK. Replicated server volumes are encrypted in transit by Transport Layer Security TLS 1.2.

Disaster Recovery (DR)

In many cases, I work with customers who start their experience on AWS by moving or building a disaster recovery site on AWS. Sometime later, they realize the benefits of AWS and they decide to migrate their entire workload.

Although AWS SMS and CloudEndure Migration products are not designed for disaster recovery purposes, in this scenario, it is easier for customers to use CloudEndure Disaster Recovery for the DR project, and then leverage their familiarity with the product by using CloudEndure Migration for the migration portion. CloudEndure Disaster Recovery also supports region-to-region disaster recovery within AWS. To learn more, see CloudEndure Disaster Recovery.

Conclusion

Both CloudEndure Migration and AWS SMS are good options for a lift-and-shift migration. In this post, I reviewed a few use cases where one service is better fit over the other. For example, CloudEndure Migration is a better option when you migrate physical servers to AWS, when you want to deploy a block-level replication solution, or when you have near real-time replication requirements. In contrast, AWS SMS is a better option when you want to leverage an agentless solution, when you can tolerate one hour between replication jobs, or when you want a solution that’s managed from one place in the AWS Management Console.

You can get started here with CloudEndure Migration and AWS SMS. If you have comments about this blog post, please submit them in the comments section. I look forward to hearing from you.

Automated Disaster Recovery using CloudEndure

Post Syndicated from Ryan Jaeger original https://aws.amazon.com/blogs/architecture/automated-disaster-recovery-using-cloudendure/

There are any number of events that cause IT outages and impact business continuity. These could include the unexpected infrastructure or application outages caused by flooding, earthquakes, fires, hardware failures, or even malicious attacks. Cloud computing opens a new door to support disaster recovery strategies, with benefits such as elasticity, agility, speed to innovate, and cost savings—all which aid new disaster recovery solutions.

With AWS, organizations can acquire IT resources on-demand, and pay only for the resources they use. Automating disaster recovery (DR) has always been challenging. This blog post shows how you can use automation to allow the orchestration of recovery to eliminate manual processes. CloudEndure Disaster Recovery, an AWS Company, Amazon Route 53, and AWS Lambda are the building blocks to deliver a cost-effective automated DR solution. The example in this post demonstrates how you can recover a production web application with sub-second Recovery Point Objects (RPOs) and Recovery Time Objectives (RTOs) in minutes.

As part of a DR strategy, knowing RPOs and RTOs will determine what kind of solution architecture you need. The RPO represents the point in time of the last recoverable data point (for example, the “last backup”). Any disaster after that point would result in data loss.

The time from the outage to restoration is the RTO. Minimizing RTO and RPO is a cost tradeoff. Restoring from backups and recreating infrastructure after the event is the lowest cost but highest RTO. Conversely, the highest cost and lowest RTO is a solution running a duplicate auto-failover environment.

Solution Overview

CloudEndure is an automated IT resilience solution that lets you recover your environment from unexpected infrastructure or application outages, data corruption, ransomware, or other malicious attacks. It utilizes block-level Continuous Data Replication (CDP), which ensures that target machines are spun up in their most current state during a disaster or drill, so that you can achieve sub-second RPOs. In the event of a disaster, CloudEndure triggers a highly automated machine conversion process and a scalable orchestration engine that can spin up machines in the target AWS Region within minutes. This process enables you to achieve RTOs in minutes. The CloudEndure solution uses a software agent that installs on physical or virtual servers. It connects to a self-service, web-based use console, which then issues an API call to the selected AWS target Region to create a Staging Area in the customer’s AWS account designated to receive the source machine’s replicated data.

Architecture

In the above example, a webserver and database server have the CloudEndure Agent installed, and the disk volumes on each server replicated to a staging environment in the customer’s AWS account. The CloudEndure Replication Server receives the encrypted data replication traffic and writes to the appropriate corresponding EBS volumes. It’s also possible to configure data replication traffic to use VPN or AWS Direct Connect.

With this current setup, if an infrastructure or application outage occurs, a failover to AWS is executed by manually starting the process from the CloudEndure Console. When this happens, CloudEndure creates EC2 instances from the synchronized target EBS volumes. After the failover completes, additional manual steps are needed to change the website’s DNS entry to point to the IP address of the failed over webserver.

Could the CloudEndure failover and DNS update be automated? Yes.

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service with three main functions: domain registration, DNS routing, and health checking. A configured Route 53 health check monitors the endpoint of a webserver. If the health check fails over a specified period, an alarm is raised to execute an AWS Lambda function to start the CloudEndure failover process. In addition to health checks, Route 53 DNS Failover allows the DNS record for the webserver to be automatically update based on a healthy endpoint. Now the previously manual process of updating the DNS record to point to the restored web server is automated. You can also build Route 53 DNS Failover configurations to support decision trees to handle complex configurations.

To illustrate this, the following builds on the example by having a primary, secondary, and tertiary DNS Failover choice for the web application:

How Health Checks Work in Complex Amazon Route 53 Configurations

When the CloudEndure failover action executes, it takes several minutes until the target EC2 is launched and configured by CloudEndure. An S3 static web page can be returned to the end-user to improve communication while the failover is happening.

To support this example, Amazon Route 53 DNS failover decision tree can be configured to have a primary, secondary, and tertiary failover. The decision tree logic to support the scenario is the following:

  1. If the primary health check passes, return the primary webserver.
  2. Else, if the secondary health check passes, return the failover webserver.
  3. Else, return the S3 static site.

When the Route 53 health check fails when monitoring the primary endpoint for the webserver, a CloudWatch alarm is configured to ALARM after a set time. This CloudWatch alarm then executes a Lambda function that calls the CloudEndure API to begin the failover.

In the screenshot below, both health checks are reporting “Unhealthy” while the primary health check is in a state of ALARM. At the point, the DNS failover logic should be returning the path to the static S3 site, and the Lambda function executed to start the CloudEndure failover.

The following architecture illustrates the completed scenario:

Conclusion

Having a disaster recovery strategy is critical for business continuity. The benefits of AWS combined with CloudEndure Disaster Recovery creates a non-disruptive DR solution that provides minimal RTO and RPO while reducing total cost of ownership for customers. Leveraging CloudWatch Alarms combined with AWS Lambda for serverless computing are building blocks for a variety of automation scenarios.

 

 

Automating your lift-and-shift migration at no cost with CloudEndure Migration

Post Syndicated from Chris Munns original https://aws.amazon.com/blogs/compute/automating-your-lift-and-shift-migration-at-no-cost-with-cloudendure-migration/

This post is courtesy of Gonen Stein, Head of Product Strategy, CloudEndure 

Acquired by AWS in January 2019, CloudEndure offers a highly automated migration tool to simplify and expedite rehost (lift-and-shift) migrations. AWS recently announced that CloudEndure Migration is now available to all customers and partners at no charge.

Each free CloudEndure Migration license provides 90 days of use following agent installation. During this period, you can perform all migration steps: replicate your source machines, conduct tests, and perform a scheduled cutover to complete the migration.

Overview

In this post, I show you how to obtain free CloudEndure Migration licenses and how to use CloudEndure Migration to rehost a machine from an on-premises environment to AWS. Although I’ve chosen to focus on an on-premises-to-AWS use case, CloudEndure also supports migration from cloud-based environments. For those of you who are interested in advanced automation, I include information on how to further automate large-scale migration projects.

Understanding CloudEndure Migration

CloudEndure Migration works through an agent that you install on your source machines. No reboot is required, and there is no performance impact on your source environment. The CloudEndure Agent connects to the CloudEndure User Console, which issues an API call to your target AWS Region. The API call creates a Staging Area in your AWS account that is designated to receive replicated data.

CloudEndure Migration automated rehosting consists of three main steps :

  1. Installing the Agent: The CloudEndure Agent replicates entire machines to a Staging Area in your target.
  2. Configuration and testing: You configure your target machine settings and launch non-disruptive tests.
  3. Performing cutover: CloudEndure automatically converts machines to run natively in AWS.

The Staging Area comprises both lightweight Amazon EC2 instances that act as replication servers and staging Amazon EBS volumes. Each source disk maps to an identically sized EBS volume in the Staging Area. The replication servers receive data from the CloudEndure Agent running on the source machines and write this data onto staging EBS volumes. One replication server can handle multiple source machines replicating concurrently.

After all source disks copy to the Staging Area, the CloudEndure Agent continues to track and replicate any changes made to the source disks. Continuous replication occurs at the block level, enabling CloudEndure to replicate any application that runs on supported x86-based Windows or Linux operating systems via an installed agent.

When the target machines launch for testing or cutover, CloudEndure automatically converts the target machines so that they boot and run natively on AWS. This conversion includes injecting the appropriate AWS drivers, making appropriate bootloader changes, modifying network adapters, and activating operating systems using the AWS KMS. This machine conversion process generally takes less than a minute, irrespective of machine size, and runs on all launched machines in parallel.

CloudEndure Migration Architecture

CloudEndure Migration Architecture

Installing CloudEndure Agent

To install the Agent:

  1. Start your migration project by registering for a free CloudEndure Migration license. The registration process is quick–use your email address to create a username and password for the CloudEndure User Console. Use this console to create and manage your migration projects.

    After you log in to the CloudEndure User Console, you need an AWS access key ID and secret access key to connect your CloudEndure Migration project to your AWS account. To obtain these credentials, sign in to the AWS Management Console and create an IAM user.Enter your AWS credentials in the CloudEndure User Console.

  2. Configure and save your migration replication settings, including your migration project’s Migration Source, Migration Target, and Staging Area. For example, I selected the Migration Source: Other Infrastructure, because I am migrating on-premises machines. Also, I selected the Migration Target AWS Region: AWS US East (N. Virginia). The CloudEndure User Console also enables you to configure a variety of other settings after you select your source and target, such as subnet, security group, VPN or Direct Connect usage, and encryption.

    After you save your replication settings, CloudEndure prompts you to install the CloudEndure Agent on your source machines. In my example, the source machines consist of an application server, a web server, and a database server, and all three are running Debian GNU / Linux 9.

  3. Download the CloudEndure Agent Installer for Linux by running the following command:
    wget -O ./installer_linux.py https://console.cloudendure.com/installer_linux.py
  4. Run the Installer:
    sudo python ./installer_linux.py -t <INSTALLATION TOKEN> --no-prompt

    You can install the CloudEndure Agent locally on each machine. For large-scale migrations, use the unattended installation parameters with any standard deployment tool to remotely install the CloudEndure Agent on your machines.

    After the Agent installation completes, CloudEndure adds your source machines to the CloudEndure User Console. From there, your source machines undergo several initial replication steps. To obtain a detailed breakdown of these steps, in the CloudEndure User Console, choose Machines, and select a specific machine to open the Machine Details View page.

    details page

    Data replication consists of two stages: Initial Sync and Continuous Data Replication. During Initial Sync, CloudEndure copies all of the source disks’ existing content into EBS volumes in the Staging Area. After Initial Sync completes, Continuous Data Replication begins, tracking your source machines and replicating new data writes to the staging EBS volumes. Continuous Data Replication makes sure that your Staging Area always has the most up-to-date copy of your source machines.

  5. To track your source machines’ data replication progress, in the CloudEndure User Console, choose Machines, and see the Details view.
    When the Data Replication Progress status column reads Continuous Data Replication, and the Migration Lifecycle status column reads Ready for Testing, Initial Sync is complete. These statuses indicate that the machines are functioning correctly and are ready for testing and migration.

Configuration and testing

To test how your machine runs on AWS, you must configure the Target Machine Blueprint. This Blueprint is a set of configurations that define where and how the target machines are launched and provisioned, such as target subnet, security groups, instance type, volume type, and tags.

For large-scale migration projects, APIs can be used to configure the Blueprint for all of your machines within seconds.

I recommend performing a test at least two weeks before migrating your source machines, to give you enough time to identify potential problems and resolve them before you perform the actual cutover. For more information, see Migration Best Practices.

To launch machines in Test Mode:

  1. In the CloudEndure User Console, choose Machines.
  2. Select the Name box corresponding to each machine to test.
  3. Choose Launch Target Machines, Test Mode.Launch target test machines

After the target machines launch in Test Mode, the CloudEndure User Console reports those machines as Tested and records the date and time of the test.

Performing cutover

After you have completed testing, your machines continue to be in Continuous Data Replication mode until the scheduled cutover window.

When you are ready to perform a cutover:

  1. In the CloudEndure User Console, choose Machines.
  2. Select the Name box corresponding to each machine to migrate.
  3. Choose Launch Target Machines, Cutover Mode.
    To confirm that your target machines successfully launch, see the Launch Target Machines menu. As your data replicates, verify that the target machines are running correctly, make any necessary configuration adjustments, perform user acceptance testing (UAT) on your applications and databases, and redirect your users.
  4. After the cutover completes, remove the CloudEndure Agent from the source machines and the CloudEndure User Console.
  5. At this point, you can also decommission your source machines.

Conclusion

In this post, I showed how to rehost an on-premises workload to AWS using CloudEndure Migration. CloudEndure automatically converts your machines from any source infrastructure to AWS infrastructure. That means they can boot and run natively in AWS, and run as expected after migration to the cloud.

If you have further questions see CloudEndure Migration, or Registering to CloudEndure Migration.

Get started now with free CloudEndure Migration licenses.