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.
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.
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.
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.
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.
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:
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.