Migrating workloads to the public cloud is taking most enterprise IT organization’s time these days. Although analyst predictions vary, I would say we’re at about 20 percent migrated in the Global 2000, including PaaS, IaaS, and SaaS.
Common mistakes are beginning to emerge in these cloud migrations. Here are the top three mistskes I'm seeing—and they are easily avoidable if you know what to watch for.
Cloud migration mistake No. 1: Doing pure “lift and shift”
“Lift and shift,” simply put, is the process of moving code and data to a platform analog in the public cloud, typically making little or no modifications. While this approach saves time and money, at least at first, it may not get you to where you need to go because cloud-based applications need to have some cloud-native localization. You need this localization to use the public cloud platform in optimal ways, taking advantage of native features to reduce operational cost and increase performance.
The path here is easy to predict: Enterprises will move workloads to the cloud using a “lift and shift” approach, then in a year or two will have to go back in and modify (or refactor) the applications to use cloud-native features once they see the cost of hosting nonnative apps. In the meantime, the application is 30 to 40 percent less efficient.
It's better to do it right out of the gate, and not simply "lift and shift."
Cloud migration mistake No. 2: Not dealing with data
A similar mistake as overly focusing on “lift and shift” is not dealing with the issues around the database after migration. The tendency is to pick pretty much the same database you've had on premises, no matter how much it costs. As a result, you end up spending way too much on the database in the cloud.
This database inefficiency can undermine the reason you’ve moved to cloud computing in the first place. You should look at migrating to a better database in the cloud, such as purpose-built cloud-native databases that may provide better services, performance at a greatly reduced price.
Of course, your own unique needs will determine what database you need and use. Just make sure to consider born-in-the-cloud options as well.
Cloud migration mistake No. 3: Avoiding or delaying integration with devops.
This mistake is actually a bigger deal than it sounds. Too often, the cloud team does not talk to the devops team, so there is a disconnect as to how cloud meets the devops tool chain and processes.
This huge mistake can cost millions in lost productivity. And it's unnecessary: You can do application development and operation in the cloud, and you can couple devops tools chains, testing, and deployment with cloud-based services.
You’re going to have to deal with cloud and devops integration at some point, so you’re just kicking the can down the road if you don't do it up front. Perhaps worse, by not bringing devops up front in the cloud migration, you’re setting expectations that you’re okay with noncloud platform (that is, with on-premises) deployments—these should not even be on the radar these days.