By Corey Quinn

We are excited to share our Guest Blog from Corey Quinn. Corey is a former Taoser and huge community advocate of Taos.

During my consulting tenure with Taos, I had the privilege of architecting numerous cloud migrations. Now that I curate, I’ve gained particular insight into many more. I want to be very clear that I’m not saying that cloud migrations are follies– far from it! My point is that cloud migrations have a lot of sharp edges, and leveraging the expertise of specialists who live in this world is critical to success.

**Cloud migrations take longer than you think they will and are very expensive.**

Let’s pretend you’ve got a datacenter full of legacy applications. The economic advantages of the cloud depend upon your application behaving in ways that it almost certainly doesn’t today. If you try to refactor all of your existing apps at the same time as you’re migrating to a cloud provider, you’re setting the stage for a story that ends in tears before bedtime. Instead, think of these projects as two distinct entities. The first project is to get what you have in its current form running in a cloud environment. This will likely be extortionately expensive. Don’t worry; this too shall pass. You’re going to have to make changes here (you’re not going to be able to shove an EMC SAN into an AWS Availability Zone without some serious negotiating!), but strive to keep them to the bare minimum required to migrate. The second project should revolve around refactoring and rearchitecting your applications to leverage the advantages of the cloud. This is where technologies such as autoscaling, containerization, and serverless come in to play. As applications become modernized, you get to watch your cloud footprint not only shrink but dynamically grow and contract with minute-to-minute demand. If you try to combine these two projects into one, you get to watch your cloud footprint step on everyone’s toes.

**It’s important to have a business case to migrate.**

In the dotcom boom, we learned that “because it’s cool” isn’t a compelling reason to build something– there has to be a business case. In the Cloud Rush, it seems we have to learn the very similar lesson of “the in-flight magazine uses the word ‘cloud’ a lot” is similarly insufficient to justify large scale migrations.

The benefits of the cloud are vast and deep– it can dramatically boost the speed of iteration, you can save large sums of money by leveraging elasticity, and you can get out of areas that aren’t your company’s core competencies– such as running datacenters. Just make sure that the benefits that you’re hoping to leverage for your company are real.

**There has never been a completely successful cloud migration.**

You may think I’m being flippant here, but there’s a point: when a company decides to move from on-premise data centers to AWS, from AWS to Google Cloud platform, from a burning dumpster full of tires to Microsoft Azure, etc., “The Plan” is created. The Plan is glorious, a shining beacon atop a hill for all to marvel at. Unfortunately, these gossamer dreams soon meet the iron bar of reality. Migrating things is *hard*, particularly when there are fifteen years of application history weighing down. Once beautiful, The Plan becomes tattered and worn as compromises are struck. Inevitably it becomes clear that one particular application can’t be moved, either due to arcane restrictions (contractual, legal, or technical) or the sheer economics of it (“Hosting this workload in the cloud would cost us six times as much as the entire engineering team!”). Companies are never big on trumpeting failures when they can spin it into a positive, so the narrative changes as a result. Their architecture is now either classified as “Hybrid” or “Multi-Cloud.”

**All Cloud Providers Have Problems**

Success stories at large conferences pick and choose between aspects of various technology wins– nobody is going to get on stage before tens of thousands of people at a vendor-sponsored event and tell the story of how they tried to migrate to the cloud and it nearly destroyed their company. This isn’t to say that these providers are bad, or that migration is a folly, or doomed to failure, but rather to go into such projects with your eyes open. Talk to people who are hands-on with your provider of choice at other companies, and get them to speak honestly. All technology has problems– the secret is in learning what various failure modes look like, and having a mitigation plan to account for them.