Yes, we did it

I will not be able to share the details here because, you know, usually it reads CONFIDENTIAL on that Excel, Confluence space, E-Mail, etc. but I would like to share with you how a cloud migration can keep you busy for ca. 5 months.

This journey started right after the summer of last year. I finalized the documentation about the environment I am responsible for, and then I had to answer a lot of questions, mostly coming from our dedicated IT Architect. The poor guy was assigned the task to support us in moving our fairly complex system not designed for the cloud at all, to the cloud.

A lot of patience was required for the process of knowledge sharing: I learned that only precise and concise statements should be made, especially when you are creating a document that will be evaluated by many different people and from many different aspects. I knew this already but this process made it clearer. And never underestimate your IT Security: those will be some very pesky questions and you will need to have an answer, a bulletproof answer if possible.

After the Architecture Board approved the design and gave us the green light the dance started. We were September. Provisioning the infrastructure in the cloud, after the order was placed, took roughly between 2 and 3 weeks. When October arrived, together with my IT counterpart, we started observing that something was not going as expected: on the provisioning end, something was not moving at the pace we were expecting. The first problem to solve: establish your ways of working. You may wonder why I did not start doing that earlier and the answer is: according to the migration program we were part of, we were not supposed to. In the end, we had to find a way to fill this gap, and we had to do that fast, like really fast.

A Jira board came in handy: your dear one started to create a useful number of user stories at night so that the morning after the stage would be set. It was early November and only then wheels started spinning as expected. We decided to go for 1-week sprints. And we kept that approach in the end. For a fast-moving project, this was a very good idea. I don't regret it. When I published this, I was exactly at that point.

In the following months, I learned a lot about cloud services, user management, data transfers, database setup, database dumps, network connectivity, network security, SELinux (!), logging, and, most importantly, how to write proper Jira tickets to ensure that who was on the receiving hand, had no doubts about the actions required. We had a couple of surprises, the most interesting one was the NFS system performance (NFS stands for Network File Sharing): high level, this approach enables two or more users to read the same word, on the same page, on the same book at the same time. This item has to be fast, reliable, and stable. I learned, the hard way, that in the cloud NFS performance increases only proportionally to the NFS size. And some NFSs are better than others... Translated a small NFS will be slower than a big NFS. If your application leverages the NFS a lot, the outcome of bad NFS sizing could be a general performance decrease of your entire application. For example: what was loaded in 3 seconds before, will now be loaded in your cloud environment in 30 seconds if not more. Testing came in handy and after a few iterations, we found a balance, although a very expensive one (the web is filled with horror stories of hefty cloud bills, right?!). After resizing the NFS properly, we took a step back and decided to reassess the entire fleet of VMs, bad timing but the right decision. And this was February.

Putting aside several other technical challenges we had to deal with, the deadline was coming closer. At that point, my manager taught me a very important lesson: owning the timeline. With his crucial help, we devised a simple and clear timeline and shared it with the stakeholders. I negotiated their approval and we had a path to follow for the conclusion of the project. To be fair: a timeline was created initially but after the mayhem in November and the recurring surprises we could not really stick to it. This revised one made a lot of sense, especially because it was based on the learnings we got along the way.

April arrived, a few days of early spring as well. We prepped up for the cutover. Despite one small unexpected surprise, the cutover was smooth and took place inside the designated time window. Here I am, a few weeks later, writing about what is currently considered a success. With the help of everybody involved, we migrated an entire environment to the cloud: you may say we could have been faster, and most likely you are right. I could have started creating Jiras earlier, I could have devised a new timeline earlier. In hindsight, a lot of things could have been accomplished earlier and better but it went this way.

I am happy now because certain calculation-heavy tasks run between 30% and 40% faster, applications load faster, business processes can be closed earlier (40 mins instead of 2 hours and something), because we have one less useless virtualization layer and because users did not complain after the cutover. I learned a lot more about Linux and the cloud, and what a migration project entails. I had to nudge a lot, write a lot, speak a lot, but it was worth it.

The outcome is tangible and every business user appreciates it. Time for an Apero?!