Skip to content

NEW ARCHITECTURE MIGRATION

Plan and Deliver Your New Architecture Migration

Move a production app through the library, native-module, and build changes needed for an agreed React Native target. Start with a readiness review so the implementation scope reflects your codebase.

Senior engineers. Controlled repository access. Scope agreed before work starts.

What the engagement covers

The written proposal identifies the target, the work included, and how your team will accept the result.

Check the dependency boundary

Review the React Native target, third-party libraries, native modules, and components. Record compatibility gaps and decisions about replacements.

Scope the native changes

Identify the Fabric, TurboModule, and code generation work that applies to your app. Some libraries need upgrades; custom native code may need implementation changes.

Verify and document the result

Deliver the migration branch, compatibility decisions, build and runtime checks performed, and the open issues your team should validate before release.

Is this the right scope?

A production React Native app whose next framework upgrade depends on native-library readiness or custom native code. An assessment can also provide a plan for your own engineers before you commit to implementation.

Scope boundaries

A full app rewrite, a move to another framework, unrelated feature work, backend changes, and ongoing maintenance are separate scope decisions. Performance gains are not assumed; any performance targets and measurements must be agreed for your app.

For a broader build rescue, see React Native upgrade support. If you are deciding who should do the work, compare delivery options.

From assessment to handoff

Start with the codebase and agree on the result before committing to implementation.

1. Review readiness

Bring the current version, dependency list, custom native modules, build setup, and any failed migration attempt.

2. Choose a delivery scope

Agree on target versions, library decisions, implementation work, verification criteria, timeline, and a fixed quote. Advisory-only work is available when your engineers will execute the plan.

3. Handoff for acceptance

Review the code changes and verification notes with your team. Your QA owner validates business behavior and your team approves release.

Make acceptance concrete

Agree on target builds and representative runtime checks for navigation, gestures, animations, startup, and native integrations. Identify business workflows, test devices, and any app-specific performance checks with your QA owner.

Your team owns the release decision

Provide a technical contact, QA time, test accounts, and a plan for business-critical workflows. We document the agreed checks and remaining limitations; your team reviews the changes and approves deployment.

Before we start

Does every native module need to be rewritten?

No. The work depends on the target version, library support, and your custom code. The readiness review identifies which dependencies can be upgraded, which need replacement, and which custom modules or components need changes.

Can you assess readiness without doing the migration?

Yes. A scoped consulting engagement can provide an assessment and written implementation plan. Execution can be agreed separately if you want help delivering it.

Can an Expo app need this work?

Yes. Its SDK target and native dependencies determine the work. For an Expo project, plan the architecture requirements together with the SDK upgrade rather than treating them as unrelated projects.

What counts as a completed engagement?

The written proposal defines the target builds, agreed implementation, checks performed, documentation, and handoff criteria. Your QA owner validates app-specific workflows and your team controls release approval.

Review the approach

Use these resources to prepare your questions for the scoping call.

We use the React Native architecture documentation and the target libraries' compatibility guidance during scoping. For current framework support, see our version reference and its verification date.

Tell us where the work is stuck.

Bring your current setup, the change you need, and your deadline. We will discuss the scope and the next step with your team.

Discuss Your Project →