Five hacks for a successful cloud migration

Do you know a team that takes a very long time to complete its cloud journey? Well, it doesn’t have to be that way. When deciding to move to the cloud there are a few steps to take that can be summarized under the following stages: Planning, building, and finally managing the cloud. Of course, there are organizational and technical challenges that come with a cloud journey making it a complex undertaking per se. In this blog post, we look at 5 pitfalls that you can avoid in your cloud journey and explain how not to add additional obstacles to your journey.

1) Not Focusing on a Working MVP

The concept of the Minimum Viable Product (MVP) has been popularized by the Lean Startup movement. The MVP is characterized by being a version of a product with just enough features so that it can be used. That way, you can learn about customer behavior right away, verify early on whether requirements are being met, and iterate on the feedback until your MVP has turned into the perfect solution.

Why am I telling you about this? We can take that same approach and apply it to our cloud journey. Getting a minimal version of the project up and running in the cloud and iterating from there. This approach allows us to address the riskiest assumptions and biggest challenges first. By doing so, we reduce the overall project risk keeping the feedback cycle as short as possible to pivot and adapt based on the feedback we get.

The hard thing about MVPs is to prevent bloating up the MVP. It needs to be minimal, while the ultimate goal is to learn and iterate enabling a final version that meets all needs. However, the MVP is not about neglecting quality or proper engineering, but the bias needs to be towards making decisions and taking actions when we see they are necessary instead of overcomplicating the subject matter, researching, and planning everything while relying on assumptions.

Here are some practical tips on how you can detect this cloud pitfall:

• The MVP is taking too long to build. Instead, strip out features and reduce the scope based on analytics data or user feedback.

• It is taking too long to implement changes. Focus on improving the time-to-market. Decrease the cycle time by improving the CI/CD automation so you can run through the learning cycle more often.

• No one can see the MVP. An MVP needs to have a public URL. You need to be able to expose your MVP so others can see and use it. Only this step allows you to further improve it.

2) Not Enough Knowledge in the Team

Knowledge about the cloud is key to a successful cloud journey. But what do you do if your team is not experienced with cloud technologies? Obviously, you could hire people with cloud experience, but that won’t solve the problem either as they on the other hand do not have experience with your project.

Acquiring knowledge is never a quick fix. This is more of a cultural topic. The team needs to be fully enabled and know how the cloud and systems work. My advice: Don´t think of the project as a team with a rockstar engineer at the top doing all the magic, but as a team that only together can perform as the rock band 😉

How to make this possible? To make learning part of your culture there are several ways to establish an inspiring and prospering work environment.

One idea is to establish a regular knowledge-sharing session where someone on the team who has been working on a specific topic shares insights with the rest of the team and enables them. The output of these sessions can also be used to onboard new colleagues in the future.

Another possibility is to implement pair programming as a great way to transfer knowledge within the team. Next to that, pairing is a good way to tackle complex challenges as it helps to foster the discussion of the challenges at hand as well as their solutions. Just the right thing for our cloud journey.

Here are some practical tips on how you can detect this cloud pitfall:

• Certain topics are always done by the same person. If certain topics such as testing or monitoring are always done by the same person add some form of knowledge sharing to get rid of the bottleneck.

• The team is cautious. If the team proceeds with caution this could be due to a lack of knowledge (could also have other causes, e.g. cultural issues).

• Ask the team. The team knows where it needs more knowledge. As a team, you can define the most important skill and experience gaps that need to be filled. Ideally, you record your findings in a skill matrix.

3) Short-Term Focus

In the first section of this post we’ve been talking about MVPs and now I’m saying that short-term focus is a pitfall? Well, yes and they actually go together.

Imagine you buy a consultant rock star engineer that helps you complete the journey to the cloud. And the goal is, that the journey is completed within 6 months when the contract with the consultant ends.

Guess what is going to happen? If time gets tight and the consultant needs to choose between building a proper long-term solution or taking a quick path to finish the job with success, then it is pretty clear how the consultant will decide.

And this discrepancy is exactly what needs to be taken care of – there might be individuals in a team that have varying goals driving the project in a way that is not sustainable.

How can you decrease the risk of individual team members weighing their personal goals higher than the teams' goals? Make sure everyone in the team is invested in two goals:

1. Completing the cloud journey as soon as possible

2. Ensuring that the solution has a high degree of maintainability and changeability.

When working with external suppliers you can improve this by seeking longer-term partnerships to help with a cloud journey.

Here are some practical tips on how you can detect this cloud pitfall:

• The number of identified technical debt topics increases. If you don’t track technical debt within the team, you should start tracking technical debt in the first place. And then, keep a close eye that the pile of debt doesn’t increase. If it increases, seek the conversation on how this was possible to avoid increasing the pile.

• The team often disagrees when making decisions. Certainly, diverse culture and open discussions help. But if it becomes hard making decisions see if the individual goals of the team members do not align.

• Some team members are overly pushy. A team only works well if all team members work on equal footing. If some team members are overly pushing their opinions and decisions it defeats long-term commitment and ownership.

4) Making things work in the cloud by all means

Not all software on this planet has been designed and built to be moved to the cloud. Oftentimes, following the cloud strategy of an organization, all workloads need to be moved to the cloud to eventually shutdown on-premises operations.

This leads to the fact that teams often prefer a lift & shift approach to their cloud journey to quickly move workloads to the cloud and then improve from there. However, often this leads to cloud journeys taking the problems of on-premises applications and adding the challenges of the cloud on top of that.

For example, an application requiring access to a file system is not a great candidate for rehosting on the cloud, but rather to rearchitect and rebuild the service right from the beginning to leverage the cloud´s capabilities.

Here are some practical tips on how you can detect this cloud pitfall:

• You require file systems in the cloud. File systems cause a lot of trouble when it comes to high availability and scalability. If this is not your concern and you can live with downtimes, go ahead with file systems. Otherwise, rearchitect and rebuild.

• You need to containerize off-the-shelf software yourself. Seriously, if the vendor does not provide a cloud-ready version of the software just do not try to containerize the application and run it in the cloud – simply rearchitect and choose another vendor.

• You don’t want to touch the application code. In a cloud platform, you need to design for failure and applications need to be resilient for various failures. It is very unlikely that an application not written for the cloud has these qualities built-in, so improving the existing application code will allow the cloud journey to end smoother.

5) Dependencies to on-premises systems

A component rarely has no connection to other systems. When moving to the cloud, those other systems are often not yet there. This leads to engineering teams spending time to bridge the gap between on-premises systems and their application now running on a cloud platform, either temporarily or permanently.

Bridging this gap can involve quite an amount of work, as it forces engineers to set up and maintain a network connection to an on-premises data center, where usually the team itself cannot change the networking setup. Thus, the VPN tunnels, certificates, technical users and all other technical details need to be set up and maintained together with the on-premises IT operations team.

Also, while centralized certificate and DNS management have worked well in on-premises systems, they do not work as well in cloud systems. But oftentimes, the central IT operations team continues their processes for the traditional data center management and teams bringing solutions to the cloud need to work with slow and manual processes to get their applications up and running.

Here are some practical tips on how you can detect this cloud pitfall:

• Your team spends a lot of time dealing with on-premises topics. You want to build a solution for the cloud. If the majority of engineering power is spent on dealing with on-premises topics, then it is often a better idea to rearchitect the application to rely less on on-premises services.

• Your team cannot use self-service. In a proper cloud set up teams can use self-services to move fast and build the solutions they want. If teams encounter a lot of non-self-service processes, there is a huge potential to streamline these processes using platform teams.

Conclusion

When starting out with a cloud journey there are a lot of pitfalls to avoid, so that teams can deliver results quickly and build sustainable solutions. In a lot of cases, it does not make sense to follow a lift & shift approach to the cloud journey, but to rather rearchitect and rebuild a solution to be cloud-native right from the beginning. Doing so can greatly speed up a development team, given a knowledge sharing culture is in place so the team can iterate and improve on its own.