David Cordero

A Pragmatic Guide to Migrating from Native to React Native (or choosing not to)

Published on 21 May 2025

Has this ever happened to you? You start considering a possible migration of your native applications to React Native, and suddenly you are bombarded with hype-filled content promising a development utopia. However, if you share this exciting news with others, it’s very likely that you will receive a lot of hateful feedback in return.

If this is your case, and you’re wondering whether migrating to React Native would be actually the right decision for your Apps, you’re in the right place.

After two years leading one of the teams working on the migration of native Apps to React Native, I am sharing some personal learnings and the insights I wish I would have had when I began this journey.

Please note that this post is not about telling you whether you should migrate to React Native or not. That’s your decision to make. Instead, I will focus on different areas that I think you should consider before making this decision, as well as during the migration process.

Avoid Overselling or Hateful Content

Let’s start by facing reality: React Native is not the solution to all problems. If it were, every company in the world (including Meta, which actually created it) would be using it exclusively. However, even they are still maintaining native codebases. However… this doesn’t mean either that all those companies that decided to use React Native are wrong.

Because of this I recommend you to maintain a critical mindset when evaluating React Native. I suggest avoiding both the extreme hype and the subjective hateful content that dominates many publications and discussions. Because reality actually exists somewhere in the middle.

Be aware that many companies and content creators base their businesses either on React Native or on native technologies, and therefore you will find a lot of overselling or hateful content about this topic. This can easily create a sense of FOMO if you’re not adopting React Native right away, or make you feel foolish if you are actually doing it.

I recommend you remain calm, critical, and balanced to make an unbiased decision.

Financial Perspective

Be cautious when software engineers speak to you about the amazing financial benefits of React Native or any other multiplatform solution. Not because they might be wrong, but because they will likely miss less technical factors that could have a significant impact on your company.

Please also keep in mind that the idea of “a single codebase is cheaper and faster” is not necessarily true - much like a single Caterpillar dump truck isn’t necessarily cheaper and faster than four regular cars.

When analyzing the financial impact of this decision, you should consider factors beyond initial development costs, for example:

• Cost of opportunity: How much time will the development and subsequent migration take for you, potentially putting your existing customers in a feature freeze situation? Do you risk seeing users migrate to competitors during this period? How likely is it that your original timeline will not be delayed?
• Personnel cost: As a result of this decision, it’s very likely that you’ll need to part ways with some of your engineers. Either because they don’t wish to develop their careers in this direction or because they couldn’t keep up with the changes. In any case, this will come at a cost. How much time and money will it take to find their replacements? That will depend significantly on your specific situation.
• Strategic barriers: Using React Native will limit your business in certain ways, for example, the number of platforms that your app will be able to support. As a consequence, you may become slower to react to opportunities such as new devices or features entering the market. Is this something relevant to your area of business?

In any case, apart from being a technical decision, the migration of your apps to react native is a big financial investment. Because of that, you should probably involve your finance team in the evaluation.

It might be a good idea to define a clear budget, setting specific milestones, and planning a return on investment to keep this topic under control to avoid compromising the viability of your business in case of significant delays or unforeseen issues getting out of hand.

Big Bang vs Incremental Migration

Be careful because it’s very easy to underestimate the time required to migrate all the existing business logic of your app. If it took years of development for your current application to reach its actual state, I recommend you being skeptical when someone tells you that the migration will take only a few months

The devil is in the details, and there are likely thousands of edge cases buried in your app’s business logic that you’ll need to handle in the new development, potentially delaying your initial plans significantly.

Unless your app is particularly simple, I recommend you avoid a big bang approach.

A big bang approach, where you rewrite everything from scratch, presents several risks:

• You can’t release until achieving feature parity with your existent Apps
• If things don’t work out, it’s very difficult to roll back without significant waste of time and money
• The scope can easily become unmanageable

Instead, following an incremental migration, that means migrating each section of your app in phases, would allow you to:

• Release changes incrementally
• Test and validate each component in production
• Measure user satisfaction
• Roll back problematic modules individually
• Demonstrate value earlier in the process
• Ultimately make an informed, educated decision of committing resources and changing strategy, after only a fraction of investments and risks taken

Experiments and Proof of Concepts

If the first React Native project created by your engineers is your production app, you’re taking an unnecessary risk.

I recommend you starting smaller to facilitate your team getting familiar with the technology before getting started with your production App:

• Create internal apps or features that aren’t customer-facing
• Organize workshops or hackathons to offer your engineers the chance to experiment with the framework and associated tools
• Build proof-of-concept implementations for the most critical parts of your business logic
• Consider developing a simple companion app that complements your main product to gain E2E experience.

These experiments provide several valuable benefits:

• They facilitate engineer engagement. This could potentially change the mindset of the team to take this as a team commitment instead of an imposed top-down decision
• They reveal unforeseen technical obstacles before you’re committed to full development and migration
• They help to identify which engineers have aptitude and interest in React Native development
• They create opportunities to establish best practices and coding standards before scaling up
• They allow you to measure and to remove uncertainties and speculation about the impact of the migration on your product
  • Impact on performance
  • Impact on Accessibility compliance
  • Developer productivity
  • Finding system integration challenges

Be transparent and don’t Leave People Behind

A technical migration is also a people migration, so you should consider offering clear growth and education paths to your engineers. Be aware that some will choose to leave regardless, but I certainly believe a transparent approach will minimize unnecessary turnovers.

I recommend you to be honest and treat people with respect. If you are working with adults, you can be sure that everybody in your team will understand changes in the strategy of the company and the reasoning behind them, so be honest and present things clearly to them.

For the ones who decide to stay, you should consider creating a comprehensive training program that addresses key areas of development for your Application:

• React and JavaScript fundamentals
• React Native specific patterns
• Cross-platform development challenges
• Testing and debugging in the new environment

It could also be a good idea to hire new engineers or contractors with expertise on the new technology, to guide your team during this process.

Required reorganization

If you are developing native applications, it is very likely that all your teams are organized this way, with teams focused on each different platform: Apple team, Android team, Web team, etc…

Therefore, facing a migration from native to a multiplatform solution will unavoidably come with a required reorganization.

How will you be distributing your teams? There are many approaches to take, which I will not cover here because this would be out of the scope of this post. But please note that, regardless of the approach you follow, this will be something you will also need to face, and it is an important point because reorgs tend to take longer than anticipated and more challenging along the way.

It means creating teams, building cohesion and trust within them, etc…, and that’s something that doesn’t happen overnight.

Watch Out for Technological Bias

Be mindful of biases from engineers who lack an open mindset toward adapting to new programming languages and technologies.

If all you have is a hammer, every problem looks like a nail.

Learning new tools and programming languages is part of the work of an engineer, so the technology chosen to solve a problem should be the one best suited for the task, and it should not be determined by your team members unwillingness to learn new tools, frameworks, or programming languages.

I suggest you think twice before pushing a specific technology just because your engineers already have expertise in it.

Don’t Limit Yourself to React Native

If your primary goal is implementing a multiplatform solution, it’s important to remember that React Native is just one option among many. Falling into the trap of considering only React Native because it’s the most talked-about solution could lead you to miss better alternatives for your specific use case.

Some of these other options even offer different approaches that could be interesting to your product. An example of this could be Kotlin Multiplatform, which would allow you to balance between multiplatform code for the business logic, and native code for the UI.

Conclusions

Since this decision could really affect your product, your team, and your whole company, I’d recommend taking the time to do it right and avoid making a choice you’ll regret later.

Even if you’ve already made up your mind and are ready to go for it, it’s worth keeping the different points from this post in mind to help things go smoothly and to reduce risks in the process.

At the end of the day, whether or not to migrate your native apps to React Native is your call to make — it’s a strategic decision that depends on your specific situation and goals.