How do Microsoft Azure cloud migration projects fail?

Migrating to the cloud can be an opportunity or a distraction. It's important to plan your migration project carefully, or you could end up with a failed migration and a big, messy distraction that saps your business focus. Ultimately though, Microsoft Azure can be a powerful platform for businesses that are looking to take advantage of the flexibility and scalability of the cloud.

In this blog post, we will discuss some of the most common reasons Microsoft Azure cloud migration projects fail.

No cloud strategy: Everyone is doing it so we should?

I have seen situations where a move to the Azure cloud has been driven by a customer requirement or a desire to play with the newest technology (Don't even get me started on developers playing with Kubernetes...).

If you don't have a clear well-defined plan about how a cloud implementation will fit within your business in the short term and long term, then DO NOT START ONE!

If you don't have clear goals, then you will never get there. It will not go as planned and could lead to disastrous service for your customers and a messy distraction for a protracted period while you sort it out.

Cloud Migration tools: Not as advertised (they are not plug and play)

While Azure does offer some tools to help with the migration process, it is important to understand that these tools are not "plug and play." They require skilled IT professionals to configure and manage them properly.

In addition, third-party Microsoft Azure cloud migration tools can be expensive, so businesses need to carefully consider whether the benefits of moving to the cloud are worth the cost. As well as working out how to manage your specific workloads and how they will need to move to Azure.

Bad architecture decisions: It's okay we will just lift and shift as is

If your business is like the many ISVs I have worked with over the years, you have been going a few years, and you have established customers and services. This excludes start-ups who don't have these issues in the same way as the cloud is usually their first iteration.

You have a software offering which has been built and had gone through various upgrade cycles, and Microsoft advertises the lift and shift as a valid approach. It often is but if you try to replicate the same architecture you have on 'tin' in data centres in Azure then you will have problems.

The worst part of this is that you won't see all of the issues that this causes all in one go and they will keep holding you back until you realise where your performance/cost issues are coming from.

Azure is not the same as on-premise. It's not massively different, in many ways if you are using a virtual machine approach, but it's different enough to cause you problems if you assume it is.

Having a partner who can provide advice on the architecture and monitor it going forward is the key piece to having a successful migration and adoption. 

Inaccurate cost estimates: Working this out accurately is a challenge

This area is often poorly understood and not really looked at in detail for any implementation. The main public cloud providers have been rubbing their hands together for years, providing a pay-as-you-go model in theory and then seeing that in practice no one turns things off.

Imagine the value of the workloads running 24/7 across just the UK data centres, and the majority are always on. But do they need to be? Even if you provided a skeleton service for the down hours, you could probably turn things down for two-thirds of any day, and then for 90% of the weekend. Of course, this depends on your business, but the cloud providers are not motivated to fix this. They provide a few things that tell you what you are spending etc... but it's up to you to implement a solution that makes the cloud cost-effective, balancing performance vs cost.

The flip side of this for ISvs who have just moved to the cloud is that you will often see a large uptick in cost or spend as soon as production deployments go live, this is usually expected. But then the most common complaint is that the Azures rise over time, and if they do as they start off then it will make it uneconomical to balance cost against adding customers while maintaining performance. 99% of the time this goes back to an architecture that is holding you back. It might relate to how your app is architected or how the architecture has been built out in Azure. Either way, once understood often there is a cost-effective way to resolve things, both in the short and long term.

Performance & Maintenance issues:

This is the point at which IG CloudOps most often gets involved. You have been in the cloud a while and things are ticking along but you have the following challenges:

• Patchy performance: Bottlenecks which are stopping scaling/adoption and sapping time
• Maintenance: Keeping things patched and updated and doing the day-to-day is a time sink you haven't really accounted for - Read about the changes Adaptive realised with CloudOps
• Outages: Due to all of these problems your platform is not as bulletproof as you would like and your service to customers is suffering. Read about inclarity here and what CloudOps did for them

CloudOps covers off these day-to-day activities, so your team doesn't have to. Read more about a move to NoOps for the longer term.

However, in the short-term CloudOps will allow you to resolve most things quickly by identifying the root cause and allow you to get your team focused on your business plan again, then cover your long-term goals with contacts monitoring and feedback on cost, performance and risk logging. So, to book a test drive and find out more click here.