Introduction

In the fast-paced world of mobile app development, staying competitive and up-to-date with the latest technologies is crucial. However, migrating a mobile application from Xamarin to Flutter is no small task, especially when dealing with a substantial app with over 100 screens, a presence in more than 12 countries, and a user base of over 3 million people. In this blog post, we will dive into the human aspects of this migration journey, focusing on the challenges and successes that come with it.

If you are interested about the technical aspects or the reasons why we did it of this migration, you can read more about this in the tale of the tech side.

Crafting a migration plan

The decision to rewrite the application was not made lightly. It was part of a plan made for all applications in the company. Our application, was the third to embark on the Flutter journey.

The first step was to create a detailed migration plan that addressed not only the technical aspects but also the human factors. It was clear from the start that this was not going to be a quick and easy transition. The initial estimates suggested it would take more than six months to complete.

We decided early on that we would train the existing Xamarin developer team to Flutter and that they would be the ones working on the migration. Indeed, when a team has been working on an app for 4 years, the actual asset is not the code, but their knowledge of the product. Even more so when code is the documentation.

Everyone had the option to either switch to Flutter or remain in .NET and join different teams for backend development.

One of the key objectives was to finish the migration as soon as possible while retaining the ability to make modifications in Xamarin for a certain period. This approach was taken to minimise disruptions and allow for a gradual transition. The strategy, however, presented its own set of challenges, mainly delays.

Initial skepticism

Kübler_Ross's stages of grief

One of the challenges faced during the migration was the initial skepticism from the team. Many developers felt less productive with Flutter compared to Xamarin for quite some time, which is understandable when transitioning to a new framework. Change can be challenging, and learning Flutter was harder than expected.

We assured the team about our understanding of this situation and that things would improve as we became more familiar with it.

Learning the Flutter Way

With more than ten developers split into two squads, it was essential to get everyone up to speed with Flutter and to familiarise themselves with this technology that was new to most. Learning a new framework takes time, and it is not always smooth sailing but we were convinced that the best way of learning anything is actually doing it.

The teams were given the ability to spend a development sprint to experiment with Flutter and build their knowledge.

In addition to this, a trainer was brought in after that sprint, and a customised training program was designed to facilitate a smoother transition.

Learning curve

Several developers faced unexpected difficulties when learning Flutter’s development approach. Switching to a completely different framework understandably takes time and difficulties can happen any time during the development especially since we work on complex features.

We were confident the squads would adapt quickly, but it turned out to be more challenging than expected.

Acknowledging these challenges and offering support is crucial in such migrations.

Adapting to delays

The migration did not go as smoothly as expected. The squads found themselves spending more time working on Xamarin than originally anticipated. Even though it was necessary to ensure that essential updates and fixes could still be made to the existing application, it caused noticeable delays.

We had to temporarily hire a squad of experienced developers to address the delays. Given the application’s complexity and the time required to get new developers up to speed, this hiring would only yield benefits if they stayed with us for a couple of months. This choice was made in coordination with the business team when it became evident that the advantages outweighed the associated costs.

Despite their experience in Flutter, this team help was limited to their understanding of our industry, confirming the initial assumption that the team is the asset.

Conclusion

Migrating a mobile application from Xamarin to Flutter is a complex process that involves not just technical challenges but also significant human aspects. It was a transformation that required adaptability and commitment from the developer team.

Managing a large-scale migration like this also requires careful planning, continuous training, and patience.

While the initial skepticism to Flutter and the unforeseen delays posed challenges, the team eventually embraced the new technology and overcame obstacles through dedicated training and perseverance.

This migration highlights the importance of acknowledging and addressing the human factors involved in such transitions, and how these factors can ultimately influence the success of the project.

The team successfully accomplished a challenging task by rewriting a complex, finance-oriented application with over 100 screens that was more than 4 years old in just about 7 months. They switched to Flutter and followed strict development standards. Their Flutter skills now match their previous expertise in Xamarin. As the team continues to learn and improve with Flutter, they will tackle more challenges and gain valuable skills for their future projects, in addition to creating an excellent application.

If I had to undergo a similar migration in the future, would I take a different approach? Probably yes, and I would ensure that everyone knows about the Kübler-Ross’s grief cycle in order to better accompany the change. Additionally, I would certainly give stronger consideration to bringing in an additional team early on to either maintain the old app or initiate the new one but ultimately this comes down to budget considerations.

For sure something I would do the same way is trusting the existing team.

Comments