Migrating to AWS – Part 2

Welcome to this second post in our series on Migrating to AWS. This blog post series will continue from Part 1 and cover a number of areas you should look out for when migrating to AWS, and provide methods of working to ensure you can successfully move an existing on-premise or other provider-hosted workloads to AWS with a minimal amount of issues.

Overview

As a reminder, these posts will cover a number of topics, split into 3 parts. Each part is split up as follows:

Part 1:

• Why Migrate to AWS?
• On-Premise Constraints
• AWS Tools to Help with Migration
• Methods of Migration (The 6 Rs or is it 7?)
• Document Everything

Part 2 (This Document):

• Phases of Migration
• Prepare / Discovery Phase
• AWS Account Setup
• CloudEndure
• Things to watch out for when using CloudEndure
• Application Migration Service (AWS MGN)

Part 3:

• Database Migration Service (DMS)
• Moving Complex Data
• Migrating – What to Do and When
• After Migration

Phases of Migration

• Prepare / Discovery

One of the most important phases of migration is actually figuring out everything you need to migrate. Often with platforms that have been built up over years, people have moved on, processes have been running uninterrupted for a while and things might not be documented. It’s important to know everything you need to migrate.

• Plan

Once you know what you are migrating you then need to decide how and what you are migrating. This comes back to the 6 R’s, and you need to decide for each aspect of your platform what you are going to do.

• Migrate

Once you have a plan in place, it is time to execute that plan. This can be all at once, or more likely in stages, where you have pieces of your platform working on-premise, with others on the cloud.

• Operate & Optimise

Once you have migrated, you then need to settle into operating your new platform on cloud and figuring out any remaining issues. After having run the new platform in production, you can figure out where you can improve on your new architecture and further optimise.

Prepare / Discovery Phase

The prepare, (or discovery phase) is arguably the most important phase in your migration. This is where you need to figure out everything you need to migrate.

With typical migrations, a lot of what’s been built on-premise or on another cloud provider has been built up over years, so you face specific challenges.

• Code written by team members who have left (potentially using languages or software you don’t use elsewhere)
• Code written for one-off purposes that is still required
• Light or non-existent documentation
• Processes (such as cronjobs) running on machines wherever they can fit
• Customer-specific code
• Older hardware and software that’s no longer supported, but is still in use because it’s in the contract
• Software or Code that interacts with outside providers or even internally on specific ports or requires specific software to be installed for it to run
• Fixed Hardware or fixed IP addresses (including whitelisting at third parties)

AWS Account Setup

Prior to your migration, you should set up your AWS Account Structure in the way it’s going to be used. You don’t want to get to migration only to discover you still need to set up and secure the account(s).

Some general advice on account structure:

• Use multiple accounts in an organisational structure, with centralised billing
• Use separate dev / test or stage / prod accounts
• Separate workloads where you can (Not as simple in a lift-and-shift) and have dev/test/prod for each
• Use cross-account roles for access, rather than separate IAM users for each account
• If you have time, set up a centralised logging and a centralised security account
• Use least privilege access for users, only give your users the access they need. This might be more during migration, then locked down once the migration has been completed

CloudEndure

CloudEndure is designed as both a migration application and a backup application for on-premise hardware. An agent is installed on the server to be migrated/backed up, which then communicates with a server in AWS via a replication server, creating a block-level copy of the drives. This replication can be continuous so you have a copy of your server in AWS.

The server in AWS can then be cut over to become a production instance, severing the replication connection and providing you with a production-ready version of the server in AWS.

Things to watch out for when using CloudEndure

CloudEndure has some setup requirements and some potential gotchas that can catch you out during migration.

• Use of Direct Connect or at least a VPN connection to AWS is recommended, both for speed and security purposes.
• Get ports 443 and 1500 opened early. Port 443 is used to communicate with the CloudEndure platform and 1500 to communicate with the replication servers.
• Multiple Network Interfaces aren’t supported. The Enhanced Networking Adapter drivers can help with networking issues when installed on the source server.
• CloudEndure does block-level copying, so for SANs, as long as they are represented as block devices, they should work. NFS shares should have the CloudEndure agent installed on the NFS server where possible.
• Windows Machines can only have up to 2TB as the root drive, even where the source machine supports more. GPT (GUID Partition Table) type disks that are dynamic aren’t supported for boot volumes. 
• Check your UEFI boot settings and enable on CloudEndure where required.
• The default disk type for replication servers is Provisioned IOPS, but this can be very expensive, be sure to change to General Purpose SSDs (GP2) in the replication settings.
• If your on-premise machine has a Virtual Machine running on it, this will need to be removed first, including any HyperV executables before CloudEndure will work, as it will cause the target machine to fail to boot.
• Any Hard-Coded IP Addresses in code or config will need to be removed or updated.

Application Migration Service (AWS MGN)

The Application Migration service is AWS’s integrated version of CloudEndure. This version is directly integrated with the AWS Console rather than having its own interface.

At the moment, both services are running simultaneously. The AWS MGN service has some limitations on regions and operating systems that CloudEndure still supports.

Examples of CloudEndure Supported O/Ss not supported by AWS MGN include:

• 32-bit Linux
• Debian 8
• RHEL 5.0
• Centos 5.0
• Windows Server 2003 (32/64 bit, R2 32/64 bit)
• Windows Server 2008 32 bit
• Microsoft Windows Server 2008 64 bit (R2 64 bit is supported by AWS MGN if patched)
• Windows XP, 7, 8, 10, Vista

We hope you’ve found some useful info here and we’ll continue with more tips in Part 3.