Navigating past the hype – our top tips for successful cloud migration.

In 1995, Gartner pioneered their concept of the technology Hype Cycle, giving IT teams a way of understanding where in the lifecycle of innovation new technologies were, and whether the time was right to get on board. In the nearly three decades since then, a lot has changed in IT, but being wary of technology hype is still a critical consideration for IT teams.

Cloud technology has seen adoption across almost every aspect of enterprise IT, but it still carries a significant hype factor with it. While it seems to be well-established in the plateau of productivity, we’ve seen plenty of cases where an IT team has committed to moving business workloads to the cloud without fully assessing if they can reap the rewards from this journey.

Taking a step back to analyse your current landscape, understand its challenges, and what portion of those a cloud migration journey will resolve is critical in this endeavour. Whether you’re a seasoned cloud evangelist or just getting started, this blog is here to help.

Devising a strategy

Firstly, before you take any steps towards moving a workload to the cloud, it’s vital to create a comprehensive strategy, which anticipates and resolves key challenges:

• What does your environment look like today?

• How do you stand to gain from cloud adoption?

• What are the major roadblocks for your cloud migration?

• What does your adoption framework and timeline look like?

The present

An important factor in your strategy is analysing the state of the current platforms. Application workloads often run extended lives since they are difficult (and expensive) to replace. Adding yet another initiative might prove to be a bad choice for some of your applications, while for others it might feel like the next step in their natural evolution. This is the time to listen to your application and support teams in terms of the potential for your applications to expand and evolve. Legacy systems might need to stay on-premises, but perhaps a new intermediate layer on cloud can add that extra layer of security, speed, or resilience you’ve always wanted, while leaving the door open to future improvements.

Potential gains

To come to a decision as to whether it’s worth moving to the cloud, a major consideration should be what you stand to gain. You can group your gains in two categories – cost savings and functional gains. If you aren’t going to see positive outcomes in both categories, you might want to reconsider the overall initiative.

The main motivator we see today is the potential cost savings that cloud infrastructure can offer. These gains stem from your ability to leverage the fact that cloud infrastructure is dynamic by nature. Rather than having your applications built around your on-premises infrastructure, you now have a fluid environment built around your application and its needs. But this can be a double-edged sword if you don’t play your cards well. A monolithic application can only evolve so much in a dynamic cloud environment before it starts to affect functionality. In contrast, native microservices applications are engineered from the beginning with this in mind.

In an on-premises environment, you will often oversize supporting infrastructure to ensure you have enough spare capacity to avoid experiencing bottlenecks during your peak usage periods – but outside of those times, you’re paying for capacity that goes unused – which adopting cloud infrastructure eliminates. 

We recommend collecting at least one year’s worth of application performance data, so all the seasonal events that impact your application traffic occur at least once. In the meantime, gaining application insight using APM can prove beneficial for fixing application/code related performance challenges.

Comparing your current operational and hardware costs next to your cloud expenses is an essential part of every adequate cloud migration strategy. While doing so you should become well aware of how the cloud billing models function, as well as the potential additional expenses that may accompany moving to the cloud, like hiring skilled resources to operate your new environment, or dev work required to make your current system operate with your future cloud environment.

Functional gains 

While cost is important it is not sufficient to serve as a justification for your initiative on its own. You can only predict so many costs and will not be able to anticipate new problems that will naturally accumulate on the new platform. 

Investing in a bit of innovation along the way pays off. Cloud infrastructure offers great ways to increase your scalability, availability and mean time to response (MTTR). Even if your migration model needs to be a lift-and-shift strategy, you should try to make the most of the available cloud functions. A phased approach here can come in handy, providing a more realistic migration plan with achievable goals both short and long term. We often see companies starting with a lift-and-shift approach that still yields an improvement in deployment and operational scenarios, thanks to the vast number of automation techniques available on the cloud. This allows you some breathing space to plan the more serious transformations of your platforms to make them cloud native – it’s also helpful for balancing budgets. 

Roadblocks

This is where you anticipate the potential challenges in migration. Any technology will come with limitations. This can lead you to a dead end with your current application when it comes to how much you can gain from running in the cloud. And you don’t want to be making those discoveries retrospectively.

Thankfully serious blocks for a given platform are already well-known by your application teams. However, certain aspects of those challenges can only become evident when you look at your application landscape through the cloud prism – so it helps if you work with a cloud professional or someone with some experience in running workloads on cloud.

A roadblock can be a clear technology limitation, both for your current on-premises and future cloud model, but it can also be something less visible. In the end it’s beneficial to discuss with your teams and get their perspective.

At this point we’ve covered some of the short- and long-term benefits, as well as the key challenges we need to address on our way to the cloud. All this data can be used to create an adoption plan for your next generation platform. A roadmap is a must when working on a strategy of this scale. It’s a simple but powerful way of visualising the data you have, and the key points in your cloud migration. But the timeline can look beyond just the path to migration and touch on post-migration goals, such as new version upgrades, enhanced functionality, or going fully cloud native.

Moving to the cloud

The most straightforward method is to simply rehost the application – what’s commonly known as “lift-and-shift” – for instance, taking your virtual machine templates (or even the data itself) and moving to the cloud. It’s simple and effective, but it can limit the benefits you see from cloud migration – especially for older, more monolithic applications which will struggle to take advantage of their new environment.

As mentioned earlier, we tend to find that the best approach is usually a two-part strategy: lift-and-shift your applications into the cloud, and then once they’re properly situated, begin tinkering with them to make the most of their new environment. Doing so will potentially involve refactoring the application – rewriting its components so that they can capitalise on cloud services. Since refactoring can be a lengthy process, having already shifted to the cloud allows you to see some of the benefits of a cloud environment while you rewrite the application, rather than having to keep everything running on-premises.

Of course, there are always situations where cloud migration is held back by monolithic legacy applications, which are unsuitable to lift and shift into the cloud. Take banking for example – many of the core systems banks use are old applications which would be prohibitively expensive to refactor, and may need to be maintained on-premises due to other constraints – such as security concerns or GDPR compliance. Users still demand the flexibility of cloud technology for these applications, and in this case, it’s often beneficial to use APIs to serve as a translation layer, running between cloud native apps and older legacy systems. Sticking with the example of banking, we see this approach adopted in most mobile banking apps, which offer a frictionless, cloud-based experience to users, while using an API to connect that experience to a core legacy system – meaning that you don’t need to dedicate time and resources to trying to refactor those older, business-critical apps.

Making the most of cloud features

Once you’ve established yourself in the cloud, you need to plan ahead to extract the most value out of your migration. To do this, the goal should be to build your apps to be cloud native – whether that means completely reworking your existing apps or developing new ones to fill the same role. Creating cloud-native apps involves breaking the functions of the app into microservices, which can be rapidly moved and developed to deliver better user experiences faster, and at lower cost.

A key example of the benefits cloud-native apps offer is blue/green deployment, where an organisation runs two identical copies of an app, one of which is live at any given time. Having a duplicate of the production application allows developer teams to work on improving an application without worrying about interfering with the production version of the app – and since the app is already in the cloud, a small number of users can be directed to the updated version of the app to test it before it becomes the live version. In an on-premises environment, this would necessitate doubling your infrastructure, creating a massive increase in costs – but since cloud infrastructure is typically billed based on usage, blue/green deployment can represent a cost saving while also improving your ability to develop and update your applications.

While the benefits can be significant, going cloud native is a big commitment, and can’t be rushed. In order to keep everything on-track, you need to strategize based on what will need to be done to go cloud native, and how you can leverage being cloud native to benefit your organisation. Rearchitecting an app into a collection of microservices isn’t a fast process, and can incur significant costs over that timeframe – we recommend a planning horizon of between 5 and 6 years before a business can reap the full rewards of rearchitecting an existing app. If it’s not worthwhile, then you should be looking to your next generation of apps and ensuring that they are cloud native from the start.

The next steps

Whatever your strategy for cloud migration looks like, Perform IT are here to help. Our experience and skills can help you develop and execute a strategy that works best for your business, and helps you see the full value of migration. If you’d like to know more, get in touch with us.