Knowledge Transfer and AWS Migration in less than a year – a success

Some of you may say it cannot be done, some would say it depends. In GFT we know nothing is impossible, as it is all about the people, their courage, commitment, creativity and the way they collaborate and care for each other. Today, I have the pleasure to share with you the story of the wonderful development teams that not only took over the six complex applications but also migrated them into AWS cloud, and all of that in less than a year. 

Project Background 

It all started when our client decided to sell one its companies that were part of its group. The separation was scoped to be done in a number of parallel workflows, one of which included IT processes, development and maintenance review and changes. It was discovered that a large part of the IT processes were maintained by the development teams from the company being sold and needed to be transitioned before the official split. The Client decided to ask for support from an IT company that specializes in the financial sector. This is where GFT came into the picture. 

Knowledge Transfer 

I took charge of the development teams in February, at the start of the project. We were introduced to the existing teams and it was decided that for the first phase of the project we would map the teams one-to-one to ease the handover process. There were a lot of challenges ahead, firstly we needed to organize Knowledge Transfer and communication with the client. In GFT we have a process called “Sprint 0”, which is all about how to start new projects with new clients. It covers all areas: roles and responsibilities, tools (access rights) and scope (backlog of things to be done). I decided to accommodate this process for Knowledge Transfer needs. You can find the details of Sprint 0 process in KT project on my previous blog note here

As we created Knowledge Transfer Plans, I had the idea of organizing tech families within the project so that people gained the knowledge together and helped each other with understanding more complex solutions. Additionally, it was beneficial for people that were alone on their technology within scrum team (e.g. we had only one Angular specialist to cover 2 applications in one of the pods). The families were: 

  • Front-End Family led by Cezary Średnicki,
  • Back-end (Java) Family led by Andrzej Kawecki later Michał Sobański,
  • Drupal Family led by Cezary Średnicki later Michał Hieronimczuk
  • DevOps Family led by Oluwasegun Ikuesan
  • QA’s led by Stanisław Rosada
  • BA’s led by Krzysztof Kolat.

All families followed the same KT process containing the steps: 

  • KT sessions – scheduled meetings between old and new teams to share knowledge, present the applications, code and solutions.
  • Required Documentation KT Shared – old team prepares and shares technical documentation.
  • Required Documentation KT Satisfied – new team reviews and approves documentation. Project Families organizes meetings, reviews shared documentation, prepares questions to help fill the gaps.
  • Shadow Delivery – old team working on the delivery with new team overviewing their work by meeting and discussing current tasks, doing code review, helping with finding and proposing solutions, in this phase developers from new team also working on local environment set-up.
  • Hands On Experience – and finally, the new development team starts working on new functionalities with support from old teams, asking new teams additional questions, the old team doing code review and pointing to key details.
  • GFT development – new teams working on development and production support on their own, old teams no longer have access to tools and infrastructure.

Each of the Family leads were given the responsibility to check and update detailed KT Plans as well as to overview the family KT sessions. As part of this it was decided to not only check and update technical documentation but also record all training sessions with the handing-over teams. Materials prepared as a part of the KT process are still used during new joiners onboarding. 

AWS Migration 

As Knowledge Transfer ended on 1st April 2021, we moved to the next project phase – Separation Program. The client’s main application consists of two parts: front-end and CMS set on AWS and data layer (backend and database) hosted on on-premises infrastructure of the company that had been sold. What is more, backend and database were shared between our client and sold company main websites. The goal of this project phase was to split common parts and migrate our clients code to AWS. 

Firstly, Javier Saez (Separation Project Manager) together with Marcin Szymczak (Project Architect) started analyzing the scope of work and preparing the plan for Migration activities. When the plan was ready development teams started to work on detailed runbooks for each activity. In this phase we decided it would be good to assign a tech lead who could monitor the quality and consistency of the runbooks. Michał Sobański took up the role and started reviewing prepared plans and manuals. In the meantime, the new infrastructure was set up by the devOps team. They created a new AWS instance, added new pipeline builds to Jenkins and deployed the current application version on new infrastructure. We co-operated with client network and L1/L2 support teams to troubleshoot arising issues. 

Then, the testing started. In the first phase we wanted to make sure that after switching the application will work correctly. Our QA’s led by Stanisław Rosada created detailed tests plans and started execution. The biggest challenge for this phase was that the new set up only contained the data layer (database and backend API) and did not have any front-end to be tested. QAs prepared a set of automated API tests and performed database validations. We also needed to make sure that performance was not affected, and as we work in the financial sector, we also needed to cover for security pen testing.  

The final part before Go Live was two weeks of parallel runs. During this time, all of the business-related activities were run on both old and new backend and results compared. Thanks to this activity we were able to confirm the new backend working as expected. We went live on 23rd September. It was a busy weekend; the team has worked long hours over the weekend. Thanks to great dedication of the team members, we managed to finish all activities, migration was approved by the client and the application was up and running in time for the opening markets on Monday morning. 

What future brings 

The team is now past two difficult and demanding project phases, still we do have a lot to do. Currently, we are focused on the delivery of new functionalities and Tooling Migrations. In the meantime, the team prepared Quality Assessment and that was shared and discussed with the client. 

Tooling Migration 

As I mentioned at the beginning, our client sold one of the companies being the part of group, which as you can imagine they owned some of the tool’s licenses. Due to that there was a need to set up new tooling instances and migrate these and their settings and data required to continue delivery. The delivery team is a part of this process. We ran tests on the new Jira instance to ensure we have all the required data and checked on migrated testing tools. DevOps working on moving CI/CD pipelines to new Jenkins. The team has already progressed with this backlog and plans to finish by the end of January. 

Quality Assessment 

Every time GFT takes over an existing project, we do Quality Assessment. For this purpose, the team runs analysis on the provided solutions, we evaluate the security (password encryption, GDPR, data protection etc.), technologies used (if those still supported), quality gates and delivery process (static code analysis, automated tests coverage, CI/CD pipelines, deploy and release processes). As a result, a report is created, which is later shared and discussed with the client. The team has already passed through those checks and is now together with the client prioritizing and adding actions to the backlog. 

We have been working on the project for a year now. There is a lot that the team achieved during this period and still lots of to be done. We learn from our experience and continue to improve the way we work as well as the quality of delivered products. We also find time to have some fun. We had a celebration party and continue to meet with the team regularly on GFT Happy Hours. It is great to be a part of this team! 

Special thanks 

When we started this project, we were nothing more than a bunch of people from different teams, with different skillsets, backgrounds and histories. And I could not be prouder than to be a part of this adventure, since we have all become one team with one goal, as we developed ourselves, supported each other and delivered successfully.  

For all the demanding work on KT and AWS Migration thanks to all the people involved: 

Project Governance:  

  1. Project Managers: Javier Saez, Dominika Bacik, Iain Kenny, Krishna Trivedi
  2. Project Architects: Marcin Szymczak, Maciej Nowicki, Marcin Radzki
  3. Project Technical Leads: Michał Sobański, Oluwasegun Ikuesan, Andrzej Kawecki
  4. DEM: Marcin Oleksiewicz
  5. Program Manager: Paul Bay

Delivery teams:  

  1. Scrum Masters: Ewelina Ruda, Adam Tomaszewski
  2. BAs: Aleksandra Zakarczemna, Krzysztof Kolat
  3. Front-end developers: Cezary Średnicki, Marcin Kolibabka, Anna Oruba, Konrad Dzikowski
  4. Back-end developers (Java): Michał Sobański, Robert Baran, Łukasz Buczny, Andrzej Kawecki, Marek Ćwirko
  5. Back-end developers (Drupal): Michał Hieronimczuk, Artur Wójcik, Błażej Owczarczyk
  6. QAs: Stanisław Rosada, Daniel Dragan, Piotr Maciej Kozak
  7. DevOps: Patrycjusz Czerniga, Robert Matuszewski, Colin Leek, Mohammad Moradi,  Salar Nasiri, Marcin Tomiec, Mykola Kolchenko, Paula Durasik, Szymon Koziarski
  8. DBAs: Tomasz Lesiński, Łukasz Samelak, Andrzej Sobczak