Xamarin to React Native: A 9-Month Migration Playbook

Xamarin officially reached end of life on May 1, 2024. Microsoft moved its mobile cross-platform investment to .NET MAUI. For teams that built apps on Xamarin between 2016 and 2022, the choice now is real: stay on a stack with no security patches and a shrinking developer pool, migrate to MAUI, migrate to React Native, or rebuild fully native.

This post is the playbook from a 9-month Xamarin-to-React-Native migration we ran on a healthcare app. It is not a tutorial. It is the decisions, the tradeoffs, and the things teams almost always underestimate. If you are evaluating your own migration, the goal is to help you ask the right questions before you sign a proposal.

Why React Native, not MAUI

Microsoft's official upgrade path is .NET MAUI. It is a valid choice, and we tell clients so during the audit when MAUI is the right answer for their team. MAUI lets teams reuse C# skills, .NET tooling, and large chunks of business logic that already exist in the Xamarin codebase.

We recommended React Native on this engagement for three reasons specific to the client:

1. Hiring pool. The client's existing team had React experience from a companion web product. The cost of training a Xamarin team into MAUI was higher than the cost of training a React team into React Native.
2. Library ecosystem. React Native has the largest cross-platform mobile library ecosystem. The client needed several integrations (a specific telehealth SDK, a HIPAA-compliant analytics tool, a custom payment flow) that all shipped React Native bindings as a first-class target.
3. Future hiring trajectory. The job market signal mattered. Senior developers are increasingly drawn to React Native ecosystems. MAUI is gaining traction but does not yet have the same hiring depth.

If the client's team had been deep in .NET with no React experience and no plan to hire React developers, MAUI would have been the right call. The honest answer is the one the audit produces, not the one we want to sell.

Stage 1: The audit

We do not write migration quotes without an audit. Migration quotes without an audit are guesses, and guesses cost the client money.

The audit ran on a read-only fork of the Xamarin repo plus access to the production analytics, crash dashboards, and App Store Connect / Play Console data. Five working days. The output was a severity-ranked findings report covering:

• What is reusable. Business logic, data models, API contracts, authentication flows, validation rules, computed values. About 40% of the C# codebase was portable conceptually, though not literally as-is.
• What is Xamarin-specific scaffolding. XAML markup, MVVM bindings, platform-specific glue, Xamarin Forms component overrides. About 35% of the codebase. Rewritten cleanly in React Native components, not ported.
• What is dead weight. Unused features, abandoned A/B test branches, deprecated third-party SDKs the client did not realize were still in the build. About 15% of the codebase. Deleted, not ported.
• What is genuinely platform-specific. Custom keyboard handling for a specific Android OEM, a legacy iOS-only payment flow, two HealthKit integrations. About 10%. Rewritten in native Swift and Kotlin, called from React Native.

The audit also established a target architecture: which React Native version, which navigation library (React Navigation v6), which state management (Redux Toolkit Query for the API layer, Zustand for local state), which UI primitives (a small in-house design system, not a third-party kit).

This was the most important week of the engagement. Every later decision flowed from the audit's findings.

Stage 2: The migration plan

After the audit, we produced a flat-fee migration scope. Not an estimate, a flat fee. The client knew the ceiling before any migration work started.

The plan covered:

• Cutover sequence. Which features ported first, which last. We started with the parts of the app least visible to users (the data sync layer, authentication, analytics) so we could validate the new architecture before user-facing features depended on it.
• Parallel-run strategy. The Xamarin app kept shipping on its existing release cadence for the first seven months of the migration. We did not ask the client to freeze features. The React Native build came up alongside it, with both apps consuming the same backend API.
• Decision gates. Three review points where the client could redirect: after the data layer was working, after the first user-facing feature shipped on React Native, and before the dual-store cutover submission. At each gate, the client could continue, pause, or pivot.
• What gets handed off, in what form. Operational runbooks, architectural decision records, an onboarding doc, README updates, and a recorded walkthrough for the next engineer.

Stage 3: Execution

Nine months of hands-on work. The pattern we ran most weeks:

• Daily builds to the client team via TestFlight (iOS) and Firebase App Distribution (Android).
• Weekly sync calls with the client's product and engineering leads.
• Internal architecture reviews every two weeks for the team doing the migration.

The most important rule of the execution phase: no feature work sneaking in through the side door. If the client wanted a new feature added during the migration, it shipped on Xamarin first, then ported to React Native after. The migration scope did not stretch.

Three patterns we hit repeatedly on this engagement that other teams should expect:

Image and media handling needs rewriting, not porting. Xamarin's image pipeline differs from React Native's. We rebuilt image caching, transform handling, and asset preloading. Plan for it.

Permissions and capability checks are platform-specific. Xamarin abstracts these. React Native exposes them more directly. The team needed to learn the iOS Info.plist permission rationale system and the Android runtime permission flow at a deeper level than Xamarin required.

Build and release pipelines are largely rebuilt. Xamarin's build system, fastlane integration, and CI scripts do not port. We replaced everything with React Native's Expo prebuild workflow plus a custom GitHub Actions setup. About four weeks of pipeline work over the engagement.

Stage 4: Dual-store approval

The dual-store cutover submission cleared in 4 weeks. That is faster than typical for a HIPAA-adjacent healthcare app and reflects two things:

1. We submitted with privacy manifests, permission rationale, third-party SDK declarations, and content guidelines fully resolved before submission. No avoidable rejections. Apple's review team caught one minor metadata issue we corrected in 48 hours. Google approved on first submission.
2. We did not ship a feature-incomplete version to "see what happens." The cutover submission was feature-parity with the Xamarin build at the time of submission. Users who downloaded the update did not lose anything.

The Xamarin app stayed shipping on the App Store and Play Store for two more weeks after the React Native cutover, in case we needed to roll back. We did not.

Stage 5: Handoff and the 30-day stability window

Handoff is the part most engagements get wrong. Our rule: the next engineer should be able to ship a release without calling us.

The handoff package included:

• A repository with clean README, contributing guidelines, and architectural decision records (ADRs) documenting every non-obvious choice in the codebase.
• Operational runbooks covering release pipelines, hotfix flows, App Store / Play Store submission checklists, secret rotation, and on-call procedures.
• An onboarding document for the next engineer: a one-day walkthrough that gets a new developer building, testing, and shipping their first PR.
• A recorded video walkthrough for visual learners and async onboarding.

Then the 30-day stability window opened. During that window, the client had direct access for anything the migration surfaced in production. Day 1 started when they notified us. The window closed at midnight Eastern Time at the end of Day 30. We answered two minor regressions during the window, both fixed inside a day.

At the end of Day 30, the client's team owned the codebase entirely. No retainer pressure. They chose what came next on their own terms.

What teams almost always underestimate

If you are evaluating a Xamarin-to-React-Native migration for your own app, these are the parts that surprise people:

• The audit is mandatory. Skipping it produces guesses, and guesses cost real money. We will not write a quote without one.
• About 30% of the budget goes to things that are not "feature porting." Pipeline rebuild, design-system creation, permissions handling, test infrastructure, handoff documentation. These are not optional and they are not glamorous.
• The "feature freeze during migration" question is the wrong question. The right question is: which features ship on Xamarin during the migration, and which wait for React Native? The answer almost always allows continuous shipping on the old app while the new app comes up alongside.
• MAUI is a legitimate alternative for some teams. Ask the audit, not your gut. If your team is deep in .NET, MAUI may be the better call.
• Dual-store approval timing is in your control. Pre-resolve privacy manifests, SDK declarations, and content guidelines before submission. Most rejections we see in this space are self-inflicted.

If your team is staring at Xamarin EOL

If you are still on Xamarin in 2026 and the lack of security patches, the SDK pressure from Apple and Google, or the hiring difficulty is becoming painful, the time to decide is now. Every month on the old stack costs more than the last. Time is money.

Our migration starting point is published: a $2,500 Quick Scan or$5,000 Full Audit gives you a written report with the specific dollar number for your migration before any rebuild work begins. Migration engagements start at $25,000 and typically run$25k to $200k+ depending on codebase size, surfaces in scope, and how much business logic is reusable.