Welcome to this series on Migrating to AWS. This blog post series will 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
These posts will cover a number of topics, split into 3 parts. Each part is split up as follows:
- 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
- Phases of Migration
- Prepare / Discovery Phase
- AWS Account Setup
- CloudEndure
- Things to watch out for when using CloudEndure
- Application Migration Service (AWS MGN)
- Database Migration Service (DMS)
- Moving Complex Data
- Migrating – What to Do and When
- After Migration
Why Migrate to AWS?
You may have already decided to move to AWS, but you may also just be at the start of your cloud migration journey and are looking into why you might want to move to a provider like AWS.
AWS has many benefits for companies and individuals thinking of hosting their applications on the cloud.
- Pay only for what you use. No more paying for servers you aren’t making the most of and move from a CAPEX model (Paying upfront for capacity) to an OPEX model (On-Going payment for usage)
- New technologies and methods of working, such as serverless
- Constantly evolving product lines. AWS releases new services and updates regularly (we do a weekly news update on new releases and find new use cases all the time)
- Support for products. AWS generally doesn’t stop supporting a service, they usually update to newer releases, but most services that have been launched since 2006 are still there
- No long-term contracts, you can stop using AWS whenever you decide to
- Hundreds of products and services for almost every use case
On-Premise Constraints
If you are currently with an on-premise data centre, or a hosting provider where you rent a virtual machine, you might be aware of some of the constraints in this operating model. Here, I’ll describe some of the constraints we’ve come across when delivering migrations.
- You are bound to a specific data centre, so if there are any issues in that particular data centre, such as a communication issue, you are stuck with either no ability to move or having to invoke a complicated and expensive Disaster Recovery Plan.
- Long-Term contract commitments for specific pieces of hardware. This can mean you are stuck with what you thought you needed when you signed the contract, so if your demand changes (such as increased/decreased traffic or wanting to launch a new feature that requires more resources) you are stuck with what you have unless you want to add more to your commitment.
- Not being able to adapt to change. The pandemic has left a lot of companies with much less business than before, and many are finding that their existing contracts covering sufficient resources for pre-pandemic aren’t suitable for what they need now.
- Outdated hardware. With contracts running for 18 months or more, the hardware purchased at the outset may no longer be good enough for your current needs.
- Lack of Control. Many on-premise and other hosting providers won’t allow you access to some of the services you may need. This is usually done to protect you from potential issues and protect other hosted customers, but occasionally it can cause headaches when trying to achieve a specific aim. (An example of this is opening specific ports).
AWS Tools to Help with Migration
AWS have a number of tools to use in your Migration that allow you to move your data and infrastructure over to AWS.
CloudEndure
We’ll cover this in more detail in a later section, but CloudEndure is a service owned by AWS that allows you to install an agent on your existing machine and do a block-level copy of the entire storage and provisions a new EC2 instance in AWS for the data to be copied to. This allows you to have an up to date copy of all of your data, ready to be switched over.
AWS Migration Hub
AWS Migration Hub is a service for tracking all of the different agents you have installed and listing all of the machines you are going to be migrating. It can list machines, applications installed on those machines and more, and provide target EC2 instances for your new machines.
AWS Application Discovery Service
The AWS Application Discovery Service is an agent you can install that will show you what’s installed on a particular machine, as well as everything that is currently running, allowing you to document what you need to migrate.
AWS Application Migration Service
The AWS Application Migration Service is the AWS console version of CloudEndure, with some updates to the interface and what it supports. There is a section in Part 2 covering this service.
AWS DataSync
The AWS DataSync service is a virtual machine you can install to attach to your Network Attached Storage and copy all of the Data over to a service such as EFS (Elastic File System).
AWS Server Migration Service
The AWS Server Migration Service allows you to use snapshot-based replication to migrate servers or virtual machines over to AWS, it also allows for an agentless snapshot process if you can’t install the agent for Application Migration Service.
AWS Database Migration Service
The AWS Database Migration Service allows you to replicate existing databases over to AWS RDS, and also to convert from one database type to another. There is a section in Part 3 covering this service.
Methods of Migration (The 6 Rs or is it 7?)
When migrating to AWS, an important factor in your decision making should be deciding exactly what you are going to migrate.
The 6 Rs are a common strategy tool for deciding what to do with each of the components you are migrating. AWS also lists a 7th strategy in some cases.
The 6 Rs are commonly:
- Retire
- Retain
- Rehost
- Replatform
- Repurchase
- Refactor
AWS also adds Relocate, though it’s specific to moving from VMWare to AWS VMWare Cloud, so it’s more of a specialisation of Replatform.
Each of these strategies is valid and most migrations end up with a combination of most of them for different aspects of the migration.
Retire & Retain
These 2 migration methods are of similar impact to your migration strategy. You can decide to retire an application or server, or retain it on-premise (for now) and not migrate it to AWS.
Rehost (or Lift-and-Shift)
This is likely to be your most common migration strategy, as it involves moving the application and its data to AWS with minimal changes.
Replatform (Lift and Reshape, or sometimes called Lift-tinker-and-shift)
This strategy involves moving to AWS but changing your application to make it more cloud aligned or other changes that don’t involve changing the core architecture. You might for example move a database to RDS, or move your application’s web serving software to Apache Tomcat.
Repurchase
This strategy involves replacing part of your application with a new service. As an example, you might be using SMTP locally on your machine to send emails, but this may not be sustainable or scalable, so you could decide to move this part of your application to another service such as AWS Simple Email Service.
Refactor
This strategy is likely the most appealing from a technical point of view, but it’s also the most time-consuming. It involves changing your application to take advantage of Cloud Services. You may for example decide to go Serverless and split up your application into lambda functions.Â
Document Everything
In the next entry in this series, we will dive into the phases of migration and how to approach each step, but to close out this section I want to give one of probably the most important tips in this series.
And that is to Document Everything.Â
I can’t stress enough the importance of good, detailed documentation, especially in the discovery and planning phases, as extra time spent here saves multiple times the amount of time in later phases. The more you can document how your platform fits together, the easier it will be to actually migrate.Â
Quite often, delays and issues in migration aren’t normally caused by moving from one platform to another, they are caused by unforeseen issues with existing code or software that is missing or not working as it did on-premise.
We hope you’ve found some useful info here and we’ll continue with more tips in Part 2.
