Migrating Applications Seamlessly to AWS with Micro Focus PlateSpin Migrate

By Scott Kellish and Jim Huang, Partner Solutions Architects at AWS
By Jo De Baer, Senior Product Manager at Micro Focus

Along a customer’s digital transformation journey to the Amazon Web Services (AWS) Cloud, server migration is one of the most common application migration cases.

Imagine a web shop that runs on two web servers, two application servers, and one database server. It’s clear that when you migrate the web shop application to AWS, you need to migrate these five servers.

One key to migration success is mobility tooling for migration automation and process consistency, which is particularly critical when a customer has a large number of applications running on hundreds or thousands of servers.

In this post, we will describe common characteristics of server mobility technology and look at PlateSpin Migrate, a server portability solution built by Micro Focus, an AWS Partner Network (APN) Advanced Technology Partner with the AWS Data & Analytics Competency.

We will also provide a case study to show how server mobility tools like PlateSpin Migrate can help customers accelerate mass workload migration to AWS.

Together with AWS, Micro Focus created the PlateSpin Migrate on AWS Quick Start to allow fast and easy provisioning of PlateSpin Migrate on AWS.

Overview

PlateSpin Migrate is a powerful server portability solution that automates the process of migrating physical server machines or virtual host servers over the network to enterprise cloud platforms like AWS—all from a single point of control.

When migrating such servers, PlateSpin Migrate refers to these servers as “workloads.” A workload in this context is the aggregation of the software stack installed on the server: the operating system, applications, and middleware, plus any data that resides on the server volumes.

PlateSpin Migrate provides you with a mature and proven solution for migrating, testing, and rebalancing workloads across infrastructure boundaries.

Server Migration Technology

Server mobility technology enables workload migration with a number of technical characteristics.

Here, we start by listing several common characteristics to help readers better understand server migration tools, and help guide in selecting the right migration tool according to specific application migration requirements. In addition, we call out how PlateSpin Migrate implements the functionality.

Tool Type

Migration tools are of two different types with respect to where they orchestrate workload migration. Software-as-a-service (SaaS) tools are typically hosted in the cloud, while a server-based migration service runs either in the source or target migration environment. The former is a multi-tenant service managed by the tool vendor, whereas the latter is managed by tool users. PlateSpin Migrate is server-based.

Tool Deployment Method

Server-based migration tools require users to deploy and configure them in the migration environment. Deployment automation is essential for efficiency and quality of server-based migration tools. PlateSpin Migrate can be deployed and configured manually on-premises, or deployed and configured automatically in the AWS target environment via the PlateSpin Migrate on AWS Quick Start.

Source Environment Support

There can be physical as well as virtual servers for migration from the source environment. Server mobility tools are expected to support both types of servers. PlateSpin Migrate supports both physical and virtual servers for migrations.

Workload Operating System

Mobility tools are expected to migrate servers running Linux and Windows operating systems. Some tools support any OS platform, as long as it’s an x86 processor architecture. Some are capable of migrating legacy systems such as Solaris and Windows 2003. PlateSpin Migrate supports migration of servers running Linux or Windows operating systems.

OS License Handling

As part of server migration, customers may choose to “bring your own license” (BYOL) to AWS, or may want to leverage AWS-managed licenses. Thus, server mobility technology may provide some form of OS license migration schemes. PlateSpin Migrate supports both BYOL and AWS-managed licenses.

Target Landing Configuration

Prior to server migration, users may plan and set up a landing environment with an Amazon Virtual Private Cloud (Amazon VPC), subnets, Network ACLs, and Security Groups for target virtual machines (VMs). Server mobility technology has the capability of enabling users to browse and select a target landing environment. PlateSpin Migrate possesses this capability.

Data Protection

Migration data in transit and in the target environment should be protected. Mobility tools protect data in transit through native data encryption/decryption functions, or via secured transport such as a virtual private network (VPN). PlateSpin Migrate provides native encryption with 128-bit Advanced Encryption Standard (AES).

For migrated server data on Amazon EBS Volumes, mobility tools let users configure Amazon EBS encryption options before the migration starts. For migrated server data on Amazon EBS, PlateSpin Migrate allows users to select EBS encryption options before the migration starts.

Application Dependency Support

From the customer’s perspective, a unit of migration is an application that is implemented by a set of servers. Mobility tools help users to group and migrate servers that implement one application. PlateSpin Migrate provides workload tagging functionality for application grouping.

Mode of Operation: Agent-Based or Agent-Less

Agent-based migration technology utilizes a software component installed in each of the source servers to perform the migration, while agent-less migration tools don’t require this. PlateSpin Migrate utilizes a software component, the PlateSpin Migrate agent, which is installed in each of the source servers. The agent is automatically removed after the migration is completed.

Data Replication at Block or File Level

During server migration, data is replicated from the source server to the target server at storage block level or application file level. Customers should select a server mobility tool that supports either or both of the replication methods based on their migration needs. PlateSpin Migrate supports both. Block-based replications are faster, but file-based replications allow additional configuration options (e.g. volume resizing).

Service Impact

Service downtime is an important metric often considered for migration cutover. The cutover operation is typically comprised of a final incremental data replication, followed by (re)configuration of the target VM, and boot up of the target VM. Migrations performed with PlateSpin Migrate have zero service downtime during replication phases, and near-zero service downtime during final cutover.

Migration Testing

Prior to migration cutover, customers must validate the applications running on the migrated server instances or staging servers with migrated server content. The cutover takes place only after the validation test passes. It’s essential that mobility tools support migration validation testing and are able to rollback an attempted migration if the validations are unsuccessful.

PlateSpin Migrate provides flexible and sandboxed testing capabilities. When using PlateSpin Migrate, there is no limit on the amount of testing or on how long a test can run, prior to cutover.

Cost Optimization

Migration tools should be cost-conscious with respect to their resource consumption. PlateSpin Migrate only boots the target workload in the cloud during replication and test cutover phases. This provides cost optimization with respect to resource consumption, compared to other solutions that require the target workload to be running during the whole migration process.

PlateSpin Migrate Operational Architecture

PlateSpin Migrate uses the following components to instrument a server workload migration:

PlateSpin Migrate Server: The server component works as an orchestrator telling the other components what to do. The replication traffic does not flow over the PlateSpin Migrate server, but is sent directly from the source workload to the target workload.
.
PlateSpin Migrate Agent: The agent is installed on the source workload and is responsible for registering that source workload with the PlateSpin Migrate server, and later for sending the replication traffic from the source workload to the target workload.
.
PlateSpin Replication Environment (PRE): This is a staging VM that is launched during the replication phases that has one or more Amazon EBS Volumes attached corresponding to each volume in the target workload. The PRE VM receives the replication traffic directly from the Migrate agent on the source workload and places the received blocks or files on the target disks that are attached to it.
.
The PRE does not require any manual management by the end user to make it available in AWS.
.
Target workload: This is created automatically by PlateSpin Migrate, and is automatically booted from the PRE at every replication phase. During test cutover or final cutover, the PRE is automatically removed, so that the target workload runs from its own disks, rather than being booted from the PRE.

Available as a separate product, PlateSpin Transformation Manager can be used in tandem with PlateSpin Migrate to streamline the execution of very large migration projects.

Figure 1 – PlateSpin Migrate operational architecture.

PlateSpin Migrate Communication Port Requirements

Migration of workloads using PlateSpin Migrate involves two distinct phases:

Discovery phase where PlateSpin Migrate discovers and inventories supported source workloads.
Replication phase where you execute and monitor the migration of a discovered source workload by performing a series of replications.

During the discovery phase, PlateSpin Migrate has the following port requirements:

Without installation of the PlateSpin Migrate agent, the PlateSpin Migrate server needs to be able to connect to the source workload on ports 137, 139 and 445 (TCP).
.
When these ports are not accessible, the PlateSpin Migrate agent must be manually installed on the source workload and connect to the PlateSpin Migrate server on port HTTPS (TCP/443) to register the workload. For cloud migrations without a VPN, source workload registration using the PlateSpin Migrate agent is the only viable option.

For the replication phase, the following port requirements must be fulfilled:

PlateSpin Migrate server must be able to communicate with the AWS API endpoint on port HTTPS (TCP/443).
.
During replications:
- Both the source workload and target workload must be able to connect to the PlateSpin Migrate server on port HTTPS (TCP/443).
- PlateSpin Migrate server must be able to connect to the target workload on port 22 (TCP), while this workload is booted from the PRE helper VM.
- The source workload must be able to connect to the target workload on port 3725 (TCP), while this target workload is booted from the PRE helper VM.
  .
During testing cycles:
- The target workload must be able to connect to the PlateSpin Migrate server on port HTTPS (TCP/443).
  .
At cutover:
- Both the source workload and target workload must be able to connect to the PlateSpin Migrate server on port HTTPS (TCP/443).

Figure 2 – PlateSpin Migrate port requirements during replication.

PlateSpin Migrate on AWS Quick Start

To enable users to quickly and easily get started with migrating workloads to the AWS Cloud, Micro Focus together with AWS created the PlateSpin Migrate Quick Start.

AWS Quick Starts are built by AWS solutions architects and APN Partners to help customers deploy popular technologies on AWS, based on AWS best practices for security and high availability.

These accelerators reduce hundreds of manual procedures into just a few steps, so you can build your production environment quickly and start using it immediately.

Each Quick Start includes AWS CloudFormation templates that automate the deployment and a guide that discusses the architecture and provides step-by-step deployment instructions.

You can find the PlateSpin Migrate Quick Start under the Migration use case on the AWS Quick Start home page. You can deploy it into a new VPC or existing VPC, and the latter option assumes you have an existing (pre-created) VPC with existing subnets. We’ll use this option to illustrate this post.

Figure 3 below depicts the infrastructure deployed once the launched Quick Start has successfully completed. The example shown is for the use-case where there is no site-site VPN connection, with the PlateSpin Migrate server deployed into a public-facing subnet and assigned an AWS Elastic IP address.

Initially, only the PlateSpin Migrate server is deployed as it is responsible for managing the target workload instances.

Figure 3 – Micro Focus PlateSpin Migrate on AWS Quick Start.

The PlateSpin Migrate Quick Start includes a comprehensive reference guide which covers the deployed architecture as well as step-by-step deployment instructions and best practices for using PlateSpin Migrate on AWS.

When configuring the Quick Start, you’ll have to answer a couple of easy questions: What VPC do you want to deploy the server into? What subnet? What key pair do you want to link to your server? What user name and password do you want to use for the PlateSpin Migrate server admin account?

While we’ve provided sensible default values where appropriate, some of the other configuration options are more advanced and deserve some more explanation:

Replication access CIDR: The IP address range defined by this CIDR determines which source workloads are allowed to be replicated by this PlateSpin Migrate server. Set this to 0.0.0.0/0 to allow the server to migrate any source workload.
.
Management access CIDR: The IP address range defined by this CIDR determines which systems are allowed to administer the PlateSpin Migrate server and migrated workloads in production and test. Set this to 0.0.0.0/0 to allow administration from any system.
.
Target workloads interconnect CIDR: Sometimes migrated workloads need to interact with other servers so the application they host will run properly. The IP address range defined by this CIDR determines which servers are allowed to communicate with migrated workloads in test and production, on any port. Set this to 0.0.0.0/0 to allow communication with any server.

Figure 4 – After about 15 minutes you have a fully provisioned PlateSpin Migrate server.

With just a couple more clicks you can kick off the Quick Start, and after about 15 minutes you’ll have a fully provisioned PlateSpin Migrate server that is ready for use.

You can retrieve its public IP address via the instances overview of the region where it’s deployed. Once you know the public IP address, simply open a browser connection to your new server like this:

https://<the_public_IP_address_of_your_PlateSpin_Migrate_server>/migrate

Note that while the port requirements are the same, PlateSpin supports migrations with and without a VPN connection, and that provisioning the PlateSpin Migrate server with the Quick Start automatically configures Security Groups with the correct ports opened in both scenarios.

When you plan to have a site-site VPN connection, as depicted in Figure 5, either over the internet or with AWS Direct Connect, setting the Quick Start parameter “Assign persistent public IP address” to false will result in the PlateSpin Migrate server being deployed in a private subnet with no public-facing Elastic IP address assigned.

You would use this same configuration without a VPN if you were migrating workloads from one Amazon VPC to another.

Figure 5 – Automated migration to AWS over a VPN.

When you don’t have a site-site VPN connection, PlateSpin supports connectivity directly over the internet, as depicted in Figure 6.

When you set the Quick Start parameter “Assign persistent public IP address” to true, the PlateSpin Migrate server will be deployed into a public subnet and individual Elastic IPs will be assigned to the PlateSpin Migrate server and the target VMs it creates when executing migration jobs.

Figure 6 – Automated migration to AWS over the internet.

PlateSpin Migrate Operations

After provisioning your PlateSpin Migrate server with the AWS Quick Start, the next step is to license your server with an activation code. You can generate a trial activation code using the Free Trial button on the PlateSpin Migrate product website, which you then apply to your server in combination with the email address of your MicroFocus.com account.

A trial activation code will allow you to run five replications, which you can use to migrate as many as three workloads over 30 days.

Figure 7 – License your PlateSpin Migrate server.

Once your server is licensed, running a migration is easy. Figure 8 depicts the overall migration workflow.

Figure 8 – PlateSpin Migrate migration operation workflow.

After adding one or more migration targets, multiple source workloads can be added (discovered) and then configured for migration. Once a source workload migration is fully configured, the migration needs to be prepared. Preparation makes sure all components are correctly installed and functional. Once prepared, the migration process can be started at any point in time.

The first replication will be a full replication, copying all blocks or files from the source workload to the target workload. After the first full replication is done, the workload will be in a “Replicated” state.

At this point, if automated incremental replications were enabled during the migration configuration (recommended), PlateSpin will automatically run nightly incremental replications to keep the target workload in sync with the source workload. By default, these incremental replications run at night.

During the working day, a test cutover can be started at any point in time. With PlateSpin Migrate, there is no limit to how often or how long you can test. When the test is ended, PlateSpin automatically cleans up any testing resources that were provisioned, and will resume the nightly incremental replications until the day when the final cutover is initiated by the user.

Let’s take a look at what this process looks like in practice. As said, after adding one or more target environments, the first step is to register source workloads to be migrated. For migrations to the AWS Cloud, this is done by downloading the PlateSpin Migrate agent from the PlateSpin Migrate server web interface and installing it on each source workload.

Once source workloads are registered and at least one target AWS Region is added, you can start your migration configurations. Select a first source workload to be configured, and click Configure Migration.

Figure 9 – Select a source workload and click Configure Migration.

Configure your migration as desired using the various configuration options that PlateSpin Migrate offers (enabling automated nightly incremental replications is recommended), and then click Save & Prepare at the bottom of the migration configuration screen.

On the next screen, click Execute to kick off the migration preparation process. When the preparation is done, click Run Migration and then Execute to start the first full replication.

Figure 10 – When you have configured your migration, click Save & Prepare.

When the first full replication is completed, the workload will be in the “Replicated” state, and the buttons at the bottom of the screen will indicate the rest of the workflow.

Note that when automated nightly incremental replications are enabled, PlateSpin Migrate will keep the source workload and the target workload in sync every night by replicating the delta changes that happened since the last replication. Alternatively, an incremental replication can be launched manually.

By clicking the button Test Cutover, a test pass can be performed. PlateSpin Migrate will spin up the target workload in the cloud so that business and application teams can verify the application. When all testing is satisfactory, the workload can be cut over in production via the button Run Cutover.

Figure 11 – The buttons at the bottom of the screen indicate the workflow.

Customer Case Study

Atos is an APN Advanced Consulting Partner focused on digital transformation. Leveraging PlateSpin, Atos seamlessly migrated a multi-national electronics manufacturer to AWS.

Like many enterprises, their client was interested in a cloud environment to reduce operational costs, create a higher availability platform, improve security, and centralize IT management.

After a thorough analysis of the existing environment and the available options, Atos recommended an AWS cloud approach.

To migrate the data center servers to AWS, Atos chose PlateSpin from Micro Focus. Key results included:

Reduction of operational costs, in-line with client expectations.
Improved key performance indicators (KPIs) related to uptime, ease of maintenance, and system administration simplification.
Migrations executed 50 percent faster than when using alternative migration solutions.
Total elimination of manual effort while executing the individual server migrations.
Downtime consistently kept under one hour per application for 95 percent of the migrations.

Conclusion

Built by Micro Focus, PlateSpin Migrate is a proven and powerful server portability solution that automates the process of migrating physical server machines or virtual host servers over the network to enterprise cloud platforms like AWS.

The new PlateSpin Migrate on AWS Quick Start allows you to provision a cloud-based PlateSpin Migrate server with just a couple of clicks and automatically deploy all the resources that are required for your AWS migrations to run successfully.

The PlateSpin “lift-and-shift” approach migrates applications by migrating the servers that applications run on. When using the AWS Quick Start, you can start migrating servers to AWS within minutes.

Micro Focus – APN Partner Spotlight

Micro Focus is an APN Advanced Technology Partner. They enable customers to utilize new technology solutions while maximizing the value of their investments in critical IT infrastructure and business applications.

Contact Micro Focus | Solution Overview

*Already worked with Micro Focus? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.

AWS Partner Network (APN) Blog