How to Avoid the Most Common Cloud-Migration Mistakes

By: Morpheus Data

There’s no teacher like experience. There’s also nothing like learning from the experience of others.

The cloud pioneers are worth heeding when you’re embarking on an application migration project. One such early cloud adopter goes by the name of “Joe the IT Guy.” Joe identifies five things people misunderstand about cloud migrations:

  • “Any app is a candidate for lift-and-shift.” If your apps are temperamental (laden with technical debt), they will be downright incorrigible when they run on whichever cloud platform you choose. Maintenance and repair are relatively easy when the server is located in the next room. Maintaining cloud apps requires “shared responsibilities” with your service provider.
  • “There’s nothing complicated about lift-and-shift.” You can’t just “zip up” your VMs and apps and then copy them to the cloud. First, you’re dealing with an entirely new security model. Second, the very nature of the underlying network is different and is dictated primarily by the cloud service’s operational model.
  • “A VM is a VM, regardless of whose server it’s running on.” Cost comparisons between an on-premise server and a cloud instance aren’t simple. Calculating the total cost of ownership (TCO) has to consider that a cloud instance includes all the services the provider offers at a single cost, rather than just the VM hardware and software. That may include directories, DBaaS, serverless computing, and other new models.
  • “There’s no real difference between cloud providers.” Start with billing models: Each major cloud service uses a different one. Some are per minute, others are per hour. Instance sizes and prices vary widely. Services offer unique sets of features, and sometimes the same features but with different names. Last but not least, each service has its own set of APIs and consoles that are generally incompatible with each other.
  • “If we take a multi-cloud approach, we won’t be locked in.” Choosing one cloud provider entails a great deal of study and preparation. Now consider how much more entailed the process will be when you’re trying to choose multiple cloud partners for various operations, all of which need to be included under a single management umbrella. For a growing number of businesses, the Morpheus Intelligent Analytics makes it easy to match workloads to the optimal infrastructure at the right price.

Before deciding which applications to migrate, and how extensively to adapt them to cloud environments, consider the many inherent differences between on-premises and cloud architectures. Source: David S. Linthicum, via SlideShare

Failures can’t be avoided, but they can be planned for

What you can’t prevent you can at least prepare for. Before you move any application to the cloud, consider what will happen when the app becomes unavailable, for whatever reason. Fortune‘s Barb Darrow quotes one migration vet who recommends building a “reliability bubble” around critical apps you host in the cloud.

For each application, create a checklist of all possible failure points, considering every potential scenario. Then determine the best way to mitigate each glitch the app could encounter. Cloud veterans recommend adding “retry logic” to the app so it will attempt to auto-correct small errors to prevent them from becoming major outages. This is analogous to restarting a stalled PC before you call the help desk. When it hits a snag, the app is programmed to wait a preset period and then retry rather than stop immediately.

To overcome common transient failures, set the period between retries as evenly as possible among applications to avoid perpetuating a service overload. Source: Microsoft

A good way to prepare for any app migration project is to have an experienced partner by your side. Morpheus‘s unified multi-cloud orchestration applies intelligent analytics to lower costs by delivering end-to-end diagnostics on VMs, containers, and public clouds. The service’s machine learning powered remediation lets you resize app components and set power schedules. There’s no better way to manage the complete application lifecycle via a self-service infrastructure.