Calculate and run a Flutter migration project
Developing mobile apps with Flutter is a good choice for most projects that start from the scratch. But what about companies that are already run native apps? Does it make sense to migrate them to Flutter? How much would the migration costs be and how much can you save afterwards? We would like to share some insights from our past projects and give you answers to the above questions.
Determining the migration cost and amortization period of such an investment depends on many factors, such as the characteristics of your native code, your business situation, and your project setup. The more information you have, the more accurate your estimate will be. But what if you need to give a quick answer? Imagine you are standing in the elevator with your CTO, only 2 floors to go, and he wants to know the migration costs and the expected payback time of this investment? In this case, the best possible answer is that the cost is 40% of the effort it took to build a native app, and that this investment will pay off in 2 years.
40% and 2 years is a blind estimate, a starting point that will never be the final result, but a good point to start calculating. Based on this assumption, we will look at the three most important factors for migration costs:
1) How best to rewrite the code?
The most efficient and probably only viable way to migrate native apps to Flutter is to write new code in Dart. This may sound like it is super inefficient, but it’s actually the opposite. If your native source code is in good shape, well-structured, and sufficiently enriched with in-code documentation, rewriting the code will only take a small fraction of the time that was originally spent creating the first version of the code.
When calculating the initial effort, consider the effort for your first release and add the sum of all efforts for change requests. Typical maintenance efforts like updates should not be considered. If you rely on many external libraries or SDKs, you should add an additional effort to your calculation. On the other hand, you can reduce the estimated migration effort if you run large parts of your business logic on your back-end server.
I do not want to list all the factors for increasing or decreasing your initial blind estimate. We have put all of our experience into an online calculator. With our “Flutter Migration Cost Calculator” we have created a small online tool that helps you to make an initial estimate of the expected migration costs and realizable cost savings.
2) Consider your business situation
While the characteristics of your native code determine the migration cost, the main factor to calculate the amortization period is your business situation. Let us start with the assumption that you plan to run your business as usual for the next 1–2 years.
In this case, migrating your two native apps to a single code base will reduce your maintenance costs by almost half, since there is only one code to maintain and test, and your support unit also only needs to be trained on one code. So, your estimated cost savings are about half of what it costs to run your two native apps today. Your payback period can be easily calculated by dividing your migration effort by your monthly cost savings.
If you are planning major changes to your apps, the situation changes significantly. Migrating to Flutter while implementing your changes increases your potential cost savings, as you will not only save half of your future maintenance costs, but also half of the development costs for your planned changes. If you plan to change your native app code by about 1/3, then your migration to Flutter would pay for itself immediately.
3) Optimize your project set-up
If your previous calculations have shown that a flutter migration could be a good business case, there are still many things you can do to screw it up or outperform. Here is a short list that can help you avoid the biggest mistakes:
Mixed development teams:
The smoothest migration projects we have seen have been those where 50% of the developers came from the client’s existing iOS and Android development team and 50% were Flutter experts that we provided for the project. Having the native app creators on board accelerates the project because they know the code that needs to be migrated in and out. Combining this with external Flutter expertise will speed up development and provide a steep learning curve for the former native developers. This is critical as they will most likely be the ones maintaining the new Dart code once the project is complete.
Do a planning sprint up front:
Even if it is a minor violation of pure SCRUM principles, start with an architecture and planning sprint. List all the features and epics you will migrate in a chronological migration timeline. The main criterion for prioritizing the feature and epic list is that there are no, or as few as possible, dependencies from anything you do to anything you will do in the future. Forward dependencies should be avoided on both sides, technology, and business. That is why this sprint requires a lot of involvement from the business owner of the project. In most cases, this leads to starting with the security items and working forward from there.
Continuously delivery and testing:
Even though you are sticking to your existing code, you are producing brand-new code and brand-new bugs. To do this, do not underestimate the amount of testing you will need to do. Ideally, include crowd testing from the beginning. Keep your sprint cycles short, no longer than 2 weeks, and have real users testing all the time.
I hope I was able to answer some questions and give you some insight into this exciting topic. I would be happy if we all can expand the Flutter universe by migrating more existing apps out there to this platform.
