Top 5 mistakes of cloud migration

At SoftwareOne, thousands of our customers are in the midst of their organisations’ journey to cloud. I have conversations every week with senior IT executives as they evolve their cloud strategies. I notice five recurring themes that I believe are mistakes when adopting public cloud.

Let me know what you think and if this also resonates with what you see in the market.

1. Approaching the move to the cloud as a mere datacentre replacement

Some of the leaders I talk to have too heavy an infrastructure perspective on cloud. In these cases, they may think “let’s move and let’s make it fast.” To do that, you must ignore the problems of non-optimised cloud moves and projects that deliver little to no business value.

Maybe your company just made a big commitment to a hyperscaler, and the clock is ticking. A bunch of apps are rehosted with the justification of “we’ve paid for it already.” As the apps typically remain untouched, after months of cloud investment the best-case scenario is that the migrated apps will operate and behave exactly the same as they did on premises. Few of the hyped cloud promises are there—the apps look and work the same.

2. Prioritising applications to be migrated based on technology rather than business outcomes

Some of our customers want to migrate applications based on what is the most technically expedient, but do not balance that with what would provide the greatest business impact. This approach simplifies the work and gives the IT department more agility in the move, but the outcome may be disappointing for the business.

Executives have high expectations about what cloud can provide (helped by the hyperscalers’ marketing). Moving to the cloud and delivering the same experience and similar cost might not be good enough. This is especially true if the migration process consumes many IT resources, the business-as-usual service is impacted, or other strategic projects are postponed.

3. Using a whiteboarding-based approach to planning instead of a tools and best practices-based approach

Many organisations rely on internal assumptions about technical viability, architecture consistency, code quality, and refactoring capabilities. (Who wants to throw away all that code that’s working?) Making assumptions up front in the planning process often has a boomerang effect. It can be shocking to see how many times cloud migrations are planned with little insight about what application changes may be required or how feasible refactoring specific applications will be.

Even within the category of refactoring, there are levels of effort. It’s not the same thing to refactor an app to just get it running on PaaS or to fix the security issues as it is to completely revamp it using microservices approaches. The best way to know what you have and what you’re dealing with to migrate it is to use automated discovery and inspection tools alongside industry-accepted methods.

4. Having disconnected development and operation cloud strategies

When adopting cloud, IT managers have a bias towards datacentre replacement and infrastructure cost savings while development teams focus on productivity and new application capabilities. These groups must intentionally work together on the often-underestimated challenges of cloud adoption, such as: How does backup now work? How do we extend our security landscape to the cloud? What’s the right governance model in the cloud?

5. Thinking about cost the traditional way

When we help customers create cloud business cases and look at how they are comparing cloud and on-premises workloads, we often see that they lack the FinOps expertise to manage a more sophisticated cost and procurement scenario in a multicloud world. Systems Integrators, Cloud Architects are rarely software or licensing experts. They are not focused on the pricing dynamics of the IT world.

For example, if you want to buy a database license or another specific software product, you have the option to purchase directly on cloud marketplaces but also through traditional software contracts with hybrid, on-premise and cloud rights. If you build your business case assuming that the software will be procured in the cloud as a SaaS solution (which may seem reasonable for an architect to assume), it’s simply the wrong way to build the cost estimate. In fact, we’ve seen many situations where the business case does not work in the cloud because the software costs are overestimated or not optimised. We also see this with cloud infrastructure, where long-term contracts often improve unit costs.