Some articles deserve a strong disclaimer. This feels like one of those that deserves a particularly strong one. So, here it goes:
DISCLAIMER: Using a migration strategy for your current on-premises workloads is a pretty terrible idea. This is what we call the "Lift and Shift" model. There are a lot of reasons it's a terrible idea. When it is the only option, we should take some important steps first. This is the goal of the article.
Moving workloads to the cloud has some very interesting challenges. Beyond the most challenging ones such as having a tool to migrate the virtual servers into cloud instances, we need to think about how to make the migration and new location as efficient as possible.
You clean before you move, not after.
A friend of mine from a previous job told me a great story. He and his family were moving from Vancouver to Toronto, so they hired professional movers. The movers were a complete full-service group that handles packing and delivery. The funny part of the story is that when the family arrived in Toronto, they had a kitchen garbage can which contained the very same garbage that was there in Vancouver.
You may think that it's a somewhat silly comparison to a cloud migration. Let's think for a moment on what it is that it really represents. The company was hired to migrate the contents from one place to another. The company can't say with certainty that any of the contents (even the garbage can contents) are meant to be left behind. If there happened to be something that was in that container, they would be responsible for it not being on the other side.
Bring this to the cloud migration story comparison. When we started the move to virtualization, we did P2V (physical to virtual) migrations. They employed a tool (like a moving company) which did not discern what should or shouldn't be migrated. We are repeating the same process in a lot of was when we do the "lift and shift" into the cloud, but we don't have to.
Prepare the Source to Fit the Destination
If you're moving to an apartment, you may not bring the full room sofa that takes up an 800 square foot room. That is because you will be using the entirety of the destination room for the sofa when you don't really have the room, or even if you do, you may not have been using the entire sofa even at the source. Cloud migrations and cloud migration utilities will very simply bring over what you have and may even add a little headroom. When you're talking about a public cloud platform, that headroom is expensive.
If you oversize 100 EC2 instances by one template size too much at some instances template sizes, that can translate to a 1.2 Million dollar overspend. Take that in for a minute as you think about how many virtual servers you have in your data center. Scary, isn't it?
This is where we have to be certain that we really used the source to it's full capacity before we think about sizing it for the target. If you have a 4-vCPU VM with 12 GB of RAM, you are looking at an M3.large which will run you around 2330$ per year using an on-demand instance.
If you were to take the same machine and right-size it prior to putting it out into AWS, you could make a significant savings. There are no doubt that cloud migrations are challenging, complex, and potentially very expensive. What we don't want to have happen is to improperly size and migrate resources and then blame "the cloud" for why it didn't go well. That's a people and process challenge that we need to use technology to solve.