A migration window needs a comparison or a way back

What it is

For a stretch after a redesign ships, people need a way to confirm they can still do the old job: either a comparison (this step used to live here, now there) or a temporary return to the old version to finish the work. With neither, migration is a one-time cliff, and delta copy becomes an apology after the fact. This entry is escape and checking inside the migration window. It is not keeping old words, and not the ban on a forced newbie class.

Why it happens

Under pressure the old model is a production tool. Comparison externalizes the translation: people need not hold two maps in working memory; one look finishes this operation, internalization can wait. Rollback caps the risk: if the new UI cannot do it today, the old path still exists, and a deadline is not lost to the redesign. The window must be finite—endless rollback keeps the new UI from growing up and turns two implementations into permanent debt. The end date must be said in advance and reminded before it hits, or rollback vanishes on some Tuesday and becomes a second cliff. A comparison that lives only in a launch blog is absent at work time and is no comparison; it belongs on the conflicting UI, or as a summonable side-by-side. Rollback must also say which data is asymmetric (fields that exist only in the new version will drop), or rollback itself creates new loss.

Where it stops holding

Old behavior closed for safety (weak crypto, overly open sharing) cannot be a rollback option; the comparison should say “the old method is closed because….” A purely visual redesign with unchanged words and places makes both comparison and rollback too heavy; “looks different, same method” is enough. When regulation requires everyone on the new flow by a date, the rollback window must end before that date; the old version cannot still be open on compliance day. If the client cannot dual-stack, at least keep a read-only screenshot comparison or a downloadable old how-to; no checking surface at all is the cliff.

Applying it

• Inside the window, provide a findable “see differences from the old version” or a time-limited “use the old version,” in settings and the work area, not in the launch blog.
• State the window’s end date and remind before it; before rollback, say which new data will not come back.
• Stick comparison beside conflict points (a moved entry, a changed default), not as a long essay off the task.
• Verify by having an old-version user fail once on purpose in the new UI, then see whether comparison or rollback is reachable from that screen and the familiar job still finishes. If not, or if rollback drops data without warning, the window did not work.

Related

• Within the group: H2.11.1 Migrating users need the delta, not a from-zero lesson · H2.11.2 Keeping old terms and layout habits lowers migration cost · H2.11.3 Forcing a newbie tour angers people who already know the product
• Adjacent: H2.04 Skippable and replayable guidance · H8.06 Version history · H3.09 Crash and offline recovery
• Search terms: temporary rollback · old vs new · migration window