Skip to main content

The road to cloud: how to execute a seamless migration

By Mike Rogers, Co-Founder and CTO at SiteMinder

  Posted in Opinions



Over the past 15 years, we’ve seen the concept of the cloud shift from vague tech jargon to the de facto birthplace for startups and being aggressively adopted by most organisations around the world.

While the cloud is now ubiquitous, the path to get there has been necessary for any business that’s recognised the cloud is both the present and future. Organisations that have embraced this are those that ultimately want to be a part of that future as well.

The truth is, innovation is born out of risk, but there are ways to minimise that. Here are five things you need to know to achieve a seamless migration:

1. It’s all about the people

The success of your move is 100% dependent on having the right people.

If your long-term goal is to reduce headcount of highly-skilled resources, then you might want to reconsider. You’re going to need those people to take you forward, so don’t expect to downsize or downskill. You’ll need to migrate your systems as well as your technical team.

To ensure skills transfer and commitment, get hands-on participation during the planning and execution phases. If you can pull off the move with internal staff only, then that’s ideal, even if it means taking longer to execute.

Choose your transformation project leaders carefully – they must be technically-savvy but also adaptable, mature and resilient as there will be challenges ahead. Pay close attention to the decision-making processes and technical hierarchy, as the reality is you will likely have a few stronger individuals who make most of the calls. This is good for efficiency but try and foster a disagree-and-commit culture and be transparent about your decision-making so that even if these people depart the project, you’re not back at square one.

2. The costs are big to move – but even bigger to not move

Understand that you are investing in a digital transformation, not a CapEx transformation, which means it’s far more important to consider and communicate the cost of NOT migrating. The cost is high. It’s about the very real risk of becoming irrelevant. So, understand the risks of stagnating as well as the benefits to be had.

One obvious benefit is your ability to compete. The cloud truly does power innovation and business agility through instant access to a huge menu of services and tools. New technologies with direct customer benefit can be experimented with at little cost and no risk. Plus, long hardware provisioning times and slow adoption of technology become things of the past. Cloud-based organisations are a step ahead and it’s likely that any of your competitors who have hatched in the last five years are already there, taking advantage of all it has to offer.

Consider, too, the impact on recruitment. With the cloud cemented as a permanent fixture in the tech landscape, you will be hard pressed to find a technical person today who doesn’t believe cloud computing is in their future. By not engaging heavily in the cloud, you sacrifice your ability to hire and retain top tech talent, without whom innovation will simply not happen.

3. Strategy is crucial and it’s a long-term game

If your primary driver is to drive agility and innovation, be prepared for it to take time.

Picking a strategy to deliver incremental benefits as you travel the migration path is a smart move. Common strategies include:

Development first – This involves moving as much of your development pipeline to the cloud as possible whilst leaving your core business systems in place. If you choose this, put your demo and training environments there, too. Your engineers can get familiar with the technology, testing will always happen, and there are amazing build pipelines and tools available to give you immediate development productivity gains. Just be aware that this is a little like being at a banquet and not allowed to touch the food! Engineers can get frustrated being restricted by what can run in the production infrastructure.

Lift and shift – This involves migrating the workload from physical servers to their cloud counterparts without any real application changes. The more complex your infrastructure, the trickier this is, and it goes without saying that careful planning and constant testing is crucial.

(Micro)Service migration – This revolves around extracting less-critical chunks of your applications into discrete web services and hosting them on the cloud. It’s a relatively low-risk option, but it will generally take much longer to complete and needs you to support two environments for an extended period of time. Be careful of creating a legacy-vs-superhero culture and focusing all attention on the new, shiny stuff.

Irrespective of the strategy you choose, move with urgency but don’t rush. Give the team bandwidth to focus. This can be tough, as the likely candidates executing the migration are the same ones involved in every other critical project and production fire that happens to be burning. Work with your business to create some “space”, as context-switching will increase both the duration of the migration and risk of failure dramatically.

4. Buy-in is non-negotiable and expectations must be realistic

As an engineer, it’s easy to think of the cloud transformation from a technical perspective. However, it’s critical that your business is completely behind the decision, the long-term goals and the benefits. So, get buy-in from all your leaders and every department, else it can easily become a whipping boy if the migration becomes a tech-only initiative.

A word of warning, though: your cloud provider’s marketing machine will paint the picture that, once migrated, your business will be as innovative as Uber, only require a part-time backpacker to run all systems, and you will all get a Porsche and retire once you hit the machine learning/A.I./blockchain button.

Time to set healthy expectations. Finance needs to know that costs will soar during the initial phase and probably for a while thereafter. Product needs to understand that features will be slow to ship as a massive transformation occurs in the back end. Even your technical staff have to be on board with the fact that Kubernetes is fun when you are running your Hello World app, but not so much at 3am when “something is wrong in production”.

Be wary of over-promising to your business and customers. They will likely see tangible benefits and real innovation only once significant changes have been made to your architecture and cloud services are adopted across the board – which could take years.

5. Everything needs to be automated and kept simple

It’s easy to get carried away with all the service offerings provided by the cloud, but, oftentimes, the most effective ones are the oldest and simplest. AWS’s S3, for example, is incredibly versatile for document storage, querying and queuing. Start with these stalwarts and save the more esoteric for later.

Focus on getting some wins quickly, as oftentimes the basics will score faster. Introduce tech which has the least impact on application architecture first. Containerisation can be a great place to start as the flow-on benefits to many other areas, particularly software development, is huge.

Try not to do anything manually. Describe and deploy your infrastructure with something like Terraform. The goal should be to free up people so they can execute on projects which drive customer value.

The road to cloud is far from easy. It takes work, but the benefits of greater agility, increased innovation and speed-to-market, instant scaling and provisioning, team alignment, reduced dependency on your hosting provider’s staff and skills, and ability to tweak performance versus cost metrics are immeasurable.

 

Thanks for sharing

Sign up to our blog and receive regular updates on the content you're into

Send this to a friend