A Busy Developer’s Playbook: 7 Steps to Migrate from AngularJS to React Without Downtime

Last reviewed: May 2026. This overview reflects widely shared professional practices as of this date; verify critical details against current official guidance where applicable.

If you are maintaining a production AngularJS application in 2026, you already know the clock is ticking. AngularJS (1.x) reached its end-of-life in January 2022, meaning no more security patches, no bug fixes, and no official support from the Angular team. The pressure to migrate to a modern framework — most commonly React — is intense. But the fear of downtime, broken features, or a year-long rewrite often keeps teams stuck. This playbook is written for busy developers and technical leaders who need a practical, incremental migration strategy that keeps the lights on. We will walk through seven concrete steps, from auditing your legacy code to running both frameworks side by side, all without taking your application offline.

Step 1: Audit Your AngularJS Application and Define the Migration Boundary

The first step in any migration without downtime is understanding what you are working with. You cannot move what you do not measure. A thorough audit of your AngularJS codebase helps you identify the scope of work, prioritize components for migration, and set realistic timelines. Many teams underestimate the complexity of their legacy code, especially when it comes to tightly coupled services, custom directives, or third-party plugin dependencies. Start by creating an inventory of all AngularJS modules, controllers, services, directives, and routes. Document which parts of the application are most critical to business operations and which are rarely used. This audit will become the foundation for your migration roadmap.

Creating a Component Dependency Map

Use tools like AngularJS Batarang (if still functional in your development environment) or manual code analysis to build a dependency graph. List every AngularJS component and its relationships to services, factories, and other components. Identify components that have no external dependencies — these are your best candidates for early migration. For example, a simple filter or a standalone UI widget that receives data via attributes can often be converted to a React component with minimal effort. On the other hand, components that depend on AngularJS-specific features like deep $watch expressions, $scope inheritance, or custom directive controllers will require more careful planning. This map also helps you spot circular dependencies or dead code that can be safely removed before migration begins.

Prioritizing Components by Risk and Value

Once you have your dependency map, categorize each component using a simple risk-value matrix. High-value, low-risk components (like a search bar or a footer) should be migrated first. Low-value, high-risk components (like a complex form with intricate validation logic) should be deferred until you have more experience with the new architecture. A typical team I read about migrated a simple navigation menu in their first sprint, which gave them confidence and a working hybrid setup before tackling a multi-step checkout flow. This prioritization prevents the migration from stalling on the hardest parts first.

Defining the Migration Boundary

A critical decision early in the process is how you will run AngularJS and React side by side. The most common approach is to use a micro-frontend architecture with a shared shell that loads both frameworks. This shell can be built with Module Federation (from Webpack 5) or a lightweight iframe-based approach. The boundary defines which parts of the page are controlled by AngularJS and which by React. For a typical single-page application, you might choose to keep the main layout and routing in AngularJS initially, while gradually replacing individual view components with React. Document this boundary clearly and share it with your team to avoid confusion during the transition.

Common Audit Mistakes

A frequent error is skipping the audit entirely and diving straight into coding. Teams often find themselves rewriting code that could have been reused, or worse, breaking critical features because they did not understand how data flows between components. Another mistake is assuming that all third-party AngularJS libraries have React equivalents that behave identically. Always verify that the new library supports the same use cases and edge cases. For instance, an AngularJS datepicker might handle time zones differently than its React counterpart. Testing these differences early prevents production surprises.

This audit phase typically takes one to two weeks for a medium-sized application. It is time well spent, as it provides a clear roadmap and reduces the risk of scope creep later. Once you have your inventory and boundary defined, you can proceed to the next step with confidence.

Step 2: Choose Your Migration Architecture — Strangler Fig, Hybrid, or Rewrite

Not all migration paths are equal. The architecture you choose determines how much risk you carry, how fast you can deliver, and how much your team needs to learn. There are three main approaches teams use to migrate from AngularJS to React without downtime: the strangler fig pattern, the hybrid application pattern, and the full rewrite (with feature flags). Each has its trade-offs, and the right choice depends on your team size, application complexity, and tolerance for disruption. This section breaks down each approach with concrete scenarios and decision criteria.

Approach 1: The Strangler Fig Pattern

Inspired by Martin Fowler’s strangler fig application pattern, this approach incrementally replaces parts of the AngularJS application with React components over time. You build a thin routing layer (often using a framework-agnostic router like page.js or a custom wrapper) that decides whether to render an AngularJS view or a React view based on the URL. Over months, you gradually “strangle” the AngularJS code until nothing is left. This is the most popular approach for teams that cannot afford a big bang rewrite. It allows you to ship value continuously and roll back individual components if issues arise. The downside is the complexity of maintaining two frameworks in production, especially regarding state management and memory leaks.

Approach 2: The Hybrid Application Pattern

In a hybrid application, both AngularJS and React are loaded on the same page simultaneously. One framework acts as the shell, and the other renders inside a container element. For example, you can keep AngularJS as the main application shell and mount React components inside specific DOM nodes using ReactDOM.render. This approach is useful when you need to replace a deeply nested component that shares state with its AngularJS parent. However, it introduces significant complexity: you must manage two digest cycles, two virtual DOMs, and potential conflicts in event handling. This pattern works best for small teams that need to migrate a few high-value components quickly and have strong experience with both frameworks.

Approach 3: The Full Rewrite with Feature Flags

This is the riskiest approach but sometimes the only viable one for applications with extremely tight coupling between AngularJS and the backend. You build the entire React application from scratch behind a feature flag. When the flag is enabled for a subset of users (e.g., internal testers), they see the new React UI while everyone else sees the old AngularJS UI. Once the new application is stable, you ramp up the percentage until the old application is decommissioned. This approach requires significant upfront investment (often 6-18 months) and carries the risk of building a product that does not match the original exactly. It is best suited for applications that are already due for a major UX redesign, not just a framework swap.

Comparison Table: Which Approach for Your Team?

For most busy developer teams, the strangler fig pattern is the recommended starting point. It balances risk with progress and allows you to learn React gradually while keeping the existing application stable. If you need a faster win, consider the hybrid pattern for a single, well-isolated component. Avoid the full rewrite unless you have a dedicated team and a clear business case for a redesign.

Once you have chosen your architecture, the next step is to set up the technical infrastructure that allows both frameworks to coexist. This is the most technically demanding part of the migration, but it is also the foundation for everything that follows.

Step 3: Set Up Your Shared Shell with Module Federation

Regardless of which migration architecture you choose, you need a way to load both AngularJS and React within the same application. The most robust and modern approach is to use Module Federation, a feature of Webpack 5 that allows you to dynamically load code from separate builds at runtime. This enables you to have an AngularJS build and a React build, each with their own dependencies, and a host shell that decides which micro-frontend to load for each route. Setting this up correctly is the single most important technical task in the migration. A poorly configured shell will lead to conflicts, slow load times, and debugging nightmares. This section provides a step-by-step guide to configuring Module Federation for a hybrid AngularJS-React application.

Step-by-Step: Configuring Webpack 5 Module Federation

First, ensure your project uses Webpack 5. If you are still on an older version, upgrade your build system first, as Module Federation is not available in earlier versions. Create two separate webpack configurations: one for the AngularJS application (the host) and one for the React application (the remote). In the AngularJS webpack config, add a new plugin: new ModuleFederationPlugin({ name: 'angularjs_host', remotes: { react_remote: 'react_remote@http://localhost:3001/remoteEntry.js' } }). In the React webpack config, expose the components you want to share: exposes: { './SearchBar': './src/components/SearchBar.jsx' }. Then, in your AngularJS code, you can dynamically import the React component using import('react_remote/SearchBar') and mount it into a DOM element. This pattern allows each framework to maintain its own build pipeline and versioning.

Handling Shared Dependencies

A common challenge with Module Federation is managing shared dependencies like React itself. If both the host and remote load their own copy of React, the application can crash or behave unexpectedly. Use the shared configuration in Module Federation to specify which libraries should be singleton instances. For example, shared: { react: { singleton: true, requiredVersion: '^18.0.0' }, 'react-dom': { singleton: true } }. This ensures that only one copy of React is loaded, even if multiple micro-frontends request it. Be careful with AngularJS dependencies — you typically do not need to share them, as the AngularJS application will remain in control of its own module system. However, if you are using a shared state management library like Redux or Zustand across both frameworks, you may need to share that as well.

Routing Between Frameworks

When using Module Federation, you need a unified routing layer that can delegate to either AngularJS routes or React routes. One practical approach is to use a lightweight, framework-agnostic router like wouter or a simple hash-based router in the host shell. Define all routes in a central configuration file. For example: { path: '/dashboard', framework: 'react', component: 'Dashboard' }. The shell checks the current URL, loads the appropriate micro-frontend, and mounts it into a container div. You can implement a simple loading spinner while the remote module is fetched. This approach keeps routing logic centralized and makes it easy to migrate a route from AngularJS to React by simply changing the framework value in the config.

Common Pitfalls and How to Avoid Them

One frequent issue is that Module Federation can significantly increase the initial load time if not configured properly. Always use code splitting and lazy loading for your remote components. Another pitfall is CSS leakage — styles from AngularJS can accidentally affect React components and vice versa. Use CSS modules or a scoped styling solution like styled-components for React components. Also, be aware that AngularJS uses a different event system than React. If you need to pass events between the two, use a custom event bus (a simple EventEmitter or a Redux store that both frameworks can access). Testing this setup thoroughly in a staging environment before going to production is essential. One team I read about spent two weeks just stabilizing the Module Federation configuration before they could confidently migrate their first component.

Once your shared shell is stable and both frameworks load correctly, you are ready to begin converting AngularJS components to React one by one. This is where the real work begins, but the infrastructure you have built makes it safe and incremental.

Step 4: Convert AngularJS Components to React Incrementally

With your shared shell in place, the next step is to start replacing AngularJS components with React equivalents. The key principle is incrementalism: convert one component at a time, test it thoroughly, and deploy it before moving to the next. This approach minimizes risk and allows your team to learn React gradually. It also gives you the opportunity to refactor the component’s logic, not just its view layer. Many teams make the mistake of trying to copy the AngularJS code verbatim into React, which often results in a React component that feels “AngularJS-like” and misses the benefits of the new framework. Instead, take the time to understand the component’s purpose and rewrite it using React idioms: hooks for state and side effects, controlled components for forms, and a unidirectional data flow.

Selecting the First Component to Migrate

Choose a component that is simple, well-documented, and has few dependencies. A good candidate is a presentational component — one that receives data via props and renders it, without managing complex state or side effects. For example, a user avatar component, a status badge, or a simple list item. Avoid starting with a component that has many AngularJS-specific features like deep $watch, $broadcast, or custom directive controllers. The goal of the first migration is to validate your toolchain, not to solve the hardest problem. Once you have successfully converted and deployed the first component, you gain confidence and can tackle more complex ones. A typical pattern is to migrate components in order of increasing complexity: presentational → container → form → integrated feature.

Handling AngularJS Services in React

One of the biggest challenges is sharing services between AngularJS and React. AngularJS services are singletons managed by its dependency injection container, while React prefers to manage state via context or external libraries like Zustand or Redux. There are two strategies for handling this. The first is to rewrite the service as a plain JavaScript module that both frameworks can import. This works well for pure utility functions (e.g., date formatting, API call helpers). The second strategy is to create a bridge: expose the AngularJS service on the window object or via a custom event bus, and access it from React using a custom hook. For example, you can create a useAngularService hook that retrieves the service from the AngularJS injector and returns its methods. This approach is fragile and should be used only as a temporary measure. Ideally, you should migrate the service itself to a framework-agnostic module as soon as possible.

Rewriting $scope and $watch Logic

AngularJS’s two-way data binding and $scope are replaced in React by state and props. When converting a component that uses $scope.$watch, you need to identify what data changes are being watched and replace them with React state updates or useEffect hooks. For example, a component that watches a user’s input and triggers a search can be rewritten as a controlled input with an onChange handler that debounces the API call. Be especially careful with deep watchers ($watch with object equality) — they often hide performance problems. In React, you can use useMemo or useCallback to optimize re-renders instead. If the component watches multiple variables and performs different actions, break it into smaller hooks or multiple useEffect calls with specific dependencies. This refactoring often improves performance and readability.

Testing the Converted Component

Before deploying a converted component to production, you must test it in isolation and within the full application. Write unit tests for the new React component using React Testing Library. Then, in a staging environment that mirrors your production setup, replace the AngularJS component with the React version using a feature flag. Run automated integration tests that cover the user flows involving that component. Compare the behavior side by side: does the React version render the same data? Does it handle edge cases (empty data, errors, slow network) the same way? One team I read about used screenshot comparison tools to detect visual differences between the old and new components. Only when the test suite passes and manual QA approves it should you promote the change to production.

This incremental conversion process is the heart of the migration. Each converted component reduces your reliance on AngularJS and builds your team’s React expertise. Over weeks and months, the proportion of React code grows until AngularJS is no longer needed.

Step 5: Manage State Across the Framework Boundary

State management is arguably the trickiest part of a hybrid AngularJS-React application. In a pure AngularJS app, state flows through $scope and services with two-way binding. In a pure React app, state flows downward via props and upward via callbacks. When both frameworks coexist, you need a strategy to keep state consistent across the boundary. If you get this wrong, users will see stale data, UI flickers, or even errors when components try to update state that no longer exists. This section covers three practical approaches for managing cross-framework state, along with their trade-offs and recommended use cases.

Approach A: Centralized State with a Shared Store

Use a framework-agnostic state management library like Redux, Zustand, or a simple EventEmitter that both AngularJS and React can access. The store is initialized once and passed to both frameworks. In AngularJS, you can inject the store as a service and call store.dispatch() to update state. In React, you use the library’s hooks (e.g., useSelector and useDispatch for Redux). This approach works well when you have a significant amount of shared state, such as user authentication, shopping cart contents, or real-time notifications. The downside is that you must refactor existing AngularJS services that currently own state to instead use the shared store. This can be a significant effort, but it pays off by creating a single source of truth that both frameworks can trust.

Approach B: Event Bus for Component-to-Component Communication

For simpler scenarios where only occasional communication is needed, a custom event bus can be a lightweight alternative. Create a simple EventEmitter (or use the browser’s native CustomEvent API) that allows components to publish and subscribe to events. For example, when a React component updates a user’s profile, it emits a user:updated event with the new data. AngularJS components that care about this event can listen for it and update their $scope accordingly. This approach is easy to implement and does not require a large state management library. However, it can become chaotic as the number of events grows, making it hard to trace data flows. It is best used for a small number of cross-cutting concerns (e.g., “sidebar collapsed”, “notification dismissed”) rather than complex data synchronization.

Approach C: Pass Data Through the DOM with Custom Attributes

In some cases, you can avoid a shared store entirely by passing data through the DOM. When a React component is mounted inside an AngularJS template, you can pass initial data via HTML attributes. For example, . The React component reads the attribute via document.getElementById or a ref. This works for read-only data that does not change after the component mounts. It is the simplest approach but also the most limited — it does not handle dynamic updates. If the AngularJS parent updates the user ID, the React component will not know about it unless you also implement an event bus or a watcher. Use this approach only for truly static data like configuration values or initial API endpoints.

Choosing the Right Approach for Your Team

There is no one-size-fits-all answer. Start with the simplest approach that meets your needs and evolve as the migration progresses. For most teams, I recommend starting with Approach B (event bus) for the first few components, as it is quick to implement and teaches you about the communication patterns you will need. As the number of converted components grows, transition to Approach A (shared store) for the most critical shared state. Avoid Approach C unless the data is truly static. Whichever approach you choose, document the data flow clearly and enforce it with code reviews to prevent spaghetti state management.

Once you have a working state management strategy, you can focus on the user experience. The next step addresses how to handle routing and navigation when some routes are in AngularJS and others are in React.

Step 6: Handle Routing and Navigation Across Frameworks

Routing is another area where the coexistence of two frameworks can cause friction. In a pure AngularJS application, the $routeProvider or ui-router manages URL changes and renders the appropriate view. In a pure React application, react-router-dom does the same. When both frameworks are present, you need a unified approach that ensures users can navigate seamlessly between AngularJS views and React views without page reloads or broken browser history. A broken routing setup can confuse users, break deep links, and hurt SEO. This section outlines three strategies for managing cross-framework routing, with practical implementation tips for each.

Strategy 1: Single Router in the Shell

The most robust approach is to have a single, lightweight router in the host shell (whether that is AngularJS or a custom shell) that manages all URL changes. When a user clicks a link, the shell intercepts the navigation, checks its route configuration, and either loads an AngularJS view (by updating $location or $state) or loads a React view (by dynamically importing the remote module and mounting it). This approach requires that you migrate your entire route configuration into a single format, but it gives you full control over navigation and browser history. For example, you can use the History API directly in the shell and map paths to framework-specific handlers. This strategy is ideal for the strangler fig pattern.

Strategy 2: Delegating to Framework-Specific Routers

Alternatively, you can let each framework handle its own routes, with a top-level redirector in the shell. When the shell receives a URL, it checks if the path belongs to AngularJS (e.g., starts with /admin/) or React (e.g., /dashboard/). It then delegates the routing to the appropriate framework’s router. This approach is easier to implement initially because you do not need to change your existing routing code. However, it can lead to issues with browser history and the back button. For example, if a user navigates from an AngularJS route to a React route and then presses the back button, the browser might not restore the correct scroll position or state. You can mitigate this by syncing the browser history with a shared history stack, but this adds complexity.

Strategy 3: Using a Framework-Agnostic Router

Some teams adopt a framework-agnostic router like wouter or universal-router that works with both AngularJS and React. This router is not tied to any framework’s lifecycle and can be integrated into both. For AngularJS, you wrap the router in a service that updates $location. For React, you use the router’s hooks directly. This approach requires more upfront work to build the integration layer, but it pays off by providing a consistent routing experience throughout the migration. It also makes it easier to eventually remove AngularJS entirely, as the router is already framework-agnostic.

Testing Cross-Framework Navigation

Regardless of the strategy you choose, thorough testing of navigation flows is critical. Test that clicking a link on an AngularJS page correctly loads a React view and vice versa. Test the browser’s back and forward buttons. Test deep linking: if a user bookmarks a React route while the AngularJS shell is active, does the shell correctly load the React view? Test edge cases like 404 pages, redirects, and route parameters. Automate these tests using end-to-end testing tools like Playwright or Cypress. One team I read about discovered that their React routes were not being indexed by search engines because the AngularJS shell was not passing the correct meta tags. They had to implement a server-side rendering workaround for critical pages. Identifying such issues early in the migration saves significant rework later.

With routing under control, the next step is to ensure that the migration does not degrade the user experience. The final step in the playbook focuses on testing, monitoring, and decommissioning the old framework.

Step 7: Test, Monitor, and Decommission AngularJS

The final step of the migration is both a celebration and a critical quality gate. You have converted all components, set up state management, and unified your routing. Now you must verify that the application works correctly, monitor it in production for regressions, and finally remove AngularJS from your codebase. This step is often rushed, but skipping it can undo months of careful work. A single undetected bug in the hybrid setup can erode user trust. This section provides a comprehensive checklist for testing, a monitoring strategy, and a safe process for decommissioning the old framework.

Testing Checklist for the Final Migration Phase

Before you can declare the migration complete, run through this checklist. First, verify that every user flow that previously worked in AngularJS works identically in React. This includes login, search, form submission, payment processing, and error handling. Second, run a full regression test suite, including unit tests, integration tests, and end-to-end tests. Third, perform a side-by-side comparison of key pages in a staging environment, using both automated screenshot diffing and manual QA. Fourth, test performance: measure page load time, time to interactive, and memory usage. React applications often improve performance, but incorrect state management or unnecessary re-renders can degrade it. Fifth, test on all supported browsers and devices. AngularJS applications sometimes rely on polyfills that React does not need, and vice versa.

Monitoring in Production with Feature Flags

Even with thorough testing, issues can slip into production. Use feature flags to gradually roll out the React version of each feature. Start with 5% of users, monitor error rates, latency, and user feedback for 24-48 hours, then ramp up to 50%, then 100%. Use your existing monitoring tools (e.g., Sentry, Datadog, New Relic) to track JavaScript errors, API failures, and performance metrics specifically for the new React components. Create a dashboard that compares error rates between AngularJS and React versions of the same feature. If you see a spike, roll back the feature flag and investigate before proceeding. This cautious approach ensures that even if a bug slips through, only a small subset of users is affected.

Decommissioning AngularJS Safely

Once all features are running on React and have been stable in production for at least a few weeks, you can begin removing AngularJS. Start by removing the AngularJS build artifacts from your deployment pipeline. Then, remove the AngularJS code itself from the repository. Be careful: there may be hidden dependencies, such as third-party scripts that expect AngularJS to be present. Remove the AngularJS module loader and any initialization code. Finally, update your documentation and team training materials. One important step is to remove the AngularJS dependency from your package.json and ensure no other packages require it. Run your full test suite one more time after the removal to confirm nothing is broken. Celebrate this milestone — it is a significant achievement.

Post-Migration Cleanup and Knowledge Transfer

After decommissioning AngularJS, your codebase should be a clean React application. However, there is often technical debt left behind: migrated components that still use AngularJS-like patterns (e.g., direct DOM manipulation instead of controlled components). Schedule a post-migration cleanup sprint to refactor these components to idiomatic React. Also, conduct a knowledge transfer session for the team, documenting the migration process, the architectural decisions made, and the lessons learned. This documentation will be invaluable for future migrations or for onboarding new team members.

With AngularJS fully decommissioned, your application is now modern, secure, and easier to maintain. The migration journey may have taken months, but you achieved it without downtime, keeping your users happy and your business running smoothly.

Frequently Asked Questions

This section addresses common questions that arise during an AngularJS to React migration. These are based on patterns observed across many teams and are designed to help you avoid common pitfalls.

Q: Can I use both AngularJS and React on the same page without performance issues?

Yes, but you need to be careful. Both frameworks run their own rendering cycles — AngularJS uses a digest cycle, and React uses a virtual DOM diff. If you have many components from both frameworks on the same page, you can experience jank or increased memory usage. The key is to minimize the number of cross-framework interactions. Use a shared shell with Module Federation to load React components lazily, and avoid frequent state updates that cross the framework boundary. Performance testing in a staging environment is essential before going to production.

Q: How long does a typical migration take?

There is no single answer, as it depends on the size and complexity of your application. A small application with 10-20 views might take 2-3 months with a dedicated team. A large enterprise application with hundreds of components, complex forms, and many third-party integrations can take 12-18 months. The strangler fig pattern allows you to deliver value continuously, so you should see the first converted component in production within a few weeks. Plan for a longer timeline than you expect, and budget for learning curves and unexpected challenges.

Q: What about third-party AngularJS plugins that have no React equivalent?

This is a common problem. Start by searching for React equivalents or alternatives. Many popular AngularJS plugins (like ui-grid, ui-router, or angular-translate) have well-maintained React counterparts. If you cannot find a direct replacement, you have two options: either keep the AngularJS plugin running in a wrapper component (using the hybrid pattern) or build a custom React component that replicates the functionality. The wrapper approach is faster but adds long-term technical debt. The custom component is more work but aligns with your new architecture. Evaluate the cost and benefit for each plugin individually.

Q: Should I rewrite tests or migrate them?

In most cases, you should rewrite tests for React components using React Testing Library. AngularJS tests rely on $digest, $injector, and other AngularJS-specific APIs that are not compatible with React. However, you can keep your integration and end-to-end tests (like those written with Protractor or Cypress) and update them to work with the new React selectors. The time spent rewriting unit tests is an investment in the quality of your new application. Do not skip it.

Q: What if my team does not know React well?

This is a common concern, but it is manageable. Start with a small pilot migration of a simple component to give your team hands-on experience. Pair experienced React developers (even contractors) with AngularJS developers. Invest in training: online courses, workshops, or internal lunch-and-learns. The incremental nature of the strangler fig pattern allows your team to learn React gradually, without the pressure of a full rewrite. Many teams find that after migrating 5-10 components, their developers are comfortable with React and can work independently.

Conclusion

Migrating from AngularJS to React without downtime is not a mythical goal — it is a well-trodden path that many teams have successfully navigated. The key is to approach it incrementally, with a clear plan, the right architectural decisions, and a focus on testing and monitoring at every step. This playbook has walked you through seven steps: auditing your codebase, choosing your migration architecture, setting up a shared shell, converting components incrementally, managing cross-framework state, unifying routing, and finally testing and decommissioning AngularJS. Each step builds on the previous one, creating a safe, controlled transition that minimizes risk to your users and your business.

Remember that the goal is not just to change frameworks, but to improve your application’s maintainability, performance, and security. The migration is an opportunity to clean up technical debt, adopt modern development practices, and set your team up for future success. Use the checklists and decision criteria in this guide to stay on track, and do not be afraid to adjust your plan as you learn. The journey may be long, but the destination — a modern, secure, and performant React application — is well worth the effort.