Migrating to Cloud: 8 learnings

BurdaForward has come a long way when it comes to our infrastructure. Starting with our own on-premise servers in 2005, then switching to a dual data center provider 10 years later and finally arriving in a “real” cloud setup in 2021. What sounds like a smooth transition and logical evolution, did not always feel that smooth. If you have done a cloud migration yourself, you might recognize your own experiences in the next few paragraphs. If you haven’t done a cloud migration but are planning to do so, you can take these learnings to make your own project run (even) smoother than ours. And if you’re planning to stay on-prem, you can joyfully laugh at my 10 learnings, knowing you won’t have to deal with them for now.

It all started with Techies playing Lego…

Seriously, we did Lego Serious Play. At our annual BurdaForward Tech Conference in the fall of 2018, the Operations Team asked developers and product owners, to illustrate what technical setup and work environment they are dreaming of – using the colorful play bricks. They built Lego artwork showcasing beautiful playgrounds with flowers and fences, illustrating they want to create, play and explore freely and creatively, whilst being safe (the fence!) and keeping strangers out. 

As our setup in 2018 did not allow any sort of playground nor granular account permissions, we started dreaming of a world where this would be achievable – we started dreaming of “the real cloud”. And we decided to go for it, in particular for AWS (for various reasons which I might talk about in another article). 

So, what was the scope of our Cloud Migration Project? 

 The scope of our project was to migrate 25 products - many of them end-user-facing – from the dual data center to AWS cloud. These products consisted of 300 technical services, some of them shared amongst the applications. These services were running on 865 servers in the dual data center. 

 Our goal was to completely escape the data center and thus, our contract with the current provider, before the 30^th of September 2021. We did not quite make it, but luckily our provider was nice and let the servers run for another month. 

Key Facts summarized: 

• 25 products, 300 services on 865 virtual servers 
• Timeline: May 2020 – October 2021 
• Involved people: 1,5 Project Managers, 15 Product Owners, approx. 40 Developers, 12 Operators, 3 consultants, 1 x AWS Professional Services 

And now - finally – my top 8 learnings about cloud migrations

1. The what, why and how need to be understood by EVERYONE in the company 

Why is that so, when mostly developers, product owners and operators are involved? That is because the rest of the company’s feature requests will need to wait – sometimes for a loooong while. You cannot do a large-scale-migration AND develop several new features in every sprint, especially when you also need to deal with some bugs.

2. You need high level management buy-in 

If the C-suite doesn’t have your back, it will be hard convincing some of the product owners to work less on creating new product features and spending more time to do background work. If the C-suite is not convinced the move to cloud is worth it, why should anyone else be? And a tip on how to get the high level management’s buy-in: Present numbers. What are the total cost of operation at the moment and what will they be like in the future? In our case, cloud was a bit cheaper and with the possibility to optimize it even more. And that cost advantage came along with many more, such as the possibility to scale, make costs transparent and manage users and identities on a granular level.

3. It is not just a technical shift, it is a shift in mindset 

“You build it, you run it” must be understood by everyone involved. Otherwise, your Ops team will end up with a lot of applications they need to run without having any closer knowledge of them. With the freedom for developers, there comes the responsibility. 

4. Without an owner, nobody will make a move 

As mentioned in 1, migration work will need to be prioritized in the teams’ sprints at some point. But before that comes a hidden piece of work: Identify which resources belong to which team. There might be some servers running and applications making money, but nobody feels accountable for it. Of course, this didn’t happen to us ;) 

5. Defining a migration strategy is key 

It is crucial to define a migration strategy for each technical service in the beginning of each migration project. Why? Because it will determine the actual stories in the sprint and the timeline. If rehosting is possible, the work is the migration itself. If an application needs to be refactored to be able to run in a cloud environment, there is a lot of prep work involved. 

To learn more about migration strategies, check out this page.

6. This is a fulltime job 

For many people! Our 10 FTE Operations team worked on it approximately 60% of their work time, so all in all 6 FTEs were needed to perform the migration. And that only from the Ops department. Countless Epics and stories were worked on in the Development teams, the CTO and Pos met for regular stakeholder rounds and there was an external consultant involved part-time to facilitate. 

7. A hard deadline really helps but to reveal your contingency is to lose your contingency. 

For our migration project, we had a hard deadline: That was the end of our contract with our then-provider. And this was really helpful to keep everyone’s focus on the migrations. However, the deadline we communicated was 3 months before the actual deadline that was still kept a secret. When it turned out we wouldn’t make it before the “fake” deadline, we were able to calm everybody down by revealing the actual deadline which was still 3 months away. What a relief! But: If we had communicated the actual deadline from the start, we probably would have ended up in the same situation . without having 3 months of additional contingency. 

8. You’re not done when your servers are shut down…. 

In the end, it all ended well! Or did it? Not yet! Because the migration is NOT done when the servers are shut down. There are 4 steps to a cloud migration: Plan, Prepare, Migrate, Optimize. And to be honest: Optimizing never really ends, does it? New possibilities come along all the time, possibilities to save money, possibilities to make your application more performant or resilient – which is the EXACT reason we love our job in tech!