Migrating Backbone, Knockout and old Ember applications

AngularJS gets most of the attention, and it is far from the only legacy framework. Backbone, Knockout and early Ember apps follow the same migration principles, with different seams and different traps.

The same principles apply

Whatever the legacy framework, a safe migration has the same shape:

1. Inventory the screens, the shared code and the third-party plugins. Delete what is unused.
2. Choose a seam where old and new code meet.
3. Share the session, the navigation and the styles, so users see one product.
4. Move one screen or one region at a time, released behind a switch.
5. Delete the old version of each piece once the new one is stable.
6. Remove the legacy framework at the end.

This is the strangler fig pattern. What changes with each framework is where the seam can go and how much of the old code carries over.

The main difference from AngularJS

AngularJS has official upgrade tooling that lets it share one application with modern Angular. Backbone, Knockout and Ember have no equivalent bridge to Angular or React. Coexistence is built from general tools:

• Route-level switching at the server or proxy, where some URLs go to the new app.
• Custom elements, where new components are mounted inside old pages.
• A thin shared layer for session and events, written by your team.

That is more plumbing to build yourself. In exchange, the two sides stay loosely coupled, which makes the final removal easier.

Backbone

What these apps look like. Backbone gives models, collections, views, a router and events, and leaves the rest to you. Every Backbone app therefore has its own architecture. Many add Marionette for structure. Views render templates by hand and update the DOM with jQuery.

What carries over

• Models and collections map well to typed services and plain data objects.
• The router is simple and coexists easily with another router, as long as each one owns distinct paths.
• The REST conventions of Backbone models usually mean the API is already clean JSON.

What needs care

• Views mix rendering, event handling and business rules. Read each one before estimating.
• The global event bus. Map who publishes and who listens before you move either side.

Typical seam. Custom elements inside Backbone views for the first pieces, then whole routes.

Knockout

What these apps look like. Knockout binds view models to HTML through data-bind attributes and observables. It is often found inside server-rendered pages, especially ASP.NET MVC applications, with one view model per page and no client-side router.

What carries over

• View models are already separated from the markup. Their observables and computed values translate naturally to component state, and to signals in current Angular.
• Each page is independent, which gives natural migration units.

What needs care

• Templates are server views with bindings inside. The server part and the client part must be separated, as in the guide for AngularJS with ASP.NET MVC.
• Custom binding handlers often wrap jQuery plugins. Each one needs a replace-or-wrap decision.
• Data is frequently injected into the page by the server. It needs JSON endpoints.

Typical seam. Page by page at the server. For large pages, component islands inside the page, as in the jQuery migration guide.

Ember 1.x and 2.x

What these apps look like. Ember is a full framework with strong conventions: its own router, its own data layer in Ember Data, its own build tool and a fixed project layout. Old Ember apps are usually real single-page applications with consistent structure.

An option the others do not have. Ember is still actively developed and has a documented upgrade path through its long-term support versions. If the team is happy with Ember, upgrading in place is a legitimate choice. It is a long road from 1.x, with many deprecations to clear, and it avoids a change of framework. Compare it honestly with a migration before deciding.

What carries over, if you leave Ember

• The route structure. Ember apps are organized by route, which gives a clear list of migration units.

What needs care

• Ember owns the whole page and the URL. Embedding pieces of another framework inside it is harder than with Backbone or Knockout.
• Ember Data shapes the API contract. Check whether the backend follows its conventions closely and what the new data layer must reproduce.

Typical seam. Route-level switching at the edge, with a shared session and a navigation bar that looks the same on both sides.

More in this section

• Migrating AngularJS that lives inside ASP.NET MVC
• Migrating AngularJS that lives inside Java and JSP
• How to keep teams shipping during a migration
• Measuring migration progress