The Most Common Cloud Migration Mistakes, and How to Avoid Them

You can tell yourself a thousand times, “The cloud is different.” Yet you’re still looking at the features people need in their applications the way you did when the features were in apps running in-house. Don’t create a cloud duplicate of your local systems. Start the migration process by asking users what functions they need. Then find the best cloud tools for integrating and managing those operations.

The same mistake is being repeated thousands of times at companies large and small. A typical scenario is described by Computerworld’s Sharon Gaudin in an April 17, 2017, article on cloud migration mistakes: An unnamed firm switched from Novell’s GroupWise to Google’s G Suite only to find users struggling. The company discovered after the fact that calendar features people relied on when using GroupWise had no comparable function in G Suite.

Gaudin quotes a senior IT manager for King County, Washington, who is two years into a cloud migration program involving hundreds of individual apps: “How you run your business in the cloud is different than how you run it [on premises]… There are changes in how you do your work, the skills that are needed, the process.”

The King County network runs 1,600 apps in-house and connects 13,000 employees at 220 separate sites. Since 2015 the county has moved 30 apps to AWS and Microsoft Azure; it plans to migrate 120 more apps to the cloud in 2017. The first year of the project was spent preparing, learning, and making mistakes, according to county IT officials. However, they see the cloud as a “good value proposition” because of universal data accessibility and lower hardware and power costs.

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

Start slow, keep it simple, be ready to learn

Cloud-migration veterans warn companies that are just starting the process to think small. Identify the apps that are ready to be replaced and that don’t contain sensitive data to minimize the risk of inadvertent compliance violations. Look for apps with spiky workloads to take advantage of the cloud’s scalability.

An example of how easy it is to overlook an important component of the app migration process is King County’s cloud-based backup application. The county thoroughly tested the cloud app’s ability to back up the agency’s data, but they neglected to test its ability to restore a backup after a failure. When it came time to restore a backup, they found it took longer than three hours for the system to retrieve the data before they could begin the restoration process. With the in-house backup system, restorations began immediately.

Many companies fail to convince business managers of the value of cloud-based applications. They mistakenly assume the cloud’s advantages in speed, efficiency, and flexibility are evident to line managers and employees. It’s important to stress the business value of individual cloud apps from the beginning of the migration process.

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. In a March 24, 2017, article by Fortune’s Barb Darrow, Vishwas Lele of consulting firm Applied Information Sciences 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 consider the best way to mitigate each glitch the app could encounter. Lele recommends 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 key difference between cloud apps and those you host in-house is the heightened awareness cloud-based systems require about the environment they’re running in. A common mistake that many companies make when first implementing cloud services is to assume the systems are more resilient than they actually are, according to Tim Crawford, an analyst for IT consultancy AVOA. The resiliency that is built into many levels of in-house data centers is simply not present in the cloud. That’s why features such as retry logic are more valuable in cloud settings.

Don’t fall for any of these five common migration misconceptions

They say you can always spot the pioneers: They’re the ones with the arrows in their backs.

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.” In a May 10, 2017, post, Joe presents the five things IT service managers are most likely to get wrong about cloud migration:

• “Any app is a candidate for lift-and-shift.” If your apps are temperamental “snowflakes” (laden with technical debt), they will be downright incorrigible 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 an entirely different approach based on “shared responsibilities” with your service provider.
• “There’s nothing complicated about lift-and-shift.” You can’t just “zip up” your VMs and data 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. It’s often best to begin with a single all-in-one service and then get some insurance against lock-in by expanding to a second cloud service for disaster recovery, for example.