Angular to React: What a Migration Actually Involves in 2026, and When You Should Not Do It

Nobody is being forced off Angular. Google maintains it, releases twice a year, and version 20 is a good framework. So when a CTO asks us what it would take to move an Angular application to React, the first thing we ask back is why. The answer to that question decides whether the migration is worth doing at all, and it shapes the effort far more than the size of the codebase does.

This article is about modern Angular, meaning Angular 2 onwards, the TypeScript, component-based framework most teams have been running since 2016 or so. If you are still on AngularJS 1.x, that is a different situation: the framework reached end of life in January 2022, the migration is forced rather than chosen, and the work is shaped differently. We cover that on our legacy modernisation page. Everything below assumes you are on Angular proper.

First, the honest answer: often you should not

If your team is productive on Angular, your app is on a version from the last two or three years, and the only reason for the question is that React is more fashionable, the right answer is to stay. An Angular-to-React migration is a serious project that delivers, on its own, zero new features. We say this to prospects regularly and it loses us work. It is still the right advice.

The cheaper alternative is usually an Angular upgrade. Moving from Angular 12 to 20 with the standalone components migration and signals is a few weeks of work for a medium app, not months, and it gets you most of the developer-experience gains people imagine they would get from switching.

When a switch earns its place

There are five situations where we do recommend the move, and they are all about the business rather than the framework.

1. Hiring. In the UK market, React developers outnumber Angular developers by a wide margin, and the gap is growing. If every hire takes twice as long and every good candidate asks about your React roadmap, the framework is losing you people.
2. You need Next.js. Server rendering, static generation, edge middleware and the deployment story around Next.js are ahead of what Angular offers. Marketing sites, content-heavy products and anything where SEO or first-paint matters commercially tend to end up here.
3. Consolidation. Two frontends after an acquisition, or a product team already building the next thing in React while the core app sits in Angular. Running both indefinitely is a tax on every shared component and every hire.
4. A very old Angular. Apps stuck on Angular 2 to 8 face a multi-version upgrade that is itself a large project, with breaking changes at every step. If you are going to spend that money anyway, it is reasonable to ask whether to spend it on the framework you want to be on in 2030.
5. Sharing with mobile. Teams who want one component and data layer across web and React Native have a genuine architectural reason to be on React.

If none of those apply, close this tab and upgrade Angular. If one or more do, keep reading.

The short answer on effort

These are the shapes we see across incremental Angular to React migrations delivered by a senior team. Angular apps generally come in at the lighter end of each band compared with older stacks, for reasons the next section explains.

Screen count is a proxy. What we actually size is the number of distinct UI patterns, how much of the application's state lives in RxJS streams and stores, and how many third-party Angular components have to be replaced. Two 40-screen apps can sit two bands apart.

What transfers cheaply

This is where Angular differs most from an older frontend, and it is good news for the plan.

• TypeScript. Your types, interfaces and API models move across almost untouched. On an AngularJS or jQuery migration, typing the domain from scratch is a real line item. Here it is free.
• Component boundaries. Angular components map onto React components far more directly than templates and controllers ever did. The decomposition work is already done.
• HTTP services and API clients. Injectable services that wrap HttpClient become plain modules or React Query hooks. The endpoints, error handling and data shapes are reused.
• Business logic in pure services. Pricing rules, validation, formatting and calculations written as plain TypeScript functions in Angular services port with a copy and a test.
• Tests. Cypress and Playwright end-to-end suites keep working against the new app with minor selector changes, and they become your parity harness. Jasmine and Karma unit tests do not transfer, but they document intent.

Roughly, a third to a half of a well-structured Angular codebase is framework-neutral TypeScript that survives the move. The better your team separated logic from presentation, the higher that fraction.

What does not transfer, and takes real work

The other half is where the effort goes.

RxJS and state management

This is the biggest single item. Angular teams lean on RxJS everywhere: component inputs as observables, combineLatest chains feeding templates, NgRx stores with effects and selectors. React has no direct equivalent and bolting RxJS onto React is a well-trodden mistake. The state model has to be re-thought, usually into React Query for server state and something small like Zustand for client state, with a great deal of NgRx boilerplate simply disappearing. That is a good outcome, but it is design work, not porting, and it takes senior people.

Angular Material, PrimeNG and the data grid

Every Angular Material or PrimeNG component needs a React equivalent, and the equivalents are never identical. Tables, date pickers, autocomplete and dialogs carry years of accumulated configuration. Data grids are the expensive case: if the core screens run on AG Grid you are in luck because it has a first-class React build, but a heavily customised Material table is a rebuild. Size by the number of distinct components in use, not the number of screens that use them.

Reactive forms

Angular's reactive forms with nested FormGroup trees, custom validators and cross-field rules are usually re-implemented with React Hook Form and Zod schemas. The logic is easy to read across, but the wiring is different enough that each complex form is a task rather than a translation.

Routing, guards and resolvers

Angular's router carries auth guards, resolvers and lazy-loaded modules. Next.js handles these through middleware, layouts and server components. Most of this becomes simpler, but permissions logic scattered across guards has to be found and centralised.

Angular Universal

If you are already server-rendering with Angular Universal, that work is not lost, but it is re-done in Next.js, and the caching and data-fetching model changes. If you are not server-rendering and that is part of the reason for moving, it is a new capability you are taking on, and it belongs in the plan explicitly.

Dependency injection

Angular's DI is elegant and React does not have it. Services become modules, hooks and context. The port is mechanical, but any code that relied on injection tokens, hierarchical injectors or multi-providers needs a deliberate redesign.

Incremental, not big-bang

Angular teams have one advantage over most legacy migrations: the tooling for running two frameworks side by side is mature.

• Route-level strangling. A thin shell, usually Next.js, owns the URL. Migrated routes render React; everything else is served by the Angular app. Users never see the seam. This is our default and it works well with Angular's lazy-loaded modules, which already define natural boundaries.
• Module federation or single-spa. Where an Nx monorepo already splits the app into libraries, each library can be migrated and mounted independently. More setup, but it lets several people work in parallel without stepping on each other.
• Web components at the edges. Angular Elements lets an existing Angular component be embedded in React pages, and the reverse works too. Useful for the two or three screens too large to move in one step.
• Shared services first. Authentication, the API client, feature flags and analytics are extracted into framework-neutral packages both apps consume. Unglamorous, and the point at which most of the risk disappears.

Incremental delivery does not cut the total engineering hours by much. What it changes is that value ships from month one, the work can pause between phases without losing anything, and a change of priorities leaves you with a half-migrated app that works rather than a half-built one that does not.

Where the effort goes

For a medium migration, the split we plan against looks like this:

• Discovery and audit: 5 to 10%. Reading the code, mapping components to patterns, inventorying UI libraries and state, agreeing the order.
• Shell, auth and shared services: 15 to 20%. The Next.js foundation, routing, API layer, design tokens, CI/CD, and the bridge that lets both apps coexist.
• State redesign: 10 to 15%. Replacing RxJS and NgRx patterns with React Query and a small client store. This line is specific to Angular migrations and is the one most estimates leave out.
• Screen and component migration: 40 to 50%. Front-loaded on the first instance of each pattern and the handful of genuinely hard screens.
• Parity testing and QA: 10%. Reusing the end-to-end suite, adding visual regression, and checking the edge cases only your most experienced users know about.
• Cutover, retirement and handover: 5 to 10%. Removing Angular, deleting the bridge, documenting the result, and making sure your team owns it.

If a proposal is silent on state redesign or on retiring the old app, ask why. Those are the two places Angular migrations quietly become permanent dual-stack projects.

The comparison that actually matters

Do not weigh the migration against doing nothing. Weigh it against two other options.

The Angular upgrade path. For a medium app on Angular 14 or later, a full upgrade to the current version with standalone components and signals is a few weeks of work, not months. If that resolves the pain, it wins on every measure.

The dual stack. If part of your product is already in React, every shared component is built twice, every design change lands twice, and every engineer needs both skill sets. Over a few years that tax alone can add up to more than the migration would have taken.

The migration case is strong when the upgrade path does not address the real problem, which is almost always hiring, Next.js, or consolidation, and when the dual-stack tax is already being paid.

How to get a plan you can take to the board

You do not need a full discovery phase to turn a band into a plan. You need a senior engineer inside the codebase for a few days with a clear brief, and a written output a non-engineer can read.

That is what our fixed-price React codebase audit does. Five working days, read-only access to the repository and pipeline, and a 20 to 30 page report: whether you should migrate at all, the migration order, the components and state that will take the most work, a timeline against the bands above, and the risks ranked. About a third of clients then do the work with us, a third do it in-house using the plan, and a third put it on the shelf. All three are fine outcomes.

Before the audit, have three things ready: the Angular version and how long it has been there, a list of the UI libraries and state libraries in use, and an honest answer to which of the five reasons above actually applies to you. If the answer is none of them, we will say so, and save you the project.