How to advocate for Kotlin migration + sample migration process

So, you’ve decided you want to convert your app to Kotlin! If you still haven’t decided, I suggest you take a look at my previous article. Now let’s discuss the next step: how to convince your team and your company to do a Kotlin migration? In this article, we will discuss the questions that may come up when you propose Kotlin Migration to your team, how to answer them, and a step by step migration process that may help your team convert your app in a smooth, bug-free way.

Questions to Consider

1. How will converting / writing in Kotlin affect developer velocity?

This is a valid concern for developers, product, and project managers. If you’re working in Kotlin, will you be able to release features on time? You could advocate for tech debt time to do the migration, but not every team has a lot of time allocated for technical debt.

As with any language, there is a learning curve. But in my experience, the more exposure developer has to Kotlin, the faster they will become at developing in Kotlin. Kotlin is a more efficient language to use. According to the Kotlin FAQ, on average, developing in Kotlin means having to write 40% less code to do the same feature! Be more efficient and effective!

If you need to figure out how long it will take to convert a class to Kotlin, adjust per the developer’s strength in Kotlin. For a small class and an experienced Android developer that’s new to Kotlin, the conversion of the class should take about 2 days, with an extra day allowed to write a unit test in Kotlin. Speed increases exponentially from there. For a small class an an Android developer experienced in Kotlin, conversion can take a couple hours, including adding unit tests.

2. How will this improve the product?

As developers, we don’t want to be adding new languages just for kicks—we want to show some real improvement! There are many ways Kotlin can improve your product. Consider the number of null pointer exceptions your app runs into. Kotlin’s null safety and robust APIs can get rid of those bugs entirely. Imagine how much better your product could be without that whole class of pesky bugs! Even if you just improve your developer velocity with the cleaner, more concise language Kotlin provides, you’re still improving your product. You can use that saved time to write more features, tackle technical debt, or look into new Kotlin libraries that can make your product even better! 

3. How can we spread information about Kotlin throughout the team?

Perhaps not all of your team is experienced in Kotlin as a language. How do you get everyone up to speed? Taking a phased approach to migration to Kotlin can help with this, and allow team members time to dip their toes into the language. I would also suggest creating a series of brown bag sessions for developers to better understand the benefits of the language and its features. An internal Slack channel can also be helpful for spreading knowledge about the language, talking through issues, and getting help from your community.

4. How can we prevent bugs?

A developer’s worst nightmare is adding a new language, and then having it cause crashes in production because of what you changed. You can mitigate this by making your Kotlin migration changes on feature branches, and then having your QA team acceptance test your app off those branches before you merge them in. It is also highly recommended that you try to unit test those classes that you do convert as much as possible.

Process of Kotlin Migration

Not everyone has the luxury of doing a total refactor of their code. If you want to do a phased approach, you can do the migration changes in smaller steps:  allowing your team time to increase their confidence in Kotlin, while allowing you to migrate without affecting team velocity, continuing regular feature work as you do the migration.

The goal of this process is 100% Kotlin migration.

Starting at Phase 1, the requirements to complete each phase are:

  • Unit tests written for each class converted to Kotlin (if possible)
    • This will not only help bug-proof your code in case the Kotlin migration broke something, but it will also improve your code coverage. (Yay!)
  • Team buy-in (developer confidence in Kotlin)
    • Your team must agree to move onto the next phase. This helps the entire team to gain confidence in the whole migration since you won’t be moving to the next phase until the whole team agrees to do so.
  •  % Kotlin conversion
    • This is for tracking your progress and is helpful for a demo of your progress. I suggest you create a script that can count the number of Kotlin files vs. the number of Java files.
  • Number of null pointer bugs
    • This metric is helpful for tracking Kotlin’s improvement for your app in terms of stamping out production bugs
  •  Number of bugs created by conversion
    • This metric will help you track if you’re doing your due-diligence in unit testing or writing good APIs. You should try to keep this number to a minimum to improve confidence in the migration process.
  • Communicate w/ product / project / associated teams if changing APIs on changes to be made
    •  Communication with all parties will help prevent unexpected API changes and will put everyone on alert to catch possible bugs before they hit production.

Phase 0: Kotlin Migration POC

Before starting any migration effort, it’s a good idea to do a quick 1-3 day Proof of Concept (POC). In this POC, you will introduce Kotlin into your app and implement a small migration. (This is a perfect “Hack Day” project).

This POC can help:

  1. Prove that introducing Kotlin to your app will not break it
  2. Prove that a converted Kotlin file will work with Java
  3. Help you and your team get a layout of how the conversion will work and how you want to proceed, and
  4. Give you time to consider any third party libraries you’d like to use with Kotlin.

Suggested POC:

  1. Pick a fragment to convert to Kotlin
  2. Pick an activity to convert to Kotlin
  3. If you do MVP, MVVM, MVC Patterns: Pick a presenter/view model/controller to convert to Kotlin
  4. Pick a service to convert to Kotlin
  5. Pick a unit test to convert to Kotlin

POC Results:

  1.  List classes converted to Kotlin
  2. Demo of working app features (Prove it works!)
  3. Compare Kotlin to Java in lines of code saved (Show the improvements)
  4. Dev velocity to convert to Kotlin (how long did it take?)
  5. Make a plan of action (going forward, what’s next?)

Phase 1: Unit tests in Kotlin

For the first phase, you’ll focus on unit tests: converting all of your unit tests to Kotlin. From here, you will write any future unit tests in Kotlin.

Why is this the first phase? Unit tests do not touch your production code, so you won’t have to worry about breaking your production app. Developers not used to Kotlin can use this time to get their feet wet with the language, how Kotlin interacts with Java classes, and bonus: your team can also use this time to improve your code coverage!

I highly suggest you look into using MockitoKotlin with your unit tests if you are using Mockito.  It greatly improves the ease of mocking objects and dealing with argument captors.

Phase 2: Convert small utilities, classes, or UI to Kotlin

Work with your team to pick out some small, very well unit-tested, utilities, classes, fragments, or activities to convert to Kotlin. Any code you write should be tested by QA on a feature branch to ensure nothing broke before you merge the class in.

By making sure you’re working with well unit-tested areas of code, you’re mitigating the chance that you’ll do the conversion and run into bugs in production.  You can also migrate UI classes because any bugs in these classes are more likely to be found by a visual QA than more business-logic based classes. You can use this phase to prove that converting small utilities or classes improves the code and does not hurt the product, and again, it gives developers time to improve their ability to code in Kotlin.

Phase 3: Create a new feature in Kotlin 

This is the real test of a developer’s familiarity with Kotlin. A developer should be able to create a new feature in Kotlin without greatly affecting their velocity. Again, that feature should be thoroughly unit tested.

This phase will prove that developer velocity is not adversely affected by including Kotlin since it should not vastly slow down feature creation. It will allow your team to get a feel for developing in Kotlin from the ground up, rather than converting existing code. This step should also improve developer confidence in Kotlin.

Phase 4: Open Conversion to Kotlin

At this point, the team should be very confident in developing and converting to Kotlin. The team members are free to convert any class they touch into Kotlin. If any APIs are changed or large features are to be converted, the developer should alert the team and any interested parties about the changes, and possibly create tech debt tickets to do the migration. In and after Phase 4, any new features should be written in Kotlin (unless the team agrees that a class must be in Java). This open conversion can be tracked through the change in percent of Kotlin conversion for each sprint and will help the team get to 100% conversion.


Whew! You made it! With this phased Kotlin Migration approach, you can take convert your app piece by piece—taking a safer, smoother path to a 100% Kotlin product. You can do this. Go for it!

The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.