5 Ways to Mess up Your Migration to the Public Cloud

The glorious public cloud is the holy grail of hosting to so many companies today, yet thousands of companies have suffered painful migrations to get there.  Companies have also realized certain workloads don’t make sense to run in the public cloud and have had to spend significant resources moving it back out of the public cloud. So, what are the most common mistakes people make when moving to the public cloud? Let’s discuss so you can avoid them!

Here are the 5 traps most people fall into:

      • Assume all Public Clouds are the same – Each cloud is different. Different hypervisors, storage types, OS’s, hardware; it’s all different. When all components are different you can’t just assume that if someone built a full scale plan for Azure at some point that it will automatically work in AWS. Your application or site needs to be tailored to work with a specific type of storage, OS, and more. Each public cloud is best at a particular area, and it’s important to choose the public cloud that works best for your type of application. AWS leads in automation tools, Azure leads in integrating with other Microsoft technologies, and Google Cloud leads in multiple streaming capabilities. Does your application or site fall within one of those? If so, that should help with narrowing things down. If not, what does your code base work best on in terms of OS and storage? That can start the process. Make sure you and everyone on your team understands that every public cloud is different.

 

      • Not Bringing in Proven Expertise – I can’t tell you how many times really smart technical teams think they can just jump in and figure out the public cloud. With enough time and training, these teams absolutely could. However, they will not bring the lessons learned through experience and best practices that a proven expert would. The public cloud is complicated and can be a timely and expensive endeavor. You do not want to make it worse by trying to figure it all out on your own. This can lead to unnecessary added time, money, and painful experiences for your team when there are capable resources out there today to help you.

 

      • Moving Everything at Once – Never, ever move everything to the public cloud at once. First, not everything is meant for the public cloud. As addressed in a previous article, prioritizing your applications and sites in a tiered structure in terms of importance and impact is critical to your success to moving things to the cloud. This allows you to evaluate and learn with much less critical applications and then you can move your way up to more mission critical applications. Also, many companies have found that not all of their applications or sites are appropriate for the public cloud. Whether it is pricing, high availability, compliance requirements, large scale databases or other critical factors, there are multiple scenarios where certain applications or sites are not well suited for the public cloud. Even if all of your applications and/or sites are meant for the cloud, again tier them and move them one or two at a time so you can learn your way through the process before putting mission critical applications out there.

 

      • Not Understanding the Key Cost Drivers in the Public Cloud – Too many companies assume that the public cloud is always cheaper, then 2-3 months after they move to the public cloud they have sticker shock when they receive their invoice. Some areas that people usually miss in the calculation and evaluation process is outbound bandwidth, compute on high end databases, and environment sprawl. Most site or application traffic is inbound and most public clouds do not charge for inbound bandwidth, which is great. However, when you start moving data to another region or your application does 2 way communication with the users, companies get surprised at how quickly outbound bandwidth costs can escalate. The next example is when companies have databases that churn and are extremely heavy on the compute side. If they really use compute heavily enough, the costs can go up very quickly and this could be an example where a baremetal/dedicated resource could be more appropriate. Multiple companies are now putting their web front ends in the public cloud, while handling their databases on dedicated servers in a managed environment to save on costs. The final example is when companies allow developers and other resources to spin up dev and test environments in an agile format to improve speed of delivery, but they forget to manage environment sprawl. Developers can forget environments they spun up after moving to the next sprint and it never gets turned down. If you have multiple people doing this and you have no one to manage it, this can cost you serious monthly spend.

 

      • Skimp on Timeline & Budget – There is no other way to say it other than to say the public cloud is extremely complicated. If you push timelines and skimp on resources, you can wind up with a huge pile of unusable resources that no application could run on, much less your application. When you make the commitment to move to the public cloud, commit to taking your time and spending money on resources that have successfully done it before, so you can get it right the first time around.
         
        Here’s a great example where trying to skimp on budget and timeline can wind up making both worse in the long run. I personally watched a customer who wanted to take over the management of an already existing public cloud environment and decided to do it on their own to save costs. Again, not even architecting and building, simply managing an existing environment. Within a month of taking over the account, they were in over their heads and needed help getting them back to where they needed to be, to have the application operate effectively. It took us much longer and it was much more painful for them than if they had come to us day one, but we were able to get it corrected.

Some of these may seem like no brainers and others might have been an eye openers, but trust me when I say that I have seen companies small, medium, and large fall into these traps. So, take your time, create a clear plan, ensure you have proven guidance by those who have done it before, invest the proper money on resources and technology, and understand the cost drivers of where you are going. If you avoid these 5 traps you have a far better chance of successfully migrating to the public cloud.