How to botch a cloud migration in three easy steps – and how to remedy it

Today, the cloud is where everyone wants to be; there is no place like it, and nothing makes your clients happier. Okay, that may be a bit of a stretch – but it’s also fair to say that not everyone can dive into the cloud with their current architecture. Many times, it takes a complete re-engineering process in order to carry a company – or even a simple product – into any cloud.

Here are three areas to think about to ensure you do not carry out a disastrous cloud migration.

Rush it and think ‘agile!’

Go with the flow and just migrate: how hard can that be? We are all familiar with the phrase ‘failure to plan is planning to fail’ – and most cloud migrations break in terrible ways due to failure to plan. All that is needed is a few engineers to move components from one place to the other, then everything is plugged together and – voila – it magically works, because it is the cloud, a magical place where everything seems to fall seamlessly into place. Right?

Perhaps not. There is another way. The old school way, the real engineering way, where you make use not only of system administrators, but instead run different teams with a central project manager who keeps things on track and acts like the glue that keeps the team communicating and working with each other like a well-oiled machine.

Communication is a critical step. We all dislike meetings, but if we do not communicate, we will run into massive issues. It is important that at least one person from each team has some facetime with a person from another team; also, a once a week global meeting to see how things are moving.

Thinking from first principles – an age-old concept recently popularised by Elon Musk – is good, but learning what others did and how they worked is extremely useful. Using agile principles is nice; holding stand up meetings in 10 minutes is nice; having a scrum master is good; but the old methodology of a PM with a Gantt chart keeping track of things and documenting everything is known to work wonders.

Above all, go slowly and design a solid foundation: an architecture in which the engineers can give their feedback and build on good ground. Trust the engineers. They will stand to suspicion on technical difficulties. If not, they will be the ones paying for it – trust them.

Lift and shift

Lift and shift is very popular nowadays. Why? Some people think moving to the cloud means moving from one data centre to another, cheaper and with more resources. It’s distributed, with nicer dashboards, but it’s just another data centre.

Needless to say, this is not the case. This is only re-hosting. This is how the process usually goes:

  • Create an inventory of resources
  • Instantiate the same resources in cloud X
  • Create the failover, high availability and/or disaster recovery solutions
  • Upload all the data and watch everything fall apart

A bigger problem is that it sometimes ‘works’, but there is no improvement. Moving to cloud is adopting a new paradigm: it means implementing cloud orchestration, automation, a different form of resilience, and of course everything as a service (XaaS); using third party components instead of implementing your own.

Once in the cloud, you do not need to install products such as Icinga or Nagios; monitoring is already there as a service. It’s the same for most LAMP stack components – it’s everything as a service! As the old quote goes – simplicity is the ultimate sophistication.

Move to an immature cloud

Don’t forget to run a checklist on things that might be needed. As an example:

  • How many X as a service do I have? What is my uptime?
  • Do I have redundancy? Regions?
  • How many availability zones and domains do I have? Where? Are they real?
  • What about security and restrictions?
  • Compliance and data regulations – is my data safe?
  • Popularity – is this cloud here to stay? Long term?
  • Third-party vendors – is there an app, support, solution, consultants’ market?

Conclusion

There are many things which need to be considered before moving to cloud. This gives a glimpse of what is needed, but do not be discouraged: the benefits are tenfold. Moving to the cloud is no longer being ahead but riding the wave; and not being in the cloud soon will certainly mean falling behind.