Incremental migration

An incremental migration moves an application to a new technology in small releasable steps while the product stays in production the whole time.

An incremental migration replaces the old technology piece by piece. After each step the application is deployed and used. There is no long period in which new code waits unreleased. Old and new run side by side, connected by some kind of bridge, until the last old piece is removed.

For a frontend, the usual bridges are:

• A hybrid application, in which both frameworks run in one page through ngUpgrade.
• A shell that sends some URLs to the old application and some to the new one.
• Web components that carry new features into old pages.

Example

A team migrating from AngularJS plans by route. The first sprint sets up the Angular build and the bridge, with no visible change. The second sprint moves the login screen. The third moves the customer list. Each sprint ends with a production release. Progress is measured as the share of routes served by the new code, and management sees that number every two weeks.

Common misunderstanding

Incremental is sometimes taken to mean slow or without an end. The total effort is often similar to that of a rewrite, and it can be higher because of the bridge code. What changes is the risk profile. Problems appear early and in small doses, value reaches users continuously, and the project can be paused without losing the work already done.

The real danger is stopping when most of the work is done. The remaining screens keep the old framework, the old build and the bridge alive. Define the finish line at the start: the old framework removed from the bundle. The guide How to migrate AngularJS to Angular without downtime describes the steps.

Related terms

• Strangler fig pattern
• Hybrid application (AngularJS + Angular)
• Feature flag
• Big-bang rewrite