Today there is no alternative to cloud anymore. This is what I was often hearing from customers and professionals. Cloud computing was one of the top buzzwords during the last decade.

Sometimes, based on what I read online, it seems to me that if you went into cloud, suddenly all your problems would disappear. I hate to tell you that, but this is not entirely true.

In most cases, I will still encourage you to take the challenge and join the cloud transformation. Still, please remember that the journey to cloud adoption can be bumpy. Especially, if you run into one of the following issues and mistakes which I would love that you avoid.

Mistake ° 1: No planning

The biggest mistake you can commit is to start your journey to the cloud without drawing the right plan beforehand. The simplest roadmap for cloud adoption should contain at least:

• choosing the cloud provider
• nominating the first workload for the migration.

Picking the right provider

All three main cloud providers can help you address similar challenges. At the end of the day, you will realize they can all provide similar functionalities.

The thing is, each cloud is best made for a different purpose. The objective would be to choose the right provider depending on the type of use cases and patterns you will be facing.

A good example would be selecting the right car type for you. Suppose you are choosing between a SUV, a pickup, and an estate/kombi car. All of them allow you to get safely from location A to location B. All of them will allow you to carry passengers and your luggage. Finally, they all let you play your favorite podcast on board.

At the same time, you see that each one is made for a different purpose. The SUV will be better if you plan to drive on different kind of terrains (off-road, snow, mud…). The pickup car will be the best choice if you intend to travel with heavier loads. On the other hand, the estate car will be your choice if you value comfort and versatility.

Based on this analogy, let me present you a couple of examples for cloud provider selection.

Let’s say that if your workloads and data analytics are predominantly based on website data processing (e.g., e-commerce, marketing), it would be interesting to consider Google Cloud Platform (GCP) for your use cases.

However, Azure would be the first choice to consider for organizations that are already strongly based on the Microsoft stack. This is when Power BI is the dominant analytics tool. Also, one of the advantages is the seamless integration between all Microsoft tools.

Meanwhile, in companies that have workloads depending heavily on serverless computing, Amazon Web Services (AWS) will be the best fit.

Naturally, these are only simple examples of considerations to be made. The decision to choose one or multiple cloud providers should be based on specific analysis and more inputs.

Nominating the first workload to migrate

No planning means that we probably did not consider which project should be the first candidate for migration. Still, this could be a major factor that encourages the discussion and whets the appetite for cloud adoption.

On the other hand, if you fail on the first project, no manager will push for further investments. Such situation will definitely stifle the initiative and general enthusiasm.

First, I need to stress it: it is crucial to choose one single project for the first migration. This should not be a critical system, although it is desired that the migrated workloads bring tangible results for different internal stakeholders. Select a low-hanging fruit.

Afterwards, you will quickly add layers of governance and security along the way, as your organization will be learning a lot from this first migration.

Mistake ° 2: lift-and-shift approach only

For those of you who are not familiar with the term: lift-and-shift means to pick up a solution (e.g., an application) that currently operates on-premises and make a 1:1 migration of the code and deployment to the cloud, without altering the logic in the application.

I have seen many customers embarking on a massive lift-and-shift operation. Many times it is working just fine. However, we are not fully using the features and capabilities that the cloud offers. Therefore, we increase the overhead and administrative costs without tapping into the real benefits that the cloud brings.

Let’s look at the following example: you would like to migrate your on-premises database to the cloud. Performing a lift-and-shift migration means that you spin up a virtual machine that will host your database. This means that the only thing that happens is that your database does not reside within the local network anymore, but it is now located in e.g., Microsoft’s resources.

Yet, if we turned to Platform as a Service (PaaS) approach, we could already offload part of the duties related to infrastructure maintenance (such as: patching, making sure your software is up to date, security) onto the cloud provider.

Mistake ° 3: Missing in-house cloud competencies

So, you have decided to adopt the cloud. Now, the task is to properly train your staff.

In the beginning, people do not have cloud competencies nor mindsets, because so far, they worked only on on-premises systems.

For example, even though SQL language is almost identical regardless of where the database is deployed (on-premises vs cloud), the approach to manage the environment will be drastically different.

Let’s suppose you wanted to migrate your on-premises SQL Server. PaaS Azure SQL Database resource will not support some of the on-premises functionalities, such as e.g. SQL Agent, Common Language Runtime. These are available only on-prem or for the Azure SQL Managed Instance service.

This service simulates the behavior of an on-premises database, but it is much more expensive than using Azure SQL Database. In most scenarios, using the classic Azure SQL Database PaaS service together with Azure Data Factory (ADF) will be more beneficial than provisioning an Azure SQL Managed Instance.

You already know that cloud administration needs to be approached differently. One of the common mistakes I have observed is to transfer the administration responsibilities to existing specialists without proper training and without the support nor expertise of a trusted external partner.

For example, it may turn out only after six months since you started the first implementation that you have set up only one cost center. Now, it becomes impossible to assign expenses to the appropriate owner. Proper configuration would require you to delete and recreate your whole environment.

Missing competencies can also result in incorrect resources governance (e.g., lacking division into resource groups) when all your environments are under one hat. This means that whoever gets access to the cloud gets immediate access to everything and can freely create and delete whatever resources. For example, an external developer can accidentally delete administrative resources. It also makes monitoring and identifying cost drivers hardly possible.

Mistake ° 4: Scrap whatever investment you’ve made

Another common mistake is to go all-in without properly assessing the needs. This happens when you avoid following the stepwise approach to cloud migration.

One of the customers that I have advised made significant investments in capacity, buying licenses for Exadata and SAS software. Their decision to adopt the cloud and scrap the infrastructure and services they have acquired was not necessarily optimal. Why that? Well, simply because the investment they made in Exadata did not depreciate yet.

Even though cloud adoption may be the right choice for your company, it does not need to happen at all costs. It could be that the licenses you have already bought answer to the existing and projected needs and usage at least partially.

For example, those could allow you to implement on-premises:

• dynamic customer segmentation based on the purchasing patterns
• customer lifetime value forecasting
• recommendation systems

If you do not expect a sudden surge of user base, perhaps you do not need to migrate these workflows to cloud yet.

Otherwise, you could design an architecture that connects your on-premises resources with your cloud workflows. Then, your local network infrastructure can talk to your cloud resources and easily exchange information.

Once the licenses for your on-premises software expire, you will be able to:

• lift-and-shift from on-prem to the respective selected cloud services
• or rearchitect the workloads and the solution.

Conclusion

To sum it up, we all remember the times when in on-prem era you could have waited up to six months for getting your VM up and running. Cloud allows you to get one ready within a finger snap. Still, we need to remember to setup the right guardrails which will enable us to keep the proper level of control over our environment.

These could range from policies on who can create what resource type, resources sizing, approval process for resources creation, to budget caps and alerting mechanisms. All those elements will help you to keep control of the cloud platform costs.

Now, you can see what the potential obstacles on the way to full cloud adoption and maturity are. The most common mistakes are related to planning, be it lack of planning or improper planning. Also, missing cloud competencies can have a heavy impact on the pace (and fate) of your cloud transformation.

Do you want to learn what you should be looking after when it comes to cloud cost optimization? Check out this article: 3 Key Aspects of Cloud Cost Optimization

Also, learn how Astral Forest will help you to overcome these challenges and take the bull by the horns.