Backbone to React Migration

Written by Backbone Tutorials Team

Last updated: June 2026 · 11 min read

A Backbone application does not have to be rewritten from scratch to become a React application. The two share more conceptual DNA than their syntax suggests, and a careful migration can run incrementally, with both frameworks living side by side in the same page while you move one piece at a time. The teams that get burned are usually the ones who try to flip a switch overnight; the teams that succeed treat it as a series of small, reversible steps.

This guide maps every Backbone concept to its React equivalent and lays out a migration path that never requires a big-bang rewrite.

Why teams migrate from Backbone to React

The motivation is rarely that Backbone stopped working. It is usually that the manual rendering and event wiring Backbone requires becomes a maintenance tax as the interface grows more dynamic.

The specific friction that triggers a move

In a large Backbone view, keeping the DOM in sync with the Model means writing and maintaining explicit render logic and event bindings, and subtle bugs appear when a re-render forgets a piece of state. React removes that work by deriving the DOM from state automatically, and the larger pull is usually the hiring pool and component ecosystem that come with it. Understanding why this tradeoff favours React is covered in MVC versus components.

Mapping Backbone concepts to React

Almost every Backbone primitive has a direct React counterpart, which is what makes incremental migration possible in the first place.

The concept-by-concept translation

A Backbone Model becomes component state or an external store entry. A Backbone View becomes a component, with its render method becoming the component's returned markup. A Collection becomes an array held in state. A Router becomes a routing library such as React Router. The mental model shifts from "tell the view to update" to "set the state and let React update," but the responsibilities line up cleanly.

// Backbone View
var UserView = Backbone.View.extend({
  render: function () {
    this.$el.html(this.model.get('name'));
    return this;
  }
});

// React component
function UserView({ user }) {
  return <div>{user.name}</div>;
}

The incremental migration strategy

The safest migration runs React inside the existing Backbone app, converting one view at a time rather than replacing everything at once.

Mounting React inside a Backbone view

A Backbone View can mount a React component into its element and unmount it when the view is removed. This lets you migrate a single widget, ship it, confirm it works in production, and move to the next one. The Backbone Router keeps controlling navigation while individual views become React internally, so the application is always shippable and no change is larger than one view.

var ReactBridge = Backbone.View.extend({
  render: function () {
    ReactDOM.render(<UserView user={this.model.toJSON()} />, this.el);
    return this;
  },
  remove: function () {
    ReactDOM.unmountComponentAtNode(this.el);
    Backbone.View.prototype.remove.call(this);
  }
});

Handling routing during migration

Routing is the last thing to migrate, not the first, because it is the spine that holds the half-converted application together.

Keeping one router in charge at a time

Running two routers simultaneously, the Backbone Router and React Router, leads to conflicts over who owns the URL. The cleaner path is to keep the Backbone Router authoritative until enough views are converted that flipping the whole routing layer to React Router becomes a single, well-understood change. Until that moment, React components live inside Backbone-routed views rather than owning routes themselves.

Moving data and sync logic

Backbone Models and Collections include server synchronisation through fetch and save, and that logic needs a new home in React.

Replacing Backbone sync with a data layer

React has no built-in sync, so the persistence logic moves to a data-fetching library or a small custom layer that calls the same REST endpoints the Backbone Models used. Because the API contract does not change, this is often a mechanical translation: the endpoint and request shape stay identical, only the calling code changes. Keeping the API stable during migration is what allows the frontend to change underneath it safely.

Common migration pitfalls

Most migration failures come from a handful of avoidable mistakes rather than any deep incompatibility between the frameworks.

What to watch for

The biggest pitfall is attempting a full rewrite instead of an incremental migration, which stops shipping value for months and risks losing edge-case behaviour the old code handled. Other traps include running two routers at once, duplicating state between Backbone Models and React state instead of choosing one owner per piece of data, and forgetting to unmount React components when their host Backbone view is removed, which leaks memory. Treating the migration as many small reversible steps, in the spirit of the wider modern frameworks cluster, avoids nearly all of them.

Read next: migrating Backbone to Vue, or the Modern Frameworks hub.