Getting ready to migrate your customers to Amazon Web Services (AWS)? Before you start migrating workloads, there are a few key questions to answer. Let’s explore the following considerations:
1. What Is the Ideal End State?
The first step in planning a migration is to define your customers’ desired end-state. What goals are they looking to accomplish by migrating workloads to AWS? Considering these drivers will shape the desired end-state of your customers’ environment: will it be hybrid or all-in on the cloud? What will the architecture look like? Consider which of these common architectures makes the most sense for your customers:
- Hybrid cloud with workload separation
- Hybrid cloud with workload balancing
- Hybrid cloud for disaster recovery
- All-in on the cloud
2. Which Workloads Should Be Migrated First?
When tackling a project of significant magnitude, the most challenging part is deciding where to get started. If your customer doesn’t have any infrastructure in AWS yet, the best approach is to begin migrating those workloads with the fewest dependencies. Another approach is to start with the workloads that have the most over-provisioned, or idle resources. Industry research suggests that as many as 30% of on-premises servers, both physical and virtual, are zombies (showing no signs of useful compute activity for 6 months or more). On top of that, more than 35% of servers showed activity less than 5% of the time. The best practice is to help right-size your customers’ cloud deployment on AWS so these workloads will see the greatest price/performance improvements once migrated.
3. What Is Your Customer’s Migration Strategy?
Once you and your customer have determined the end-state and which workloads to begin with, you must decide on a migration strategy. You may have multiple strategies depending on the workload, application, and business unit, but typically, organizations pick one of the following options:
- Lift and shift
- Partial refactor
- Full refactor
- Transition to SaaS or PaaS
4. What Will Your Customer’s Technical Architecture Look Like on AWS?
The last question to consider is tactical, but complex: what will your customer’s infrastructure look like on AWS? Which instance types should be used, and in which configurations? Which Reserved Instances should be purchased to maximize your customers’ investments? To properly answer these questions, you must look at historical performance data across CPU, memory, network, and disk for servers, and across throughput, capacity, and IO for storage. Decide how much “headroom” to give to each asset (typically 25%), and then look at the actual minimum, maximum, and average usage across these metrics to determine which instance type makes the most sense on AWS. A virtual machine is considered undersized when the amount of CPU demand peaks above 70% for more than 1% of any 1 hour. On the other hand, a virtual machine is considered oversized when the amount of CPU demand is below 30% for more than 1% of the time during a 7-day period. Looking at 30 days of history is sufficient, because it is easy to scale up resources on the cloud if needed. When going through this process, it’s critical to normalize for different generations of physical infrastructure.
Find out how the CloudHealth Migration Assessment simplifies the process of migrating assets from your customers’ data center to the AWS cloud. The Migration Assessment enables you to efficiently assess and model workloads for migration. You can then leverage other CloudHealth platform features to manage and optimize your customers’ infrastructure for cost, usage, performance, and security once they are running on the cloud. This helps reduce complexity and enables you move faster in the migration process.