Design a Migration Users Can Live Through

Systems & Architecture · deployment, process, trust

Updated 2026-08-04

Replace an old product one route at a time rather than all at once, which engineers call the strangler fig approach. A single cutover date means one missed behavior breaks everything and the only recovery is a full retreat.
Accept that the two systems will be visible at the same time. Users will cross between old and new screens mid-task, so the seams need designing rather than hiding.
Keep one thing constant across the boundary. Navigation, terminology, or the account switcher staying identical is what makes a mixed product feel like one product.
Move the pieces in an order that matches value, not architecture:

Start with a surface that is self-contained and low risk.
Then the surfaces people use most, once the pattern is proven.
Leave the deeply entangled workflows until last.

Give people a way back, and make it real. An opt-out that loses the work done in the new version is not an opt-out.
Say what changed on the screen where it changed. A release note nobody reads cannot substitute for a line of context at the moment someone finds the button missing.
Never ship the new version missing a feature people rely on and call it a preview. That is the fastest way to make the migration itself the thing users resist.
Set a visible end date for the old surface, and hold it. An indefinite "classic view" splits your product in two permanently and doubles every future decision.
Watch where people switch back. The route they return to is the list of what the new version has not earned yet.

A migration is not a launch, it is a period the product lives in, and the interface has to be designed for that period rather than for the day it ends.