How to Execute a Seamless AWS Migration

In mid-2014, Experts Exchange decided it was time to make the transition to a cloud infrastructure. We’d been spending tens of thousands of dollars per month on maintaining physical datacenters in multiple locations for development, testing, production, and disaster recovery. We were running almost fully on FreeBSD. With the way technology was shifting, the growing popularity of cloud solutions, and how the cloud could cost less than manually overseeing physical datacenters, we knew it was time for a change.

The Search

When we began the cloud search we knew we wanted a provider that would allow for a simple migration and would support FreeBSD to minimize the overhead work required in the migration. Also included in our “must have” list was the need for instances and services with the appropriate mix of performance and cost, and a platform that was stable enough to invest in for the long haul. That last factor was very important to us—and is to many companies. We wanted to conduct one major cloud migration and have it remain an effective storage and backup solution for years to come.

Our search included many large, major cloud providers. We looked at Azure, Google Cloud Platform (GCP), AWS, and Softlayer. Azure, it turned out, didn’t support FreeBSD (or Linux for that matter). We also weren’t looking to conduct a major refactor to fit into a Microsoft environment, so we ruled out Azure. Softlayer and GCP, at the time, didn’t seem as advanced or mature as AWS. In the end, AWS had more services that fit our needs and their pricing model was comparable to the other platforms.

The Migration Process

If you go to AWS’ Migration page, they outline a step-by-step guide for migrating to their cloud services:

• Phases
  1. Project Phase
  2. Foundation Phase
  3. Migration Phase
  4. Reinvention Phase

Sometimes when you approach a new tech service, guides act as a starting point but usually require modifications in order to fit your individual needs. With AWS, however, we were pleasantly surprised that these phases were spot-on with the way the migration occurred.

Here are the 4 main steps of our migration:

1. Project Phase: We began with a very small proof-of-concept. Our goal was to see if we could get the core pieces of our infrastructure running on a cloud instance. We did not do a full verification, but simply wanted to get to the point to where we could make a “go/no-go” decision.
2. Foundation: After we determined it was a “go”, we started building the foundation. This included a design of the network layout and determining what type of instances and services we would use.
3. Migration: When migrating our applications and portfolio, we made it a point to simply focus on moving as much as we could “as-is”. For example, if we had a physical server, we made a cloud instance equivalent. This helped us get started, but left a lot of room for optimization.
4. Re-invention: Once we were established in AWS’ cloud environment and we had things up and running to a point where we felt more comfortable with the platform, we found ways to optimize and integrate additional AWS services into our setup. In this process, we moved off of FreeBSD and to Amazon Linux.

When migrating to the cloud (as AWS’ website explains), companies usually rely on a rehost, replatform, repurchase, retain, refactor, or retire strategy. Sometimes just one, sometimes a mix of a few, and sometimes all six. Our migration strategy was built mainly of rehosting and refactoring steps. AWS’ network, for example, would not have easily accepted our old load balancers. Instead of trying to make it work, which could result in a difficult transfer, we switched things up in order to use AWS’ elastic load balancers.

**It’s important to note that in 2014, there were no existing migration services applicable to our situation and migration. If we did this today, we’d likely use AWS’ database migration service. We did end up using Amazon’s Relational Database Service (RDS) for our database solution instead of our existing, physical databases.**

The result of all this work? A “seamless migration,” as our CEO likes to say. We were able to migrate with little downtime and minimal issues after the cutover. The few issues we had did not affect our customer base. Other than the scheduled downtime needed to perform the transition, our users did not notice a change or impact in our site’s performance.

Before this, I’d never before done a cloud migration. While I had previously conducted migrations of physical datacenters and built out disaster recovery environments, the cloud migration was a new experience. It helped enhance my skills and brush up on information relevant to today’s typical IT infrastructures.

Maintenance

Day to day, we now rely on automation features, including configuration management tools like Ansible that allow us to automate changes we need to make to our systems. If an instance goes bad, we’re able to throw it away and create a new one quickly and easily.

Since the migration to AWS and the switch to RDS, we no longer have to maintain physical servers or storage solutions, which has minimized the overhead we’d incur with racks full of physical machines. In the past, it was up to us to switch out bad hard drives, change tape drives, manage power, refresh equipment with upgrades as our needs grew, etc. We also had our own failover and backup processes we had to test and maintain. On top of that, if there was some kind of on-call issue, it often meant we had to drive to a datacenter to get things fixed. We’re very happy we no longer have to do these things!

RDS alleviated a lot of overhead and now, with AWS, our failover processes and backups are managed externally. Adding capacity can be accomplished in just a few clicks. Needless to say, the move to AWS freed up our time and now team members can work on website and infrastructure improvements instead of handling maintenance tasks. 

Have you migrated to AWS or a similar cloud provider? How did your experience differ from ours? Tell me in the comments below.