Moving “” Legacy to Modern Cloud in a Single Night


Imagine completely shutting down a website like Sound scary? It is – and yet the team had to do just that to move their website to the cloud.

Paweł Szczepaniak, Principal System Engineer for General Marketplaces at SMG, talked about their biggest legacy to cloud migration project yet and how it all turned out great!

The Cloud is the Limit had been renting a rack in the Zurich data centre, but the hardware was getting quite old. In addition, their setup was reaching some of its limits. During peak traffic, the internal network was saturated, so they knew it was time for a new and improved solution. The goal was to move to the cloud and, by doing so, fully automate management of the infrastructure. This migration would reduce the risk of hardware failure, as well as ensure documentation and automation to mitigate potential problems. With AWS scalability, future growth concerns are alleviated as increased traffic and load can be managed with flexibility. How to go about an intense migration project like that?

Understanding Legacy

To be able to tackle this project, the team needed to understand the legacy infrastructure. So what does legacy mean?

By legacy, we mean outdated computing soft- and/or hardware that is still being used. The system still works and fulfils the function it was designed for however, it limits or disables growth.

Since the code had been written more than 10 years ago, there were a lot of unknowns. The specifics of its operation and the settings they managed were crucial. More importantly, adapting it for cloud migration was essential, as these dynamics were previously unconsidered. Back then, the absence of cloud or microservices concepts led to insufficient flexibility required for cloud operations. This difference in technologies also made testing incredibly important and very challenging. Juggling new setup creation, existing infrastructure maintenance, and cloud migration within a short span posed considerable challenges. This task was made easier thanks to the initial automation of everything.

The Big Move

The team’s uncertainty about on-premise duration led to time pressure. This drove them to migrate production first, then address testing. Ultimately, it helped keep the most important environment – production – fully operational and ready for the increased traffic.

The migration process started at 11 pm when traffic is usually at its lowest. That way could be fully shut down. The expectation was to be back live at 8 am the next morning. However, things went better than expected, and shortly after 5 am, the site was back online. During the day, there were some minor functionality issues that were easily resolved, but none of the critical features had any issues so the migration was a complete success.

Test, Test, Test

This probably goes without saying, but testing is always the way to go with any new feature, especially a new infrastructure. If you think you’ve tested it enough, test it again. It sounds a bit boring, but more bugs will always come up, and it’s better to find them and fix them before any releases. Almost all setups are so complex that anyone can miss a detail, but at least you will have caught as many as you could beforehand.

Test. Then test it again. Then again.

Another thing Paweł emphasised was the importance of documentation. It is a valuable exercise to completely shut down (or partially in some instances) before going live to see what happens and document all the processes that are not automated. This type of documentation will help save a lot of time and resources in the long run.

And to end this successful migration of from legacy to the cloud, Paweł’s most important piece of advice: “If you’re under time pressure and feel confident that it will work – go for it. Even if you work from 11 pm and it’s 5 am. You have more time to fix bugs before the majority of users will come onto the site”.

Latest Blog Posts

Fotos vom Management mit und ohne Hintergrundfarbe als ZIP-Datei

Logo zum Download in allen Versionen