Migrating users need the delta, not a from-zero lesson

What it is

People coming from an old version, a competitor, or an offline process are not blank. They bring a working mental model: what objects are called, where step one lives, which actions are irreversible. Re-onboarding should teach the delta—which step moved, which rule changed, which old method will now fail—not a class that treats the product as never seen. From-zero teaching unpacks skills they already have; migrants hear “the system thinks I can’t,” and the few things that actually changed are buried in intro sentences.

Why it happens

Skill transfer depends on structure that can be aligned. People guess the new UI with the old model: export should still live near File. Right guesses make migration almost free; wrong guesses make the failure itself the strongest delta signal, but the failure must be explained as “this changed,” not “you don’t know how.” A from-zero course follows a novice’s ignorance order, not the old model’s conflict points, so conflicts arrive late, wrapped as ordinary intro, and cannot be used to revise the model. A second layer of delta copy is scope: list only what changed; stay silent on what did not. Silence lets old skills keep working, the main asset of migration. Narrating the unchanged too is a declaration that old skills are void; people go into unnecessary full alert, slow down, and make more errors.

Studying it

Recruit people still on the old version or a named competitor; compare a full novice tour, a short change-only note, and silence. Tasks should be the set they already perform in the old environment.

Independent variables: whether copy is organized as delta, whether unchanged parts are marked as unchanged. Dependent variables: first wrong click driven by old habit, time to correct, completion time, feeling treated as a novice.

Lab participants who never saw the old version turn this into ordinary first use. Migration studies must screen for a living old model. Competitor deltas should align on tasks, not on control appearance.

Where it stops holding

When the old model cannot align with the new product at all (category change, object system rebuilt), the delta list becomes a from-zero course in disguise; say outright “this is a different method” and keep a very short new-path demo, rather than pretending the same product was tweaked. Pure new users have no model to migrate; delta-only copy leaves them without a base. When an admin migrates a population, delta copy should face the operator’s model, not the blank profile of the impersonated account.

Applying it

• List conflict points along the old task path (entry moved, default changed, old shortcut dead); migration copy covers only those points.
• Stay silent on unchanged capabilities; do not file them into a “welcome to the new version” feature list.
• Write “it used to be in File, now it sits by the object” at the place the old habit will fail, not as an abstract preview at the door.
• Verify with someone still on the old version doing a familiar job. Record the first wrong click; if copy does not aim there, replace the from-zero tour with a delta sentence at that spot, and compare correction time and “treated as a novice” reports.

Related

• Within the group: 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 · H2.11.4 A migration window needs a comparison or a way back
• Adjacent: H2.01 First-use Guidance · H2.03 Progressive onboarding · G1.08 Terminology consistency
• Search terms: delta onboarding · mental model transfer · what changed