DEV Community: CobuildX AI

The Framework Nobody Wrote Down: Taking a Backbone App to React

Emmanuel R — Mon, 05 Oct 2026 09:49:28 +0000

Backbone gave you models, views, a router and events, and left the rest to you. So most Backbone apps carry a homegrown framework on top: a global singleton, an event bus, a navigation controller, view cleanup code, a template build step and a drawer of jQuery plugins. Moving to React is mostly about finding that framework and deciding what replaces it. This guide covers how to run Backbone and React side by side, let React read Backbone models, turn views into components, test an app that never had tests, and delete the code that only existed to keep Backbone tidy.

Backbone never tried to be a full framework. It gave you models, collections, views, a router and events, and then it left the rest to you. How views get cleaned up, how one part of the app talks to another, where navigation lives, how templates get built: your team decided all of that. Or, quite often, someone who left the company years ago did.

That's why leaving Backbone feels different from leaving other frameworks. You aren't really moving off Backbone. You're moving off the framework your team built on top of it, and nobody ever wrote that one down. The good news is that a lot of it can simply be deleted, because React already does those jobs for you. The real work is finding it all first.

Source code: the examples in this post come from a small GitHub viewer we built with Backbone 1.0, RequireJS, jQuery Mobile and Handlebars. On a desktop its views sit side by side as panels, and on a phone each one becomes its own page. We rebuilt it in React 18 with the same screens, element ids and API calls. You can find both versions at cobuild-tech/migratex-examples. The app was small, so we simply rewrote it. For bigger apps, we move step by step, and that's the approach this post describes.

Before You Start

Why leave, and when not to

Nobody we talk to is upset with Backbone. It did exactly what it promised. Teams leave because of everything that grew up around it. RequireJS, Handlebars 1.x and old jQuery plugins have gone quiet, and in our example, jQuery Mobile was officially deprecated by its own maintainers in 2021. Every Backbone app also has its own house rules, so new developers have to learn your particular setup before they can change a button. And almost every Backbone team has a story about a "zombie" view that was removed from the page but kept listening to events.

That said, be honest with yourself before you commit. If the app is stable, rarely changes and the people who look after it are happy, leaving it alone is a perfectly fair choice. Move when changing the app keeps getting more expensive, not just because the code looks old.

Inventory the framework you built

Before anyone gives an estimate, list every piece of setup your team added around Backbone. Even our small example had a surprising amount. For each item, you'll decide whether React already covers it or whether it can simply go:

What the team built	What it was for	In our example
A global singleton	Lets any module reach the controller, the event bus or the current user	`Globals`, created to break a circular RequireJS dependency
An event bus	Lets distant parts of the app talk without imports	`Globals.events.trigger('page:destroy', id)`
A navigation controller	Decides which view goes where, often instead of `Backbone.Router`	`controller.js` with `goToHomePage`, `goToRepoPage`...
View cleanup code	Unbinds events and removes DOM so views don't leak	`BaseView.close()` plus a page stack in `events.js`
A template build step	Precompiles templates into JavaScript	The Handlebars CLI, run by hand from a README
Global AJAX hooks	Loading spinners, auth headers, error handling for every request	`$.ajaxSetup` showing "Connecting To Github"
jQuery plugins	Widgets, animation, layout	jQuery Mobile pages and transitions, EnquireJS

Here's a quick way to get a rough size. Search the code for .extend(, listenTo(, .on(, trigger(, $( and the name of your global object, and count the hits. The extend count tells you how many models and views you have. The event and jQuery counts show how much hidden wiring sits between them, and that's where most of the time goes.

Get onto a modern bundler first

If the app still loads through RequireJS or a long list of <script> tags, change that first, before any React code arrives. The nice part is that you don't need to rewrite your modules to do it. webpack understands AMD define() calls, so the existing code can be bundled as it is and moved to ES modules file by file later. Vite works really well for the new React code. While you're at it, move any hand-run template build step into the bundler, so it runs on every build.

Then upgrade Backbone to 1.4 or later. It's a small step that brings old patterns to the surface early. Our example still read this.options inside views, which Backbone removed in 1.1. It's also a good time to swap model.on(...) for this.listenTo(model, ...), so views clean up their own listeners when they're removed.

Running Backbone and React Together

Rewriting everything at once is tempting, but it's risky. The safer path is Martin Fowler's strangler fig approach: you add new code around the old app, piece by piece, until the old app isn't needed anymore. Backbone makes this easier than almost any other framework.

Mounting React inside a Backbone view

A Backbone view is really just an object that holds a DOM element, so you can hand that element straight to React with createRoot:

// views/cartView.js
import { createElement } from 'react';
import { createRoot } from 'react-dom/client';
import { Cart } from '../react/Cart';

export const CartView = Backbone.View.extend({
  render() {
    this.root ??= createRoot(this.el);
    this.root.render(createElement(Cart, { cart: this.model }));
    return this;
  },
  remove() {
    this.root?.unmount();
    return Backbone.View.prototype.remove.call(this);
  },
});

The rest of the Backbone app doesn't notice anything changed. It still creates a CartView and calls render() and remove() as before. Calling render() again simply updates the React component with new props. Just remember to override remove() as shown, so the React root is cleaned up along with the view.

Sharing models and the URL

For a while, your React components will need data that still lives in Backbone models. There's no need to copy it into React state and keep two versions in sync. Backbone models already fire change events, and that's all React's useSyncExternalStore hook needs:

export function useModelValue(model, key) {
  const subscribe = useCallback((onChange) => {
    model.on(`change:${key}`, onChange);
    return () => model.off(`change:${key}`, onChange);
  }, [model, key]);
  return useSyncExternalStore(subscribe, () => model.get(key));
}

Now a Backbone view can call cart.set('count', 3) and the React component updates on its own. One simple rule keeps this smooth: when an attribute holds an object or an array, always set a new one instead of changing it in place. React compares values by reference, so a new value is how it knows something changed.

The URL needs a single owner too. Backbone.history and React Router both listen to the URL, so pick one at a time. Early on, Backbone keeps the router and React lives in small islands. Once most screens are in React, switch it around: React Router takes over, and the remaining Backbone screens are mounted by small React wrapper components. From there, you can move routes across one at a time.

Replacing Models and Collections

A Backbone model looks like one thing, but it does several jobs at once. Split them up and each one has a simple React replacement:

What a Backbone model does	A good choice in React
`url`, `fetch()`, `save()`	Plain `fetch` functions, called through TanStack Query
`parse()`	A tested function that shapes the API response
`defaults`, `validate()`	Form state with a validation function or schema
`change` events	Query cache updates, with React re-rendering for you
Collection `reset`, `add`, `remove` events	Refetching or updating the cached list
`_.where`, `_.filter` on collections	Everyday array methods, used during render

The parse() methods are worth more than they look. They hold years of knowledge about your API, like which field was renamed or which endpoint wraps its results. Move them into plain functions with tests before anything else, so both apps can use them. Ours was a one-liner, which is pretty typical:

// Backbone
const UserModel = Backbone.Model.extend({
  urlRoot: 'https://api.github.com/legacy/user/search/',
  parse: (data) => data.users[0],
});

// React
export async function fetchUser(name) {
  const data = await getJson(LEGACY_USER_SEARCH_URL + encodeURIComponent(name));
  return data.users[0] ?? {};
}

You might spot two small improvements in the React version: it encodes the username for the URL, and it returns an empty object instead of undefined when nothing matches. Porting is a great time to fix little bugs like these, as long as you write each one down.

One more thing to keep in mind. Backbone views often created a new collection every time they were shown, so every click sent a fresh request. TanStack Query caches results, which is usually a nice speed boost. Where users expect a button to really refresh, add a request id to the query key so it fetches again, just like before. That's what we did in our port.

From Views to Components

This is the biggest change in how you think, so let's look at a real example. Here's our Backbone home view reacting to a user search. It finds DOM elements, changes them and runs a jQuery animation:

showAdditionalButtons: function() {
  if (this.model.has('username')) {
    this.avatar.attr('src', gravatarUrl(this.model.get('gravatar_id')));
    this.avatarContainer.slideDown();
  } else {
    this.avatarContainer.slideUp('slow', function() {
      alert('No User Found');
    });
  }
}

In React, the handler just updates state. The markup describes what each state looks like, and the slide becomes a CSS transition on a class:

onSuccess: (user) => {
  if (user.username) {
    showAvatar(gravatarUrl(user.gravatar_id ?? ''));
  } else {
    hideAvatar();
    setTimeout(() => alert('No User Found'), SLIDE_MS);
  }
}

<div className={`avatar-container${avatarOpen ? ' is-open' : ''}`}>

Once the team gets used to this, a whole group of bugs goes away. The page can't fall out of step with the data anymore, because the page is always drawn from the data.

The rest of a view carries over easily. The events hash becomes onClick and similar props on the elements themselves. Our views even had two versions of every event map, one for touch and one for click, and React only needs one. Handlebars templates become JSX, and the {{#if isPhone}} blocks that wrapped every template became a single <PhonePage> component.

Delete the cleanup code

This is the most satisfying part. Our example had a page stack, a page:destroy event, a close() method on a base view, and careful calls to undelegateEvents() and removeData(), all to stop views from leaking. In React, when a component is no longer rendered, it's gone, along with its event handlers. So we deleted all of that code instead of porting it. It even fixed a bug: clicking "Get User Activity" twice on desktop used to leave the first view attached to the page.

The global event bus usually goes the same way. For each trigger, ask who actually listens to it. Most of the time it's just one place, and the event becomes a prop, a callback or a shared piece of state. In our app, page:destroy didn't need a replacement at all, because it only existed to clean up views, and React handles that for you.

Responsive layouts without jQuery Mobile

Our example had one more job to move. The same views showed up as panels on a desktop and as separate pages on a phone. The Backbone controller used EnquireJS to check the screen size once, at startup. In React, the screen size is just another value to subscribe to, using matchMedia and the same useSyncExternalStore hook we used for models:

const PHONE_QUERY = 'all and (max-width: 599px)';

function subscribe(onChange) {
  const mql = window.matchMedia(PHONE_QUERY);
  mql.addEventListener('change', onChange);
  return () => mql.removeEventListener('change', onChange);
}

export function useIsPhone() {
  return useSyncExternalStore(subscribe, () => window.matchMedia(PHONE_QUERY).matches);
}

Now the panels and the pages share the same components. On a desktop, the home page shows them side by side. On a phone, each one is its own route with a Back header, so the browser's Back button works too, which the original never managed. Because the hook follows the window size, resizing switches the layout straight away. The jQuery Mobile look, with its header bars, rounded buttons, slide transitions and loading overlay, came across as a few hundred lines of plain CSS.

Testing the Migration

Many Backbone apps have few tests, and ours had none. So before changing anything, we wrote down what the app actually does, odd parts included. Michael Feathers calls these characterisation tests in Working Effectively with Legacy Code: they record what the code does today, not what anyone thinks it should do. Reading our app closely turned up things nobody would have put in a spec:

If the user search fails, nothing happens at all, because the listener only ran on success.
"No User Found" waits until the avatar has finished sliding away before it appears.
Clicking "Get User Repositories" again clears the repo table as well as reloading the categories.
The phone or desktop layout was decided once and never changed when the window was resized.

Each one became a test, or a written decision to change it. Without that list, the first three would have quietly changed during the port and come back months later as bug reports.

For bigger apps, write the important user journeys as Playwright tests and get them passing against the Backbone app first. Then run the same tests against React. A journey counts as migrated when it passes on both. Keeping the original element ids in the React markup gives both apps the same test handles, and mocking the API with MSW lets one fake server work for both apps. Inside the React test suite, wait for what the user would see with Testing Library's findBy queries. Our 23 tests cover the desktop panels, the phone pages and resizing across the breakpoint.

Finishing the Migration

Helping the team settle in

Code moves faster than habits, and Backbone habits run deep. These patterns show up in almost every team's first React pull requests, and each one has a simple React-friendly alternative:

Reaching for jQuery inside an effect. If something on the page should look different, update state and let the component describe the new look.
Rebuilding the event bus. Passing a callback, or sharing the state both components care about, keeps things easy to follow.
Changing objects in place and forcing a render. Create new values instead, and React will pick up the change on its own.
Using effects to keep two values in sync. Usually the second value can just be calculated during render, as the React docs on effects explain.

A short internal page that shows one of your own Backbone views next to its React version helps more than any general tutorial. Reviewing early React pull requests in pairs, with one person who knows the old app and one who knows React, spreads both kinds of knowledge quickly.

The removal checklist

You'll know you're finished when backbone, underscore, jquery and the template runtime are removed from package.json, along with their plugins. Before that commit, run through a few quick checks:

Every screen is rendered by React, and Backbone.history is no longer started.
Everything the global singleton used to hold has a new home, or was removed on purpose.
Auth headers, loading indicators and error handling from $.ajaxSetup and ajaxPrefilter now live in your fetch client.
Plugin CSS, like jQuery Mobile's, has been replaced, and nothing depends on its class names.
The bridge code, like React roots inside Backbone views and the model hook, has been cleaned up.
Old URLs, including hash URLs like #users/42, still work or redirect.

That last point is easy to miss. Many Backbone apps used hash URLs (/#users/42), and those links live on in bookmarks, emails and help pages. The part after the # never reaches the server, so a server redirect can't catch it. Add a small bit of code on the React side that reads the old hash and sends users to the new path, and keep it around for a long time. Also keep the last Backbone build ready to deploy behind a flag for a short while. Once real traffic has been quiet long enough, delete it and enjoy watching jQuery leave the bundle.

Looking back, a Backbone migration is mostly about finding everything your team built because Backbone didn't, and noticing how much of it React makes unnecessary. In our example, the page stack, the event bus, the view cleanup and the global singleton were all deleted rather than ported. In short: list the homegrown framework before you estimate, get onto a modern bundler first, mount React inside Backbone views, and write down what the app really does before you test both versions against it.

About MigrateX

MigrateX is our software and services platform for moving software, data and infrastructure from one technology to another. It brings automation and experienced engineers together, so the repetitive work gets done quickly and the tricky decisions get the human attention they need.

Everything in this guide comes from how we run Backbone to React projects with MigrateX. Here's what that looks like in practice:

Assessment. We scan your Backbone app and map the framework your team built around it: globals, event buses, controllers, cleanup code, template builds, AJAX hooks and jQuery plugins. You get a clear picture of where the effort really sits before anyone commits to a timeline.
Migration plan. Together with your team, we decide what each piece becomes in React, what can simply be deleted, which screens move first, and who owns the URL along the way.
Step-by-step migration. Automation handles the repetitive parts, like moving the build to a modern bundler, converting templates to JSX and porting parse() methods. Our engineers handle the parts that need judgement, like the data layer, routing and the views that bridge the two apps.
Proof that it works. We write down how your app behaves today, oddities included, and run the same Playwright tests against both apps. A screen only counts as migrated when it passes on both.
Handover and clean-up. We remove the bridge code, jQuery and the last Backbone packages, keep a way back until traffic is quiet, and leave your team with a React codebase they know and own.

What you get along the way:

No big-bang release. Your app keeps running and shipping features while the migration happens in the background.
Less risk. Shared tests, careful URL handling and a way back mean users don't notice the move, and you can pause at any point.
A team that's ready. We pair with your developers throughout, so they're comfortable with React long before the last Backbone view is gone.
More than front ends. The same approach covers other frameworks, like Angular and Ember, as well as data and infrastructure migrations.

To see the code behind this guide, visit github.com/cobuild-tech/migratex-examples. Still running a Backbone app that's been quietly doing its job for years? We'd love to hear about it. Tell us a little about your app through Contact Us, and we'll start with a free conversation about where the effort is likely to be.

References

Source code

CobuildX AI. migratex-examples: a responsive GitHub viewer built with Backbone 1.0, RequireJS, jQuery Mobile and Handlebars, and its React 18 rewrite, with a README describing the migration. https://github.com/cobuild-tech/migratex-examples/tree/main/backbone-react

Migration strategy

M. Fowler. StranglerFigApplication. martinfowler.com, 29 June 2004. https://martinfowler.com/bliki/StranglerFigApplication.html
M. Feathers. Working Effectively with Legacy Code. Prentice Hall, 2004.

Backbone and its stack

Backbone.js documentation. https://backbonejs.org/
Backbone.js. Change log (1.1.0 removed automatic this.options). https://backbonejs.org/#changelog
webpack. Module methods: AMD. https://webpack.js.org/api/module-methods/#amd
jQuery. jQuery maintainers continue modernization initiative with deprecation of jQuery Mobile. 7 October 2021. https://blog.jquery.com/2021/10/07/jquery-maintainers-continue-modernization-initiative-with-deprecation-of-jquery-mobile/

React and testing

React. createRoot. https://react.dev/reference/react-dom/client/createRoot
React. useSyncExternalStore. https://react.dev/reference/react/useSyncExternalStore
React. You Might Not Need an Effect. https://react.dev/learn/you-might-not-need-an-effect
React Router. https://reactrouter.com/
Playwright. https://playwright.dev/
Testing Library. Async methods (findBy queries). https://testing-library.com/docs/dom-testing-library/api-async/
MDN. Window: matchMedia() method. https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia

Libraries

TanStack Query. https://tanstack.com/query/latest
MSW (Mock Service Worker). https://mswjs.io/
Vite. https://vitejs.dev/

Originally published on the CobuildX AI blog.

Leaving Ember for React: What Your Conventions Were Hiding

Emmanuel R — Mon, 05 Oct 2026 09:48:08 +0000

Ember's great strength was that you didn't have to decide: the router loaded your data, Ember Data cached your records, the run loop handled timing and services found their way into components. When you move to React, every one of those becomes a decision your team owns. This guide is about finding those hidden conventions and choosing what replaces each one, from Ember Data and ember-concurrency to addons, acceptance tests and the React islands that let both frameworks share a page.

One thing we always liked about Ember is that you could open someone else's project and find your way around in minutes. Ember had already decided most things for you: where data gets loaded, how records are stored, how services reach your components. That works really well while you stay. The trouble starts when you try to leave, because you realise a big part of your app's behaviour doesn't live in your code at all. It lives in Ember.

Changing Handlebars templates into JSX isn't the hard part. Most developers get comfortable with it in a day or two. What takes time is finding all the small things Ember was doing in the background, and then deciding what should do that job in React. Hyrum's Law sums it up nicely: "all observable behaviors of your system will be depended on by somebody." In other words, your app relies on Ember in ways nobody ever wrote down.

Source code: all the examples in this post come from Inkwell, a small blogging app we first built in Ember 3.24 and then rebuilt in React 18. We kept the same routes, HTML, data-test-* selectors and acceptance tests. You can find both versions at cobuild-tech/migratex-examples. Inkwell was small, so we simply rewrote it. For bigger apps, we move step by step, and that's the approach this post describes.

Before You Start

Why leave, and when not to

When we ask teams why they're moving away from Ember, they almost never say Ember is bad. What they say is that everything around it has become harder. New hires usually know React and have to learn Ember from scratch. There's often an old addon in package.json that nobody has touched since 2019, and it's the reason the app is stuck two versions behind. And the tools they want to use, like design systems, chart libraries and payment widgets, all come with React examples first.

That said, it's worth being honest with yourself before you commit. A modern Ember app on Octane and Embroider, looked after by people who know it well, is a perfectly good place to be. If your real problem is a handful of outdated addons, upgrading them will cost far less than a migration. Move because the ecosystem keeps slowing you down, not just because the code feels old.

Inventory the hidden conventions

Before anyone gives an estimate, sit down and list everything Ember handles for your app by convention. Each item on that list is a place where React lets you pick the approach that suits you best. In our experience, this list tells you much more about how long the migration will take than counting components ever does.

Convention	What it does in Ember	Where to look
The resolver	Finds components, services and helpers by their file names	The `app/` folder layout, `@service foo` with no import
Route hooks	Loads data before the page shows, handles redirects, loading and error screens	`model()`, `beforeModel()`, `loading.hbs`, `error.hbs`
Ember Data	Fetches and caches records, keeps one copy of each, links related records	`this.store`, models, adapters, serializers
The run loop	Groups updates together and schedules async work	`later`, `debounce`, `next`, `schedule('afterRender')`
Initializers	Runs setup code when the app starts, before the first page	`app/initializers`, `app/instance-initializers`
Addons	Auth, translations, forms, tasks, mock APIs	`package.json`, often with their own rules on top

Here's a simple way to get a rough size. Search the code for @service, this.store, model(, later(, debounce( and task(, and count how many times each one shows up. It takes about ten minutes and shows you where the heavy work is.

Pay extra attention to initializers, because they're easy to overlook. Ember runs them automatically when the app starts, so they quietly read the login token, load feature flags and start analytics without anyone calling them. In React, startup code is explicit: it lives in the entry file or in a provider at the top of the app, where everyone can see it. That's a nice improvement, but it means each initializer needs to be moved on purpose. List them all early and give each one a clear home, so nothing like analytics gets left behind.

Get to Octane and Embroider first

If some parts of your app still use Classic Ember (Ember.Component, mixins, observers, or computed() with long lists of keys), upgrade them to Octane first, while they're still in Ember. It feels like extra work, but it usually saves time. Octane already works a lot like React: native classes, @tracked, clear @args and data that flows one way. That makes Octane components fairly easy to port. Classic components, with observers firing in the background, have to be fully understood before you can move them, and that's slow.

You don't have to do it all by hand. ember-native-class-codemod converts a lot of the old classes for you, and the Ember upgrade guide covers the rest. Do the same for the build and move to Embroider. It puts Ember on standard bundler tools, which makes it much easier to share packages, and later React components, between the two apps.

Running Ember and React Together

When you decide to leave Ember, it's tempting to stop everything and rewrite the whole app in one go. Most people who've tried that will tell you not to. Joel Spolsky famously called Netscape's full rewrite "the single worst strategic mistake that any software company can make", and that advice has held up for more than twenty years.

The safer path is what Martin Fowler calls the strangler fig. You add new code around the old app, piece by piece, until the old app is no longer needed. Slack rebuilt its desktop client this way. They set clear rules for how old and new code could talk to each other, and the first thing they shipped was the emoji picker.

You might think the natural unit is one route at a time. In practice, Ember routes are often large and nested, and a single one can take weeks. So we start even smaller. We drop React components into Ember templates as small "islands", while Ember keeps running the rest of the page.

Mounting React with a modifier

This is simpler than it sounds. An Ember modifier is given a DOM element, so it can start a React root inside it, and clean it up again when Ember removes that element:

// app/modifiers/react.js
import { modifier } from 'ember-modifier';
import { createElement } from 'react';
import { createRoot } from 'react-dom/client';

export default modifier((element, [Component], props) => {
  const root = createRoot(element);
  root.render(createElement(Component, props));
  return () => root.unmount();
});

<div {{react TodoList todos=@todos onComplete=this.complete}}></div>

This short version creates a fresh React root each time an argument changes, which is perfectly fine for your first island. For busier components, switch to a class-based modifier that keeps the same root and simply calls root.render with the new props. React then updates only what changed.

Sharing state across the boundary

Once a few islands are in place, they'll need to share data with the Ember side. Say your React island needs to show the cart, but the cart lives in an Ember service. Each framework tracks changes in its own way, so the cleanest fix is a tiny store that sits outside both of them:

// shared/cartStore.js
let items = [];
const listeners = new Set();

export const cartStore = {
  get: () => items,
  set(next) { items = next; listeners.forEach(l => l()); },
  subscribe(l) { listeners.add(l); return () => listeners.delete(l); },
};

React has a hook made for exactly this: useSyncExternalStore. Calling useSyncExternalStore(cartStore.subscribe, cartStore.get) keeps the island in sync with the store. On the Ember side, the cart service subscribes once and copies the value into a @tracked field, so the existing templates keep working as before. When the last Ember screen that uses the cart is gone, you delete the service, and the store is already in place for React.

As more islands join up, you can start moving whole routes. One option is a small shell in front of both apps that decides which one handles each URL. Another is to let React take over routing and treat the remaining Ember screens as the islands. Either way, plan for the shared setup to be temporary. Set a rough end date for it, so the team keeps moving towards a single React app.

Replacing Ember Data

Pull the store apart

If there's one part of an Ember migration that tends to take longer than planned, it's Ember Data. A single line like this.store.findRecord('todo', 1) does a lot of work. It fetches the record, cleans up its shape, caches it, connects it to related records, and makes sure every screen sees the same copy.

React keeps data fetching separate from the view layer, so you get to choose the right tool for each of those jobs. The trick is to stop treating the store as one big thing. Break it into pieces and pick a replacement for each one:

What Ember Data does	A good choice in React
Fetch and cache	TanStack Query, which handles caching, refetching and keeping data fresh
Translate the API shape	Your existing adapters and serializers, moved into plain, tested functions
One instance per record	Refreshing the right queries after a change, or a normalised cache like RTK Query if you need it
Relationships	Clear, separate requests, or letting the API return related data (`include`, GraphQL)
Dirty tracking and rollback	Form state with React Hook Form, kept close to the form

Serializers first, identity map maybe

We always start with the serializers. They're easy to overlook, but they hold years of knowledge about your API: renamed fields, unusual date formats, and that one endpoint that sends back a different shape for reasons nobody remembers. Move them into a plain module, add a few tests, and both the Ember and React sides can use them while the migration is in progress.

Next, ask yourself whether every record really needs to be one shared object. Many teams assume it does, simply because Ember always worked that way. In most apps, refreshing the right queries after a change keeps every screen up to date, and it's easier to follow when you're debugging.

If your app relies heavily on the store, there's one more option worth a look. WarpDrive, the next version of Ember Data, is being built to work outside Ember too. Spend an afternoon checking where its React support stands before you decide.

Async Without the Run Loop

If you ask an Ember developer about race conditions, they might not have much to say. That's because the run loop and ember-concurrency have been handling timing for them for years. For example, a search box that ignores old requests only takes a few lines:

searchTask = restartableTask(async (term) => {
  await timeout(250);
  return this.api.search(term);
});

Here, restartableTask cancels the previous search when a new one starts, timeout adds a short delay while the user types, and the task stops on its own if the user leaves the page.

In React, you get the same result by choosing the right tool for each kind of async work. For anything that fetches data, TanStack Query does this job really well. You use the search term as the query key, and it makes sure only the latest result is shown. It even gives you an AbortSignal to pass to fetch, so old requests can be cancelled:

const debounced = useDebouncedValue(term, 250);
const { data } = useQuery({
  queryKey: ['search', debounced],
  queryFn: ({ signal }) => api.search(debounced, { signal }),
  enabled: debounced.length > 0,
});

For things like polling, timers and animations, React keeps the setup and the cleanup together in the same effect, so it's easy to see what starts and what stops. The React team's guide You Might Not Need an Effect is a great read before you begin.

Then go through your ember-concurrency tasks one by one and think about what each one was really for. A restartable task usually becomes a query with the right key. A drop task becomes a button that's disabled while the request is running. An enqueue task becomes a small queue. And here's a nice surprise: many of those later() and schedule('afterRender') calls were only there to fix Ember timing issues. In React you often don't need them at all, so you can simply delete them.

Addons and Tests

Replacing the addons

It helps to think of each addon as its own small migration. The good news is that React has a strong library for almost every one of them, and in a few cases you can bring your existing work straight across:

Ember addon	React option	What you can keep
ember-intl	react-intl (FormatJS)	Your translation files, since both use the same ICU message format
ember-cli-mirage	MSW (Mock Service Worker)	Your fixtures; the handlers are written once and shared by both apps
ember-simple-auth	Your auth provider's SDK, or a small auth context	The session storage format, as long as you keep it the same
ember-concurrency	TanStack Query plus effects	Your cancellation rules, once they're written down
ember-power-select	Downshift, React Select or your design system	A fresh start; set aside some time for a design review
ember-page-title	`<title>` in components (React 19)	Your page title text

We'd suggest moving translations and mocks early, before most of the components. If both apps read from one shared set of ICU translation files, users see the same wording on every screen from day one. And once your mocks are in MSW, the same fake API works in React tests, in Ember tests and on your laptop.

Give authentication a little extra care. If both apps read the same session cookie or storage key, in the same format, users can move between Ember and React screens without ever noticing. That smooth hand-off is what makes a step-by-step migration feel invisible to your users.

Acceptance tests are the contract

One of the most valuable things an Ember team has is its acceptance tests. Years of them describe, in detail, what users can actually do. Treat them as the checklist the React version needs to pass.

The tests will look a little different on the React side. Ember tests usually call await settled(), which waits for the run loop, network requests and timers to finish. React Testing Library takes a more user-focused approach. It waits for what the user would actually see on screen, using findBy... queries. Here's the same test in both:

// Ember
await visit('/todos');
await click('[data-test-add]');
assert.dom('[data-test-todo]').exists({ count: 1 });

// React Testing Library
render(<Todos />);
await user.click(screen.getByRole('button', { name: /add/i }));
expect(await screen.findAllByRole('listitem')).toHaveLength(1);

Here's what has worked well for us. Pick the user journeys that matter most and write them as Playwright tests. Get them passing against the Ember app first, then run the exact same tests against React. When a journey passes on both, you know it's migrated. If it only passes on Ember, it still needs a bit more work, however finished the code looks. Keep your data-test-* attributes as they are, so both apps share the same test handles.

Finishing the Migration

Helping the team settle in

Code moves faster than habits, and that's completely normal. When Ember developers write their first React pull requests, we usually see the same three patterns. Each one has a simple React-friendly alternative:

Turning every service into a context. It's a natural first step, but most services don't need to be global. A plain module of functions, or state kept close to the components that use it, is often simpler.
Using effects the way observers were used. In React, a value that depends on other values can usually be calculated right during render, or updated in the event handler that changed it. The React docs on effects explain this really well.
Fetching data inside effects. People miss Ember's model() hook, and React has great options that feel just as familiar: router loaders or a query library like TanStack Query.

A little support goes a long way here. A short internal guide that shows your app's common patterns in both Ember and React pays for itself within weeks. Pairing an Ember expert with a React expert on code reviews helps even more, and both of them usually learn something new.

The removal checklist

You'll know the migration is finished on the day ember-source, ember-data and ember-cli are removed from package.json. Before you make that commit, run through a few quick checks:

Every route, including error, loading and "not found" pages, is now served by React.
Every initializer has a new home in React, or has been removed on purpose.
Session, feature flags and analytics all start from the React entry file.
The shared store, the island modifier and any other bridge code have been cleaned up.
Old URLs still work, with redirects in place for anything that changed.

Even after that, keep the last Ember build ready to deploy behind a flag for a short while. Real users have a way of finding the one thing nobody tested. TSB Bank is a well-known example. In 2018, a platform migration disrupted service for a large share of its 5.2 million customers, and UK regulators later fined the bank £48.65m. A front-end migration is much lower risk, but the lesson still applies: keep a way back until you're sure you won't need it. Once things have been quiet for long enough, delete it and enjoy the smaller bundle.

Looking back, moving from Ember to React is mostly about making clear choices for the things Ember used to handle behind the scenes: loading data, caching, async timing and startup code. Your team now decides how each of these works, which means a bit more effort at the start and a cleaner, easier-to-follow app at the end.

If we had to sum it up in a few lines: list the conventions before you estimate, get to Octane before you port, start with small islands, and give the data layer, addons and tests the same care as the components. The JSX part will take care of itself.

About MigrateX

Everything in this guide comes from how we run Ember to React projects with MigrateX. Here's what that looks like in practice:

Assessment. We scan your Ember app and build the inventory described above: services, store usage, route hooks, run loop calls, initializers and addons. You get a clear picture of where the effort really sits before anyone commits to a timeline.
Migration plan. Together with your team, we decide what each convention becomes in React, which screens move first, and how Ember and React will share state, sessions and translations along the way.
Step-by-step migration. Automation handles the repetitive parts, like converting templates, porting serializers and setting up MSW mocks. Our engineers handle the parts that need judgement, like data layer design, async behaviour and the islands that bridge the two apps.
Proof that it works. Your most important user journeys run as Playwright tests against both apps. A screen only counts as migrated when it passes on both, so progress is something you can see, not just something you're told.
Handover and clean-up. We remove the bridge code and the last Ember packages, keep a way back until traffic is quiet, and leave your team with a React codebase they know and own.

What you get along the way:

No big-bang release. Your app keeps running and shipping features while the migration happens in the background.
Less risk. Shared tests, a shared session and a way back mean users don't notice the move, and you can pause at any point.
A team that's ready. We pair with your developers throughout, so they're comfortable with React long before the last Ember screen is gone.
More than front ends. The same approach covers other frameworks, like Angular and Backbone, as well as data and infrastructure migrations.

To see the code behind this guide, visit github.com/cobuild-tech/migratex-examples. Planning a move from Ember, or already partway through? We'd love to hear about it. Tell us a little about your app through Contact Us, and we'll start with a free conversation about where the effort is likely to be.

References

Source code

CobuildX AI. migratex-examples: Inkwell, an Ember 3.24 RealWorld blogging app, and its React 18 rewrite. https://github.com/cobuild-tech/migratex-examples/tree/main/ember-react

Migration strategy and case studies

H. Wright. Hyrum's Law. https://www.hyrumslaw.com/
J. Spolsky. Things You Should Never Do, Part I. Joel on Software, 6 April 2000. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
M. Fowler. Strangler Fig Application. martinfowler.com. https://martinfowler.com/bliki/StranglerFigApplication.html
C. Jackson. Micro Frontends. martinfowler.com, 19 June 2019. https://martinfowler.com/articles/micro-frontends.html
Slack Engineering. When a rewrite isn't: rebuilding Slack on the desktop. 22 July 2019. https://slack.engineering/rebuilding-slack-on-the-desktop/
Bank of England. TSB fined for operational resilience failings. December 2022. https://www.bankofengland.co.uk/news/2022/december/tsb-fined-for-operational-resilience-failings

Ember

Ember.js. Upgrading to Octane. https://guides.emberjs.com/release/upgrading/current-edition/
ember-native-class-codemod. https://github.com/ember-codemods/ember-native-class-codemod
Embroider: modern build tooling for Ember. https://github.com/embroider-build/embroider
ember-modifier. https://github.com/ember-modifier/ember-modifier
Ember.js. Ember Data. https://guides.emberjs.com/release/models/
WarpDrive (the successor to Ember Data). https://github.com/emberjs/data
ember-concurrency. https://ember-concurrency.com/

React and testing

React. useSyncExternalStore. https://react.dev/reference/react/useSyncExternalStore
React. You Might Not Need an Effect. https://react.dev/learn/you-might-not-need-an-effect
React. . <a href="https://react.dev/reference/react-dom/components/title">https://react.dev/reference/react-dom/components/title</a></li> <li>React Router. Data loading. <a href="https://reactrouter.com/">https://reactrouter.com/</a></li> <li>Testing Library. Async methods (<code>findBy</code> queries). <a href="https://testing-library.com/docs/dom-testing-library/api-async/">https://testing-library.com/docs/dom-testing-library/api-async/</a></li> <li>Playwright. <a href="https://playwright.dev/">https://playwright.dev/</a></li> </ul> Libraries <ul> <li>TanStack Query. <a href="https://tanstack.com/query/latest">https://tanstack.com/query/latest</a></li> <li>React Hook Form. <a href="https://react-hook-form.com/">https://react-hook-form.com/</a></li> <li>FormatJS. react-intl. <a href="https://formatjs.github.io/docs/react-intl/">https://formatjs.github.io/docs/react-intl/</a></li> <li>MSW (Mock Service Worker). <a href="https://mswjs.io/">https://mswjs.io/</a></li> </ul> <hr> Originally published on the <a href="https://cobuildx.ai/blog/ember-to-react-migration-guide">CobuildX AI blog</a>.

Moving from Angular to React: A Practical Guide

Emmanuel R — Mon, 05 Oct 2026 09:37:31 +0000

If you've spent time in Angular, you're used to a framework that makes most of the decisions for you. Templates, dependency injection, routing and forms all come in the box. React gives you much less: it's a library for building components, and routing, shared state and how you structure the app are left to you. That difference is why moving between them takes more than rewriting syntax. We ported large applications from Angular to React, and this is what we learned along the way: how to pick a strategy, how Angular's ideas map onto React's, and how to make the move without breaking things for your users.

Most Angular-to-React migrations don't fail on a tricky hook or a missing library. They fail on a decision made in the first week: how the move should happen at all.

So before we touched a single component, we had to answer a risk question rather than a technical one. Rewrite the whole thing in one go, or move it across in pieces while both versions keep running? Most of what follows depends on that answer.

Source code: the examples here come from a small todo app we built twice, once in Angular 14 and once in React 19, with the same features, styling and tests. Both versions are on GitHub at cobuild-tech/migratex-examples [1]. The app is small enough that we did it as a full rewrite. The incremental advice below is what we follow for bigger applications.

Choosing the Strategic Approach

The full rewrite

In a full rewrite you leave the old application alone and build a new one next to it, feature by feature. On a chosen day, traffic switches over and the old app is retired.

For a small, low-stakes app, that's fine. It's what we did with the todo app: two components, one service, no real users depending on it. For anything larger it hides a nasty risk. The team can spend months writing code that no real user ever touches, and the feedback only arrives at the end, which is the most expensive moment to find out you misunderstood something. Joel Spolsky made the classic case against big rewrites back in 2000 [3], and most of it still holds.

The business doesn't pause while you do this, either. Feature requests keep coming, so each one gets built twice (once in the old app to keep it alive, once in the new one), or it waits until after the cutover. Nobody enjoys being the one to explain that to a product manager.

The incremental approach

An incremental migration takes the opposite view. The old app is never frozen and never swapped out in one go. It gets replaced piece by piece, with both versions serving real users at the same time.

The industry name for this is the Strangler Fig pattern [2], after a vine that starts small on a host tree and slowly grows around it, until the tree isn't needed any more and only the fig is left standing.

In software, the vine is a thin routing layer. For each route (or even each request) it decides whether the old system or the new one answers. More routes move across over time, until the old system has nothing left to serve and you can switch it off.

For almost anything with real users, this is the approach we'd pick, because every step is small and you can undo it. A route that moves gets tried by real people within days, not months. If it breaks, the router sends that route back to the old app while you fix it. The old app doesn't vanish overnight. It hands over one route at a time, until there's nothing left for it to do.

How to choose

The questions that decide it turn out to be about the organisation more than the code:

Do real users depend on the app today? If they do, a rewrite puts them at risk for the whole length of the project.
How big is it, and how many teams touch it? One team and a handful of screens can survive a rewrite. Several teams, dozens of screens and a steady stream of feature requests make incremental far more practical.
Can the business live with a feature freeze? A rewrite almost always needs one, because anything added to the old app mid-rewrite has to be built again in the new one.
Can both frameworks run side by side? Incremental depends on it, usually through a micro frontend shell [4].

Our rule of thumb: rewrite if the app is small, low-risk and owned by one team. Otherwise go incremental, and let the old system keep serving users while the new one gradually takes over.

Mapping What We Already Knew

What surprised us once we started was how much Angular and React agree on. They solve mostly the same problems. They just use different mechanisms to do it.

So the work wasn't learning React from scratch. It was matching each Angular mechanism to its React counterpart, and resisting the urge to rebuild Angular's machinery inside React. Here's the mapping we ended up with. The official Angular [7] and React [13] docs cover each mechanism in more depth.

Templates

Open an Angular component next to a React one and the first thing you notice is the file count: two files against one. It's tempting to call that a formatting difference and move on. It's more than that.

Same screen, two ways of writing it

To keep the comparison honest, we built the same todo app twice (source on GitHub [1]), once in each framework, with identical behaviour and identical styling. Here's the single todo item from each.

In Angular, the logic lives in a TypeScript class, and a decorator points it at a separate HTML file:

@Component({
  selector: 'todo-item',
  templateUrl: './todo-item.component.html',
})
export class TodoItemComponent {
  @Input() title = '';
  @Input() isDone = false;
  @Output() onComplete = new EventEmitter<string>();
}

<li class="todo-item {{ type }} {{ isDone ? 'done' : '' }}">
  <div class="checkbox" (click)="handleClickCheck()"></div>
  <p>{{ title }}</p>
</li>

In React, it's one function that returns the markup:

export function TodoItem({ title, type, isDone, id, onComplete }) {
  return (
    <li className={`todo-item ${type} ${isDone ? 'done' : ''}`}>
      <div className="checkbox" onClick={handleClickCheck} />
      <p>{title}</p>
    </li>
  );
}

Both render exactly the same <li>, and both are answering the same question: given this data, what should appear on the screen?

A template is a language. JSX is a value.

That's the difference that explains nearly everything else. An Angular template looks like HTML, but it's really Angular's own small language [8], which the compiler reads and turns into code. It has its own vocabulary for everything a screen needs:

What you need	Angular template	React JSX
Show a value	`{{ title }}`	`{title}`
Pass data to a child	`[title]="item.title"`	`title={item.title}`
React to an event	`(onDelete)="handleItemDelete($event)"`	`onDelete={handleItemDelete}`
Loop over a list	`*ngFor="let item of todoList"`	`todoList.map(item => ...)`
Show conditionally	`*ngIf="completeList.length"`	`completeList.length > 0 && ...`
Keep an input in sync	`[(ngModel)]="title"`	`value={title}` + `onChange`

Look at the right-hand column. React has no special syntax for loops or conditions, because JSX is just JavaScript [14]. {title} compiles to an ordinary function call that returns an object describing the UI. A loop is .map(), a condition is &&, and a variable is a variable.

A few practical things fall out of that. Scope works differently: an Angular template sees the fields of its class, linked by name across two files, while JSX sees whatever is in scope a few lines up, so TypeScript flags a misspelled name straight away.

Components are found differently, too. <todo-item> only works in Angular because TodoItemComponent is listed in the module's declarations. <TodoItem> works in React because it was imported at the top of the file. There's no registry, just imports.

Talking back to the parent gets simpler. Angular needs @Output(), an EventEmitter and .emit(). In React, onComplete is just a prop that happens to be a function, and the child calls it.

And because JSX is a value, you can keep markup in a variable, return it early or pass it to another component, which you can't do with a template file. The smaller renames follow from the same idea: class becomes className, image paths become imports, and trackBy [11] becomes key [15]. Our Angular trackById method simply disappeared. In React it's key={item.id} on the list item.

Which do we prefer?

For this kind of work, we lean towards JSX: one file, one language, and TypeScript checking the markup and the logic together. But Angular's constraint deserves credit. Its templates make it hard for business logic to creep into the view, and nothing in JSX stops a render function from filling up with logic. In React, keeping components clean is a team habit, not a framework rule.

What this means for a migration

Porting a template isn't a line-by-line translation of directives. It's closer to rewriting a small program in another language: *ngFor becomes a map, *ngIf becomes an expression, @Output becomes a callback. The screen that comes out should be identical, and in our todo app it is.

The more useful question isn't "what's React's version of this directive?" It's "what is this template trying to show, and how would I say that in plain JavaScript?"

Two-way binding

In Angular, [(ngModel)] [9] keeps a form field and a piece of data in sync in both directions. Type in the input and the class field updates; change the field in code and the input updates. In the todo app, the title box is one line:

<input name="title" [(ngModel)]="title" />

That "banana in a box" syntax is really two bindings folded together. [ngModel] pushes the value down into the input, and (ngModelChange) pushes every change back up into the class.

React only gives you the first half. Data flows one way, from state down to the screen, and you write the way back yourself with a controlled input [16]:

<input value={title} onChange={e => setTitle(e.target.value)} />

Yes, it's more typing. What you get for it is traceability. In Angular, title can change from the template, from the class, or from anything else bound to that field, and none of those paths are visible from the input. In React, the only way title changes is through setTitle. Search for it and you've found every place the data can change.

Who is allowed to change the data?

That's really the whole difference. With two-way binding, both sides can: the class writes title, the input writes title, and the framework quietly keeps them in sync. It's like a shared document that two people are editing at once. Convenient, until something looks wrong and you have to work out who changed it.

With one-way data flow, only the state can. The screen is just a picture of that state. The input never changes title itself; it reports what the user typed through onChange, and the state decides what to do with it. One person owns the document, and everyone else sends suggestions.

Question	Two-way binding (Angular)	One-way data flow (React)
Who owns the data	Shared by the view and the class	The state, and only the state
How the view changes data	Writes to it directly	Asks, through an event handler
Where to look when a value is wrong	The template, the class, and anything bound to them	Every call to the setter
Best fit	Simple forms with a few fields	Screens where inputs depend on each other

For a simple form with a few fields, two-way binding is genuinely nicer to write. Once inputs start depending on each other, though, we'd take one-way flow every time. React makes that choice for you, and a migration is a good moment to get used to it.

Dependency injection

Angular hands services to components through the constructor [10]. The DI container creates the service, decides how long it lives, and gives the same instance to everyone who asks for it. In the todo app, the component just declares what it needs:

constructor(private localStorageService: LocalStorageService<ToDo>) {}

React has no container like that, so what happens to the service?

When we opened LocalStorageService, the answer was a bit of an anticlimax. It was a generic class with an empty constructor and two methods, getItem and setItem. The class existed mainly so the DI system had something to inject. In React, those became two exported functions in a nine-line file:

import { getItem, setItem } from '../services/localStorageService';

Nothing to register, no lifetime to manage. Where logic also needs to hold state or run side effects, it becomes a custom hook instead [19]. That's where the todo state went: everything AppComponent used to hold now lives in useTodos(), which App calls like any other function.

Don't rebuild Angular's architecture in React just because the old app had it. Work out what the service was actually doing, and move only that.

State management

In Angular, state usually lives in one of two places: inside a component, or in a shared service that DI hands to whoever needs it. Because DI is built in, sharing state is almost free, and a lot of Angular apps put most of their state into services from day one.

React starts from the opposite default. State begins local, inside the component, with useState. It only moves when other components need it: first up to the nearest parent they share [17], then into React Context [18] if they're far apart in the tree. Only when that stops being enough do you reach for a library such as Redux [24] or Zustand [25].

The progression looks like this:

Why Angular reaches for services

Angular was built around dependency injection from the start, and a service marked providedIn: 'root' is a single shared instance for the whole app. That makes it a natural home for shared state. Our todo app keeps its state in AppComponent, but a small shared store in Angular 14 typically looks like this:

@Injectable({ providedIn: 'root' })
export class TodoStore {
  private todos = new BehaviorSubject<ToDo[]>([]);
  readonly todos$ = this.todos.asObservable();

  add(todo: ToDo) {
    this.todos.next([...this.todos.value, todo]);
  }
}

Any component that asks for TodoStore in its constructor gets the same instance, and so the same list. Sharing takes one line.

Why React didn't follow

React started from a different idea: the UI is a function of state. A component is just a function that runs again whenever its state or props change. There's no container holding shared instances, so state lives where it's rendered, and sharing it is something you do on purpose.

In our React version, all the todo state lives in the useTodos() hook. App calls it once, and each TodoItem gets only what it needs through props. If two components far apart in the tree needed the same data, Context would let them share it without passing props through every level. The todo app is too small to need it, but it would look like this:

const TodosContext = createContext(null);

function App() {
  const todos = useTodos();
  return (
    <TodosContext.Provider value={todos}>
      <Page />
    </TodosContext.Provider>
  );
}

function CompletedCount() {
  const { completeList } = useContext(TodosContext);
  return <span>{completeList.length} done</span>;
}

Anything bigger than that, React leaves to libraries such as Redux or Zustand. That's deliberate: the core stays small, and each team picks the tool that fits.

Watch out for in-place updates

One porting detail is easy to miss. Angular's handleSubmit adds a todo with this.todoList.push(...) and then saves this.todoList to localStorage. Angular's change detection is happy with an array being changed in place. React isn't. Push onto an array held in state and nothing re-renders [20], and reading a state variable straight after calling its setter still gives you the old value [21].

So every handler in useTodos() builds the next list first ([...todoList, newTodo] rather than push), passes it to the setter, and saves that same list to localStorage. It's a small change, but it's the kind that passes a quick review and then shows up as a list that doesn't update.

Pros and cons

Trade-off	Angular: shared services	React: local-first
Pros	Sharing is built in and takes one line. There is one obvious place for shared data. Every team follows the same pattern.	State sits next to the code that uses it. Data flow is easy to trace. Nothing gets shared by accident.
Cons	It is easy to share state that never needed sharing. Any component that injects the service can change it. It is hard to see which components depend on a service.	Passing props through many levels ("prop drilling") gets tedious. You have to choose a tool for app-wide state. Different teams may choose differently.

Coming from Angular, the temptation is to reach for the biggest tool first and set up a global store on day one. Resist it. Use the smallest tool that solves today's problem, and move up only when you actually feel the pain of not having something bigger. The todo app never needed more than useState.

Routing

Angular ships its router as part of the framework [12]. React doesn't ship one at all. You add a library such as React Router [22], or pick a framework like Next.js [23] if you also want server rendering.

It sounds like a bigger difference than it is. In both, a URL should resolve to a screen; what changes is the configuration and the tooling around it, not how you think about navigation. (The todo app has no routes at all, so this was the one part of the mapping we didn't need.)

How the Migration Should Actually Happen, Step by Step

With the strategy chosen and the concepts mapped, the migration itself followed a fixed order:

The order matters more than it looks. Most of the risk in a migration comes from skipping a step, or doing them out of sequence.

If the steps look familiar, it's because they're the Strangler Fig pattern in practice. Step 2 builds the routing layer, the "vine" that decides who answers each route. Step 3 moves routes across one at a time. Step 4, plus the rollback plan further down, makes sure every move can be undone. That combination is where the reliability comes from:

a mistake affects one route, not the whole application
every migrated piece meets real users within days, not at the end of a months-long rewrite
the router can send a route back to the Angular version in minutes if something goes wrong
new work carries on in whichever framework currently owns that route, so there's no feature freeze

1. Set up the tooling

Before a single feature moves, the new React project should build, test and deploy, even if all it contains is one empty page. For the todo app, that meant Vite [26], React 19 and TypeScript, with three scripts in package.json that every change goes through: npm run lint, npm test and npm run build. Not much, but it meant the React side was checked the same way from the first commit.

For a production app, you'd want the full set in place before any real code lands:

Linting and formatting. A linter (we used oxlint [29]; ESLint is the common alternative) plus a formatter like Prettier, so style never has to come up in review.
Type checking. tsc runs as part of the build, so a wrong prop or a missing field fails straight away instead of in production.
Tests. Vitest [27] and Testing Library [28] for unit and component tests. For the side-by-side check in step 4, an end-to-end tool such as Playwright [30] can run the same user journey against both versions.
CI. Lint, type checks, tests and a build on every pull request, deployed somewhere real, ideally with a preview URL for each branch.
Observability. Error tracking (Sentry, for example), Core Web Vitals and logs, all tagged by framework, so you can tell which side a problem came from.
Feature flags. The switch [6] that later lets you send a route back to Angular. Far easier to add now than in the middle of an incident.

This pipeline is the safety net everything later depends on. Retrofitting it once the real code exists is harder, and riskier.

2. Decide how old and new will live together

In an incremental migration, Angular pages and React pages have to live on the same site at the same time, sometimes for months. So how do users move between them without noticing?

This is where a micro frontend architecture earns its keep. A thin shell application owns the routing decision and hands each route to whichever framework currently owns it [4]. Frameworks such as single-spa [5] exist to do exactly this wiring.

Not every project needs this. A small app can do without it, and a full rewrite (like our todo app) skips this step entirely. It pays off in larger applications, with many teams and many screens, where the migration has to happen without stopping feature work.

3. Migrate from the bottom up

Start with the smallest, most isolated pieces (a button, a form field, a single list item) and only move up once they're proven. In a real codebase, "smallest" isn't always obvious, and that's where a dependency graph helps.

Build a dependency graph (a DAG) first

Before moving anything, map which pieces depend on which. Every component and service is a node, with an arrow from A to B whenever A uses B. Code shouldn't depend on itself in a loop, so the result is a directed acyclic graph, or DAG, and the migration order falls straight out of it: start with the nodes that depend on nothing, and only move a node once everything it depends on has moved.

Ours was small enough to draw by hand:

AppComponent
 ├── uses → TodoItemComponent     (depends on nothing)
 └── uses → LocalStorageService   (depends on nothing)

TodoItemComponent and LocalStorageService depend on nothing, so they went first and became TodoItem and localStorageService.ts. AppComponent depends on both, so it went last, once there was nothing left underneath it.

For a larger app you won't draw this by hand. Tools such as madge [31] or dependency-cruiser [32] generate the graph from source, for example:

npx madge --image graph.svg --extensions ts src/app

Two things to watch for. If the tool finds a cycle, where A uses B and B also uses A, break it before migrating, usually by pulling the shared part into its own small module. And keep the graph up to date as you go. It doubles as a progress chart, with migrated nodes marked as done.

Going top-down usually means touching everything at once, which throws away most of the safety you chose an incremental migration for.

4. Verify constantly, not only at the end

After each piece moved, we asked two questions: does it behave the same, and does it look the same?

Tests answer the first. We ported every Angular spec (Jasmine and Karma) to Vitest and React Testing Library, scenario for scenario, so coverage never dropped, and the React version finishes with all 13 tests passing. The second question needs a person. We ran both apps side by side in a browser, added, prioritised, completed and deleted todos in each, and compared screenshots.

One small decision made that easier: both versions use the same localStorage keys (todoList and completeList) and the same data shape, so either app can read the other's todos in the same browser. It's a cheap trick, and worth copying.

Don't save either check for the end. A problem found one piece later is cheap to fix. Fifty pieces later, it isn't.

Deprecation and Rollback

When can the old code go? Not when the new code compiles, and not when the tests pass. For a production app, only after the React version has run under real traffic for a while without surprises.

Each piece goes through the same four stages: migrated to React, verified in production, old code kept but unused, and finally old code removed. Until that last stage, keep a way back, whether that's a feature flag [6] or a route-level toggle that sends users to the Angular version if something slips past the tests.

Keeping that path costs effort, and once everything looks fine it's tempting to rip it out early. Don't. The point of a rollback is that you don't know when you'll need it, and the one time you do, it pays for itself.

Looking Back

The migration was never really about turning Angular syntax into React syntax. The harder and more useful part was understanding what the existing app actually did, finding the idea behind each Angular mechanism, and deciding how that idea should live in React.

It got much easier once we stopped thinking of it as one big rewrite and started treating it as a series of small decisions. Understand what you have before changing anything. Map the concepts deliberately instead of copying the old architecture. Move in small pieces, and check each one before the next. And let go slowly: keep a way back until the new system has earned the trust to stand on its own.

About MigrateX

Everything in this guide comes from how we run Angular to React projects with MigrateX. Here's what that looks like in practice:

Assessment. We scan your Angular app and map what it really relies on: components, services and the DI tree, two-way bindings, NgRx or service-based state, routes and guards, and third-party modules. You get a clear picture of where the effort really sits before anyone commits to a timeline.
Migration plan. Together with your team, we choose between a full rewrite and an incremental move, decide what each Angular mechanism becomes in React, and build the dependency graph that sets the order screens move in.
Step-by-step migration. Automation handles the repetitive parts, like converting templates to JSX, porting Jasmine specs to Vitest and setting up the tooling. Our engineers handle the parts that need judgement, like state design, replacing services and the shell that lets Angular and React share one site.
Proof that it works. Every ported test passes, and your most important user journeys run as Playwright tests against both apps. A screen only counts as migrated when it passes on both, so progress is something you can see, not just something you're told.
Handover and clean-up. We remove the shell routing and the last Angular packages, keep a way back until traffic is quiet, and leave your team with a React codebase they know and own.

What you get along the way:

No big-bang release. Your app keeps running and shipping features while the migration happens in the background.
Less risk. Shared tests, feature flags and a way back mean users don't notice the move, and you can pause at any point.
A team that's ready. We pair with your developers throughout, so they're comfortable with React long before the last Angular screen is gone.
More than front ends. The same approach covers other frameworks, like Ember and Backbone, as well as data and infrastructure migrations.

To see the code behind this guide, visit github.com/cobuild-tech/migratex-examples. Planning a move from Angular, or already partway through? We'd love to hear about it. Tell us a little about your app through Contact Us, and we'll start with a free conversation about where the effort is likely to be.

References

Source code

CobuildX AI. migratex-examples: an Angular 14 todo app and its React 19 rewrite, with a README describing the migration. https://github.com/cobuild-tech/migratex-examples/tree/main/angular-react

Migration strategy

M. Fowler. Strangler Fig. martinfowler.com, 22 August 2024 (first published 2004). https://martinfowler.com/bliki/StranglerFigApplication.html
J. Spolsky. Things You Should Never Do, Part I. Joel on Software, 6 April 2000. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
C. Jackson. Micro Frontends. martinfowler.com, 19 June 2019. https://martinfowler.com/articles/micro-frontends.html
single-spa. Getting started overview: a framework for running several front-end frameworks in one app. https://single-spa.js.org/docs/getting-started-overview
P. Hodgson. Feature Toggles (aka Feature Flags). martinfowler.com, 9 October 2017. https://martinfowler.com/articles/feature-toggles.html

Angular documentation (v17)

Angular. Introduction to the Angular docs. https://v17.angular.io/docs
Angular. Template syntax. https://v17.angular.io/guide/template-syntax
Angular. Two-way binding ([(ngModel)]). https://v17.angular.io/guide/two-way-binding
Angular. Understanding dependency injection (including providedIn: 'root'). https://v17.angular.io/guide/dependency-injection
Angular. Built-in directives (*ngFor and trackBy). https://v17.angular.io/guide/built-in-directives
Angular. Common Routing Tasks (the Angular router). https://v17.angular.io/guide/router

React documentation

React. Getting Started (legacy docs). https://legacy.reactjs.org/docs/getting-started.html
React. Writing Markup with JSX. https://react.dev/learn/writing-markup-with-jsx
React. Rendering Lists (the key prop). https://react.dev/learn/rendering-lists
React. : controlling an input with a state variable. https://react.dev/reference/react-dom/components/input
React. Sharing State Between Components (lifting state up). https://react.dev/learn/sharing-state-between-components
React. Passing Data Deeply with Context. https://react.dev/learn/passing-data-deeply-with-context
React. Reusing Logic with Custom Hooks. https://react.dev/learn/reusing-logic-with-custom-hooks
React. Updating Arrays in State. https://react.dev/learn/updating-arrays-in-state
React. State as a Snapshot. https://react.dev/learn/state-as-a-snapshot

Libraries and tooling

React Router. https://reactrouter.com/
Next.js documentation. https://nextjs.org/docs
Redux. https://redux.js.org/
Zustand. https://zustand.docs.pmnd.rs/
Vite. Getting Started. https://vite.dev/guide/
Vitest. https://vitest.dev/
Testing Library. React Testing Library. https://testing-library.com/docs/react-testing-library/intro/
Oxc. Oxlint. https://oxc.rs/docs/guide/usage/linter
Playwright. https://playwright.dev/
madge: dependency graphs for JavaScript and TypeScript. https://github.com/pahen/madge
dependency-cruiser: validate and visualise dependencies. https://github.com/sverweij/dependency-cruiser

Originally published on the CobuildX AI blog.