Skip to main content
BlogCloud

Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1

Overview

We understand every customer and organisation is unique in its own way. The decision an organisation takes to start their cloud adoption and modernisation journey of their environment to AWS is never an easy one and typically a very time consuming one. It involves many factors that need to be considered including resources, cost of change, TCO, ROI, application treatment, competing priorities, culture change, key stakeholder and C suite buy-in, training, upskilling as well as a solid understanding of the tangible and intangible benefits before proceeding. More often organisations engage CMD Solutions to help them build this AWS migration business case to create that compelling fit-for-purpose plan and strategy for adopting modern technologies and cloud at scale. 

Once that decision is finally made there is usually a push to get into AWS as quickly as possible. This can usually lead to an unplanned and inadequate solution, as there is a big difference between migrating to AWS quickly and migrating to AWS quickly with scalability, reliability, automation, optimisation and security in mind which results in little to no downtime and a well architected solution.

Migrations between one server and multiple servers (migrations at scale) also require a very different approach especially if you want to implement all the above capabilities. To perform large scale migrations and modernisation require the right tooling, planning and execution…another incredibly valuable topic is experience, with CMD Solutions having performed countless migrations over the years, we have refined this process.

In this two part series I will be taking you through a typical “lift-and-shift” (rehost) process of a Windows Server environment, although CMD Solutions will always look to modernise (replatform/refactor) the move to AWS by leveraging AWS native solutions such as RDS, Autoscaling Groups, Serverless, etc where applicable…but there is often a need to get into the cloud rapidly or if legacy applications need to be migrated.

Part 1 will be focusing on pre-migration tasks, setting up the tooling used for the migration and getting your on-premise servers in a state to be able to test and migrate.

Part 2 will take you through the actual migration testing, final cutover into AWS and getting your servers into a Terraform managed state, while at the same time modernising the environment using IaC and AWS services.

Migration Overview

We’ll be walking through a scenario of migrating a workload from an ‘on-premise’ Microsoft Windows environment into AWS. The workload is a simple 3-tier application composed of multiple frontend servers, a database server and a load balancer. While this is your typical frontend-backend solution there are many more factors to consider such as backups, file systems, proxy, etc. We won’t be going into this level of detail for the purpose of this blog but these should be assessed in the cloud adoption and modernisation process. Lastly we’ll also be codifying all migrated resources into IaC with Terraform, modernising the solution for high-availability and improving the overall cloud security posture.

Below is an example diagram of the on-premise solution that we’ll be migrating to AWS.

This is a simplified example hosted in a data centre environment. A solution similar to this usually colocates all servers on the same VMware host, which means there is little to no redundancy and often a very flat network structure.

diagram of the on-premise solution that we’ll be migrating to AWS

Below is what the solution will look like when migrated to AWS. The compute and database instances will be situated across multiple AZs (Availability Zones) for high availability and the individual server tiers will be deployed in distinct subnets with segregated levels of access:

  • Public – ALBs and Bastion Hosts
  • Private – FrontEnd/Application servers (web servers)
  • Secure – Database Servers

With the addition of the NACLs, routes and security groups that we’ll configure specifically for the different servers, we are applying a defence in depth environment with security at all layers.

For the purpose of this blog, I have built the “on-premise” servers (domain joined – cmdblog.local) in Availability Zone A (AZ-A), and will be using AZ-B and AZ-C as the AWS environment.

“On-Premise” servers in AZ-A.

Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 2
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 3

While this blog will walk through the technical solution of the migration, it needs to be understood that for a successful migration and modernisation to occur there needs to be a significant amount of pre-migration work.

This includes:

  • Application Discovery and Dependency Mapping
    • This can be done using a tool such as Cloudamize
  • Deep-Dive application workshops
    • This should include all application SMEs, stakeholders and technical experts
    • Depending on the size and complexity of the application this may require several workshops
  • High Level Design documentation
    • Detailed migration document explaining in detail the current and future state of the application environment, migration process, timelines and network design.
    • This will need to be reviewed by all application SMEs and stakeholders, once approved migration can then move forward.

The first step is getting all the tools and solutions set up to manage the migration of servers from on-prem to AWS. This will include the following:

  • AWS Application Migration Service (MGN)
  • AWS Migration Factory

AWS Application Migration Service (MGN)

The Application Migration Service (MGN) must be initialised upon first use from within the AWS Application Migration Service console.

You will need AWS credentials to use AWS MGN. Create an AWS IAM User and assign the proper permission policy to the user. Obtain the Access Key ID and Secret Access Key, which you would need to enter during the AWS replication agent installation on the source servers.

Prerequisites

Create IAM User (e.g. MGNser) with the following policy, AWSApplicationMigrationAgentPolicy

Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 4

Configure the Replication Settings in MGN

Replication Settings determine how data will be replicated from your source servers to AWS. Your Replication Settings are governed by the Replication Settings template, which you must configure before adding your source servers to Application Migration Service.

Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 5

AWS Migration Factory

Overview

AWS Migration Factory is a solution that AWS introduced a couple years ago to work in partnership with CloudEndure to assist with migration at scale and is now fully integrated with AWS MGN.

The solution is entirely serverless and through API calls to AWS MGN executes tasks through, it also has a web console that is used to manage migration waves and servers.

Note: The Execution Server needs to be created and installed separately.

Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 6

The Migration Factory solution is built using a CloudFormation stackset (Stackset 1) and as best practice it should be deployed in a Shared Services Account (Management account) that has access to all other AWS accounts. This is not compulsory, but recommended to accelerate the process. AWS CloudFormation

Prerequisites

The Migration Factory uses IAM Roles and Policies to access any other AWS accounts that need servers migrated to them. In order to configure these roles, another CloudFormation stackset (Stackset 2) needs to be deployed in each account.

There are multiple steps that need to be followed to fully configure the Migration Factory for migrations.

  • Deploy Migration Factory CloudFormation stackset (Stackset 1) into a Shared Services account.
  • Deploy Cloudformation ‘Target Account’ stack (Stackset 2) into all AWS accounts that servers will be  migrated to.
  • Build and configure the Execution Server
    • Download and Install Python 3 and install necessary packages: boto3, requests, paramiko.
    • Attach the Execution IAM Role that was created during the Migration Factory deployment to the server.
    • Add the following tag (Key: role; Value: mf_migration).
  • Configure the Migration Factory (Account IDs, etc)
    • Update the “aws_accountid” section (Administration > Attributes > Application > AWS Account ID) with all the accounts that servers will be migrated into.
  • Configure Migration Factory Users and Groups (Amazon Cognito).
  • Migration Factory is now configured.

All these steps are explained in detail in the Cloud Migration Factory on AWS Implementation Guide

Servers can now be populated into the Migration Factory and the migration process begins.

Onprem Server Data and Pre-Checks

To start the migration process, download the server-list.csv file from the GitHub repository. The server-list.csv file is an example AWS MGN Service migration intake form to import the attributes for the in-scope source servers.

This information would have been collected during application discovery workshops and migration planning.

Completed CSV file ready for import:

wave_id,app_name,aws_region,aws_accountid,server_name,server_os_family,server_os_version,server_fqdn,server_tier,server_environment,subnet_IDs,securitygroup_IDs,subnet_IDs_test,securitygroup_IDs_test,instanceType,tenancy

1,blog-demo1,ap-southeast-2,710820815220,onprem-server-web-01,linux,amazon linux 2,onprem-server-web-01.local,web,prod,subnet-0dec1986738f18987,sg-09b9aad07d6c802a7,subnet-0dec1986738f18987,sg-09b9aad07d6c802a7,t3.large,Shared

1,blog-demo1,ap-southeast-2,710820815220,onprem-server-web-02,linux,amazon linux 2,onprem-server-web-01.local,web,prod,subnet-0191dc06e7dcb0ca9,sg-09b9aad07d6c802a7,subnet-0191dc06e7dcb0ca9,sg-09b9aad07d6c802a7,t3.large,Shared

1,blog-demo1,ap-southeast-2,710820815220,onprem-server-web-03,linux,amazon linux 2,onprem-server-web-01.local,web,prod,subnet-0dec1986738f18987,sg-09b9aad07d6c802a7,subnet-0dec1986738f18987,sg-09b9aad07d6c802a7,t3.large,Shared

1,blog-demo1,ap-southeast-2,710820815220,onprem-server-db,linux,amazon linux 2,onprem-server-db.local,db,prod,subnet-0c4c10237e883d259,sg-09b9aad07d6c802a7,subnet-0c4c10237e883d259,sg-09b9aad07d6c802a7,t3.large,Shared

Import the group of servers into the Migration Factory using the Migration Factory Console.

Under Migration Management, select Import and choose Select file. Select the intake form you completed previously and choose Next.

Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 7

Confirm that that servers have been imported into the Migration Factory:

Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 8

Add Credentials into Migration Factory

Any credentials that will be required throughout the migration process, whether that is for the source servers or new credentials that you want set on the servers, need to be configured in “Credential Manager” in the Migration Factory.

  • Choose Add from the Credential Manager Secrets list.
  • Select the Secret Type to add.
  • Enter a Secret Name. This will be the same name that will be displayed inside AWS Secrets Manager

for the secret name.

  • Enter a Secret Description. This will be the same description that will be displayed inside AWS Secrets

Manager for the secret description.

  • Enter the credential information for the secret type.
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 9

Prerequisites for Source Server

A precheck of the source servers that need to be migrated can be done to make sure that they are ready for MGN. This is to verify the necessary prerequisites such as TCP 1500, TCP, 443, root volume free space, .Net framework version, and other parameters.

Note: Before you can conduct the check, the MGN agent must be installed manually on at least one source server in order to create a replication server in the AWS account.

  • On the Migration Factory console, select Jobs, select Actions, and then Run Automation.
  • Enter Job Name, select “0-Check MGN Prerequisites” script and your automation server to run the script.
  • Select Windows Secrets. Enter MGN replication server IP, choose the wave you want to run automation on and choose Submit Automation Job.
  • You will be redirected to the Jobs list page, the job status should be RUNNING.
  • The script will also update the solution’s migration status in the Migration Factory web interface.
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 10
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 11
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 12

Agent Installation

If this passes, then the servers are ready for the MGN agent to be installed and replication to begin.

  • On the Migration Factory console, select Jobs, select Actions, and then Run Automation.
  • Enter Job Name, select “1-Install MGN Agents” script and your automation server to run the script.
  • Select Windows Secrets. Choose the wave you want to run automation, and choose Submit Automation Job.
  • You will be redirected to the Jobs list page, the job status should be running.
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 14
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 15

You’ll see the progress of the agent installation and configuration in AWS MGN or in the Migration Factory.

Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 16
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 17
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 18

If replication fails to start, there could be multiple reasons but it is usually down to networking:

  • Network access (required ports and Internet connection not setup correctly)
  • Firewall

Local Accounts

Before a TEST MODE migration is performed, a temporary local admin account should be created on each domain-joined Windows server. This is required because Test instances have no connectivity to the domain and therefore aren’t able to use AD authentication. For standalone Windows machines this step is not required. To create local admin users, run the following command from the Execution Server.

  • On the Migration Factory console, select Jobs, and select Actions, and then Run Automation
  • Enter Job Name, select “2-Add local user” script and your automation server to run the script.
  • Select Windows Secrets. Select New Secret, choose the wave you want to run automation on and choose Submit Automation Job.
  • You will be redirected to the Jobs list page, the job status should be RUNNING.
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 19
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 20
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 21
Cloud Adoption – How to easily migrate and automate an on-premise workload – Part 1 - 22

Summary and Next Steps

As you can see in this first part, planning as well as getting the right processes and tooling for cloud adoption is critical to a successful migration.  In Part 2 I’ll be going through the test and cutover of the servers as well as adding IaC including modernisation using AWS services.

Close Menu