PATTERN Cited by 1 source

Screen-by-screen RN migration¶

Problem¶

You have a large existing native app (90+ screens in Zalando's case) that you want to move to React Native. Big-bang rewrite fails:

Scope too large (months or years of no business-value delivery).
Risk too concentrated (one deploy takes the whole app).
Teams blocked simultaneously.

Pattern¶

Migrate one screen at a time, each on its own risk budget. The legacy native app continues to ship through its normal release cadence. Each screen's migration is a small, bounded, testable change:

Identify a candidate screen (usually low-traffic + simple for the first migration; see patterns/early-launch-on-low-traffic-screen).
Build the RN version in the Developer App against the shared RN Entry Point.
Ship the Framework SDK update that exposes the new screen's entry point.
Update the legacy app to route to the RN-backed screen (replacing the native implementation).
Monitor — observability, crashes, analytics, performance — and roll back via the legacy app's existing rollout tools if needed.
Repeat for the next screen.

Prerequisites¶

This pattern requires the surrounding architecture from the brownfield-RN toolkit:

patterns/rn-as-consumable-npm-entry-point — so the Framework SDK can mount RN screens alongside native.
patterns/turbo-module-plus-di-contract-for-native-interop — so RN screens can call legacy-app functions (wishlist, session, analytics) without direct source coupling.
patterns/standalone-developer-app-for-rn — so each screen can be developed and tested in isolation.

Without these, screen-by-screen migration degenerates into tangled RN-plus-legacy spaghetti.

Risk profile per screen¶

Each migrated screen has independent blast radius:

A broken RN screen doesn't take down native screens.
RN JS-bundle errors scoped to that screen only (assuming the JS-bundle architecture supports per-screen boundaries).
Production rollout can be gated on that specific screen (feature-flag, server-side switch, or a binary release).

This is the core property that makes progressive migration safe. Compare to big-bang where every screen is at risk on every deploy.

Zalando's canonical case¶

Zalando's 2025-10 disclosure:

First screen: low-traffic, simple. Exercise the pipeline; build observability; learn the delivery mechanics at low stakes.
Subsequent screens: "a few screens, ranging from major to minor."
Discovery Feed: the front screen, media-heavy, featured in Q2 2025 results — validates the architecture at front- screen scale. See systems/zalando-discovery-feed.

Migration is explicitly ongoing: "For us, the migration is still ongoing."

Contrast: migration granularity options¶

Granularity	Unit of migration	Canonical case
Big-bang	Entire app	(none — fails at scale)
Per-team / per-app	App	Shopify (portfolio of apps) — sources/2025-01-13-shopify-five-years-of-react-native-at-shopify
Per-screen	Screen within a single app	Zalando — sources/2025-10-02-zalando-accelerating-mobile-app-development-with-rendering-engine-and-react-native
Per-component	Component inside a screen	(not documented on wiki — theoretical ceiling)

Zalando's screen-level granularity fits their one-app-per- platform structure. Shopify's team-level fits their portfolio-of-apps structure. Neither is wrong; they're orthogonal cuts of the "progressive adoption" principle.

Seen in¶

sources/2025-10-02-zalando-accelerating-mobile-app-development-with-rendering-engine-and-react-native — canonical wiki first source.