Agility, scalability, and long-term business need… there are many reasons why no two migrations to the cloud are the same. Here we look at five businesses that have made the move, and how they chose to get there.
Almost every business today recognises the need to transform themselves to keep up and remain competitive in the digital age and (rightly) view Cloud as the way to achieving that. The flexibility and agility that Cloud offers are the orders of the day in uncertain times, but while many would like to throw everything in the Cloud and be done with it, it’s not as simple as that.
Unless you’re working from a greenfield site, you’ll have to think carefully about which applications you move to the Cloud and when balancing legacy considerations with your business objectives. The trick is identifying where the transformational benefits of Cloud can really be secured, and which workloads are of a lesser priority.
What’s clear is that there is no one-size-fits-all Cloud solution and that no two migrations will be the same. In fact, the right strategy will vary, sometimes considerably, by application.
With that in mind, what do you need to think about before taking the leap into Cloud?
Think ahead...
The move to Cloud can be a complicated process. There’s no such thing as a ‘big bang’ solution where a change can be made overnight and be in place the next day. In fact, while some projects can be done and dusted within a month, it’s not unheard of for them to take over three years, depending on the complexity of the project and number of moving parts.
This variance makes planning essential to ensure you know what you’re dealing with and understand all of the different dependencies in your IT estate so that you’re not caught short halfway through a project.
In fact, this planning phase can take just as long, if not longer than the migration itself, as a major construction firm recently found out with its move to Cloud. After spending around nine months planning the project, it was able to migrate 200 virtual machines and 800 datacentres to Azure in six weeks flat and without a hitch.
It definitely pays to do your homework.
Are your applications Cloud-ready?
Public Cloud, when deployed correctly, is transformative but it’s not right for every application. A big and costly mistake that companies often make is that they believe that simply ‘lifting and shifting’ their servers and applications to Public Cloud is all that needs to be done as far as migration is concerned. It’s important to recognise that for many legacy applications, public cloud may not give an immediate return on investment.
Where Public Cloud is appropriate, an in-depth knowledge of the Big Three (AWS, Microsoft, and Google) – each of which come with unique tools – is another factor to consider when deciding what is most appropriate for a business’ strategy.
Before any migration, it’s important to assess your applications to check whether they are Cloud-ready or need to be re-engineered – or you’ll risk paying over the odds for a platform that you’re not able to take full advantage of.
One business learned this the hard way. They tried to move their applications out of a datacentre to a major Cloud platform on their own but quickly discovered it was more expensive to run and they were not able to maximise any benefits. Their hasty retreat from the Cloud and back to their old datacentre was certainly no surprise.
To scale or not to scale
The ability of Cloud to scale with demand is one of its key selling points, particularly for businesses with customer-facing applications that receive variable amounts of traffic and for those organisations in the middle of an increase in business growth.
For a fast-fashion retailer whose site can experience over 40 times normal peak traffic within a matter of minutes, the scalability of Public Cloud makes it a natural fit. But it’s not necessarily going to be suitable for the more stable workloads of internal applications. A mistake here could see you paying more for functionality you don’t need.
Focusing on applications and how they deliver value to the business is essential to consider before making the move, answering the question “why am I doing this and what impact will it have?” Only then will it be clear where you should house them.
Know your strengths
There is no doubt that public Cloud has immense potential to transform a business, but implementing and managing the platform can challenge even the most experienced IT teams.
This is something a fintech company recently found out. Despite its rapidly-growing business, it had initially discounted moving its servers to AWS as they lacked the skills needed in-house to safely make the move. But after a five-month project, which focused on architecting the solution and upskilling their staff, they’re now in a position where they can comfortably manage everything themselves.
However, even if you have the skills in-house to make the move, you might decide your team's efforts would be better spent on driving towards your business objectives. Upskilling can be a time-consuming and expensive process, so spending all of this resource on this area might not be the most cost-effective activity.
The path to Cloud success
A move to Public Cloud requires appropriate research to be carried out before taking the plunge. This should include a comprehensive review of what your company needs, a sense of realism in terms of timescales, and forward planning to make sure that a migration is factored into the wider business strategy. To aid in this process, a third-party provider can bring the expertise and resource to make your Cloud migration project a real success.
Key takeaways:
- The benefits of Cloud are clear, but there is no one-size-fits-all solution when it comes to migration
- Meticulous planning of a migration is key, as it can significantly reduce the time spent carrying out the implementation
- Assess your applications to work out whether they are cloud-ready before you make the decision to migrate
- Pay close attention to the individual needs of your business, so that you don’t end up paying for functionality that you don’t need