React Native to Expo migration
Move your React Native application to Expo.
Are builds, upgrades or releases taking up too much of your team’s time? Lezo moves your app to Expo and cuts the cost of its maintenance and upcoming features by about four.
01Situations
When to consider a migration
Fragile builds
iOS or Android builds fail intermittently or only work on one particular machine.
Complex releases
Signing, versioning and publishing to the stores involve poorly documented manual steps.
Heavy native maintenance
The ios/ and android/ folders pile up changes nobody dares touch, and every React Native upgrade turns into a project.
A key developer leaving
Project knowledge rests on one person who is leaving, or on a provider you are replacing.
A decision to adopt Expo
Your team wants Expo tooling: EAS builds and submissions, updates, native configuration through plugins.
A major change ahead
A redesign or a major feature is planned, and you want a sound foundation first.
02Cost
An Expo app costs about four times less to evolve
On an older React Native app, maintenance often runs around €30,000 a year, and a new feature about €10,000, between broken builds and native code to adapt. Once the app is on Expo, these costs drop by about four.
- Maintenance, per year
- Older React Native: €30,000After the Expo migration: €7,500
- One new feature
- Older React Native: €10,000After the Expo migration: €2,500
Indicative orders of magnitude: the actual estimate depends on your scope.
Where the savings come from
- 01
Less native code to maintain
The ios/ and android/ folders are generated from configuration: no more manual changes to carry over at every update.
- 02
Planned upgrades
The Expo SDK bundles versions that work together: an upgrade becomes routine work again.
- 03
Automated builds and releases
EAS builds, signs and submits the app to the stores, without relying on one particular machine.
- 04
A migration sped up by AI
AI handles the repetitive changes; every step is validated by the builds and the key user flows.
03Process
Four steps, with results presented at each one
01
Assessment
- Work done
- Review the existing app, dependencies, constraints and goals.
- What you get
- A clear decision: whether to migrate, and on what scope.
02
Migration plan
- Work done
- Define the changes, their order and how they will be validated.
- What you get
- A plan discussed with your team and an estimate specific to the project.
03
Implementation and validation
- Work done
- Adapt the project, then verify the builds and key user flows.
- What you get
- A delivered version with the verification results.
04
Handover
- Work done
- Document the choices and hand over to your team.
- What you get
- A team able to build and release on its own.
04After the assessment
What we decide together
There is no single migration recipe. The assessment lets us settle, with your team:
The tooling
Which Expo tools to adopt (prebuild, EAS Build, EAS Submit, updates) and which existing tools to keep.
The pace of adoption
A gradual adoption, one part at a time, or a broader switch in one go.
Native integrations
For each native dependency: an Expo module, an existing config plugin, a plugin to write or native code to keep.
The release pipeline
Signing, environments, build profiles and who is responsible for store releases.
What a migration does not fix on its own
Benefits depend on your project. A migration simplifies native configuration and the build pipeline; it does not automatically fix functional debt, performance or the app’s architecture. The assessment clearly separates what the migration covers from what it does not.
Deliverables
What you receive
- A written assessment of the existing app and its dependencies.
- An engagement plan with the order of changes.
- The code and configuration changes.
- Validation results: builds and tested user flows.
- Documentation of the choices and the new setup.
- A handover session with your team.
Required access, release responsibilities, timelines, support and acceptance criteria are set out in the proposal.
Case study
Chouic: three apps migrated to Expo in one month
Chouic, a studio whose mobile games are played by millions, asked Lezo to migrate three React Native apps. Its team then migrated a fourth app on its own, and reports a productivity gain and lower maintenance costs.
Read the Chouic case studyLezo also builds its own mobile app, Questovery, with Expo, and has released and maintained it since day one.
FAQ
Your questions about Expo migration
Does migrating mean rewriting the application?
No, that is not the goal. Most of the application code is usually kept; it is mainly the native configuration, some dependencies and the build pipeline that change. The assessment identifies any parts that need deeper changes.
How are native dependencies and integrations handled?
Each dependency is reviewed: Expo equivalent, existing config plugin, plugin to write or native code to keep. The choices are documented in the plan and approved with your team.
What access do you need to review the project?
For the assessment: read access to the code repository and a description of the environments. Access to store accounts and third-party services is only requested if the migration requires it, under rules agreed with you.
How do you prepare our team to take over?
Your developers take part in validation, the documentation describes the new setup and a handover session is planned. The goal is for your team to build and release without depending on Lezo.
How are price and schedule set?
After the assessment, based on the native dependencies to handle, the expected validation and your team’s availability. The migration plan comes with an estimate specific to the project. Once migrated, maintenance and new features usually cost about four times less.
Where does your app stand?
Which app do you want to migrate? What is your main blocker? These two answers are enough to prepare a first conversation.