How to Plan an AngularJS to React Migration Without Breaking the Business

What an AngularJS to React migration involves in 2026

An AngularJS to React migration replaces the AngularJS 1.x front end with React, component by component. It is a rewrite, not an upgrade: no supported path exists between the two frameworks. The work splits into three tracks: components become JSX, two-way bound state becomes unidirectional state, and routing moves to React Router.

Get the name right first, because the search results do not. AngularJS is Angular 1.x, sometimes written Angular JS. Angular 2 and later is a different framework that happens to share a brand. Four of the nine pages currently ranking for this query never mention AngularJS at all. They use Angular examples, and those examples do not apply to your codebase.

So your decision is not React or no React. It is which of four routes to fund, what that route costs, and whether React is a destination your team can staff.

AngularJS end of life: what unsupported actually costs you

Unsupported means no patches, ever. The Angular team ended long-term support for AngularJS on December 31, 2021, after extending it once during the pandemic. Its angular/angular.js repository is archived. You can no longer file an issue or a pull request against it, which the official version support page confirms. The npm and bower packages are still published, but marked deprecated.

Here is what that means in practice. NIST's vulnerability database carries CVE-2024-8372, a srcset sanitization flaw in AngularJS. It affects every version through 1.8.3, and 1.8.3 is the last release there will ever be. The record is flagged "Unsupported When Assigned" and states plainly that the project will not receive updates.

So there is no version to upgrade to. The only fix is to stop using the framework.

That risk lands in three places on a CTO's desk.

• Security review: A customer or an auditor asks how you patch your front-end framework. You do not have a good answer.
• Hiring: People who know AngularJS well moved on years ago. The ones who stayed charge a premium.
• Dependency drift: Node, bundlers, and browser APIs keep moving. Each year the gap widens and costs more to bridge.

None of the nine pages ranking for this query cites a single one of the three sources above. That is why "AngularJS is old" rarely wins a budget conversation. A named vulnerability that will never be patched usually does.

Four ways off AngularJS, and how to choose

There are four routes, not two. Most articles present a rewrite and an incremental migration, then stop. Read the table, then pick the row that matches your two hardest constraints rather than the row that sounds most ambitious.

Read Martin Fowler before you commit to row one. On the full-replacement plan, he writes that he and his colleagues have watched it go down in flames most of the time. His case for the incremental route is that teams rarely specify existing behavior accurately, and much of that behavior turns out not to be wanted. He also defends transitional architecture, meaning code you build and later throw away, because reduced risk and earlier value outweigh the waste.

Rows two and three are where most enterprise applications land. Choosing either one commits you to running AngularJS and React together for a while. That is the part almost nobody documents, and it is where an application modernization program either holds together or comes apart.

Running AngularJS and React in the same application

They can run together, and React's own documentation says so. The Add React to an Existing Project guide opens by telling you that you do not have to rewrite. It documents two supported patterns. React can own an entire subroute behind a server or proxy rule, or it can mount into a specific element on an existing page. React's docs note the second pattern is how most React usage looked at Meta for years.

The table below covers the options teams actually choose between, and what each one does to the four things that break during coexistence.

Two things break more often than anything else here. Neither gets much coverage on page one.

Routing ownership comes first. One framework has to own the top-level route, and reversing that call is expensive. Leave it with AngularJS while React handles leaf screens, then hand it over in one deliberate step once React covers enough of the app.

Session sharing comes second. You have two bundles and one login. Keep the token in a cookie on a single domain and read it from both. Never sync two auth states.

Not everyone agrees with coexistence. The ButterCMS engineering team argues against mixing frameworks in one application, and the argument is fair. You carry two runtimes, two mental models, and a wrapper layer somebody has to remove later.

Here is the tradeoff. Coexistence buys continuous delivery and costs you transitional code. A rewrite buys a clean codebase and costs you a delivery gap. Pick the cost you can absorb.

[DIAGRAM 1: Two-lane diagram of a coexistence period. Top lane AngularJS shell owning the router and the auth cookie, bottom lane React screens mounted via wrappers, with a vertical marked handover point where React Router takes the top-level route and a second marked point where the AngularJS bundle is deleted. ALT: Coexistence period showing AngularJS owning routing until React Router takes over at handover]

A migration sequence that avoids a half-migrated app

The half-migrated app is the real risk, not the code. The top result for this query is a developer asking how to stage the release without it looking like Frankenstein. Nobody in that thread answers him. The answer is exit criteria, a feature freeze, and a cutover date you set before phase one begins.

Seven phases, in this order. Each one ends on a condition rather than a date.

1. Modernize the build first. Move to Webpack or Vite and ES modules, and retire Bower and Gulp. Exit criterion: React can be added to the bundle without touching AngularJS code.
2. Inventory every screen. Count screens, custom directives, and filters. Directives are the real unit of effort, not files. Exit criterion: every screen is tagged port, rebuild, or delete.
3. Pull business logic out of the client. AngularJS apps of this age usually hold rules the backend should own. Exit criterion: no screen you plan to port depends on client-side business rules.
4. Hand over leaf screens. Start with the screens that have the fewest inbound links. Exit criterion: three screens run in React in production for two weeks with no rollback.
5. Move state and data access. Replace $scope two-way binding and AngularJS services with unidirectional state in Redux, Zustand, or Context. Swap $http for fetch behind React Query or SWR, and rebuild forms in React Hook Form or Formik. Exit criterion: no React component reads from the AngularJS scope.
6. Move routing and tests. React Router replaces ui-router or ngRoute at the top level. Karma and Jasmine give way to Jest, React Testing Library, and Playwright or Cypress. Exit criterion: deep links resolve and coverage on migrated screens matches the old suite.
7. Cut over and delete. Remove the AngularJS bundle, the wrappers, and the injector. Exit criterion: the AngularJS dependency is gone from package.json.

Three controls keep this from stalling, and the first is the one teams skip.

Freeze feature work in the old framework. Anything new gets built in React. Skipping this control is the single most common reason a migration runs for years instead of quarters.

Make every screen earn its port. Both publicly documented migrations off AngularJS quietly deleted features rather than porting them, with stakeholder signoff, and neither team framed it as a policy. Make it one.

Set the cutover date before phase one. A date you renegotiate once is a plan. A date that does not exist is not.

Staged does not have to mean risky. On one Entrans engagement, a legacy ExtJS front end was modernized alongside a backward-compatible API migration instead of a single cutover. The published outcome was a 100 percent uninterrupted API migration with no production incidents, plus a 40 percent cut in UI interaction lag. Different framework, same principle. Stage the change, hold the contract stable, and the business never feels it.

Cost, timeline and team: how to size the work

The real question is not whether shifting from AngularJS to React is worth it. It is what your specific codebase makes it cost. Nobody can price that from a blog post, and any page that tries is guessing. What you can do is name the drivers, then get a range from someone who has read your code.

Six drivers, in rough order of impact:

1. Distinct screens, counted honestly. Five variants of one screen are not one screen.
2. Custom directives and filters. Each is a small rewrite with hidden behavior inside it.
3. Business logic sitting in the client. This is the item that breaks estimates.
4. Existing automated test coverage. Low coverage means building the safety net first.
5. Length of the coexistence period. Every extra month makes you pay for the transitional layer twice.
6. React fluency on the team today. Learning React during the migration is the most expensive way to learn it.

One cost is easy to miss. React ships with almost nothing, so routing, forms, data fetching, and dependency injection all become choices your team makes and then owns. AngularJS made most of those decisions for you. Budget the evaluation time, not only the code.

Two migrations are documented publicly with real numbers. Mark Erikson's team converted roughly 95,000 lines with four to five engineers over about 21 months. A ButterCMS engineer reports roughly three years, with the engineering team split in half. Neither figure transfers to your app, and both teams had other work running. Use them to sanity-check a proposal, never to build a budget.

The column no competing article includes is the cost of doing nothing. Staying on AngularJS never appears in a project budget. You pay it in security review time, higher contractor rates, and dependency upgrades deferred until they cannot be deferred. That cost is real, it grows, and it never gets a line item.

Team models come in three shapes. Internal only is cheapest when you already have React fluency and some slack. Partner-led is fastest when you have neither. A blended pod sits between them: the partner runs the conversion track while your team keeps shipping features. Where the constraint is capacity rather than approach, adding dedicated React developers to your existing team beats reshaping the whole program around a vendor.

Can AI convert AngularJS code to React?

Partly. AI handles the mechanical work well and the decisions badly. Demand for a converter is obvious. A VS Code extension that converts AngularJS components into React through the OpenAI API ranks on page one for this query. Half the related searches ask about automated conversion.

The only first-hand evidence is discouraging on the full-conversion promise. Mark Erikson evaluated automated conversion tools on his own MEAN codebase and judged the output not useful enough to adopt. That is one engineer on one codebase. It is still the most honest data point available.

What AI genuinely speeds up:

• Inventorying screens, directives, and dependencies across a codebase nobody fully remembers
• Explaining what an undocumented directive actually does before you rewrite it
• Mechanical template to JSX transforms, and codemods run through jscodeshift or ts-migrate
• Writing the tests you are missing, before you touch the code

Four things it does not do: choose your route, rewire two-way binding into unidirectional flow, decide which screens to delete, or lift business rules out of the client into a service. Those four are the expensive parts. AI-driven legacy modernization pays off when you point it at inventory and test generation. It disappoints when you expect a working React app back.

Where an AngularJS to React migration fails

Three cases where we would tell you not to do this.

Your team is fluent in Angular and the app leans on Angular idioms. Angular is then the cheaper destination, and its upgrade path is far better documented. Search demand agrees, because more people ask about the AngularJS to Angular route than the React one. If that describes your team, read the AngularJS to Angular migration guide and skip React entirely.

The app is inside about 18 months of sunset or replacement. Buy extended support and stop there. The official AngularJS support page names XLTS.dev as a commercial option. Funding a migration for an app you are about to switch off spends the money in the wrong place. We would say so before quoting the work.

Automated test coverage is near zero and nobody wants to build it. Migrating without a safety net turns a framework problem into a regression problem, and your users find the regressions first. Build the test layer on the AngularJS app before you migrate. It is unglamorous work, it costs less than the alternative, and it survives the migration.

One correction, because the search results contradict each other on it. One ranking page lists React as bad for SEO while two others sell server-side rendering as the fix. Both are half right.

React is no worse for search than AngularJS, but a client-rendered single-page app is. Server-side rendering solves it, usually through Next.js. That is a real engineering line item rather than a free benefit. Budget for it, or accept the rendering behavior you have today.

Two governance items get forgotten every time. A staged rollout can regress accessibility on the screens that move, so somebody has to own testing it. And if the app sits in a regulated workflow, the cutover needs an audit trail agreed in advance.

Plan the route before you fund the work

If AngularJS is still in production, the open question is which route off it to fund, not whether to move. Entrans runs a two-week front-end modernization assessment. We inventory every screen and custom directive, then score the four routes against your test coverage and release cadence. You get back a phased plan with exit criteria, a cutover date, and a cost range you can take into a budget conversation. On one recent legacy front-end engagement, the staged API migration finished with zero production incidents while the business kept shipping. Talk to an Entrans architect to scope yours.