Term changes require global replacement and migration notes

What it is

Versioned terminology migration treats a rename as a change to concept mappings and the content ecosystem, not as one global replacement. The team maps affected surfaces, then plans a compatibility period, search aliases, user-facing migration explanations, and exit criteria. Migration covers product-controlled interfaces and content while explicitly identifying historical snapshots, external material, and user-generated content that cannot or should not be rewritten.

Why it happens

An old term persists in user memory, bookmarks, queries, documentation links, support records, analytics events, and automation. Updating only the current interface can make the feature appear missing; immediately deleting every old term erases cues needed to interpret historical material. An impact graph connects concept, term, string or page, search index, support macro, analytics and integrations, and accountable owner. During compatibility, old-to-new links help users rebuild the mapping and aliases preserve discovery. Versions and exit signals keep “formerly known as” messages from becoming permanent noise.

Studying it

Before migration, quantify old-term occurrences, searches, task entry points, and external dependencies across touchpoints. Use logs and interviews to separate users who still rely on the old name from systems that incorrectly continue producing it. After launch, segment by user tenure and channel to observe old-query success, new-name recognition, task completion, related contacts, and errors. Retire compatibility messaging based on those signals and risk, not a universal two-release rule. For immutable history or third-party material, test whether aliases and bridge pages reliably lead users to the current concept.

Where it stops holding

A global migration does not authorize rewriting user-authored text, audit records, signed material, historical versions, or third-party tutorials. Preserve them and bridge names at retrieval or display time. An old name implicated in security, law, or another active concept must not become an unconditional alias. API names, event names, and persistent identifiers may need separate compatibility and deprecation plans rather than following a UI-label replacement. The termbase records term state and version; stale TM segments need marking or invalidation; a style guide governs expression and cannot orchestrate a migration.

Applying it

• Build an impact graph and change record with concept ID, old and new preferred terms, rationale, owner, effective version, touchpoints, dependencies, risks, explanation placements, and accountable assignees.
• Design the compatibility period: add a concise bridge at the new term's first consequential appearances and scoped aliases in help and support search. For high-risk actions, state whether only the name changed or the function and consequences changed too.
• Change the old term in the termbase from preferred to deprecated or search alias with an explicit scope. Scan product-controlled content and update UI, docs, support macros, and indexes while preserving immutable history.
• Define and regress exit criteria. Remove the notice only when old queries resolve to the new concept, new production of the old term approaches zero, and key tasks and contacts stabilize; check external dependencies and name collisions before retiring aliases or compatibility layers.

Related

• Same group: T1.04.1 Use exactly one term per concept across the product · T1.04.2 The glossary must cover interface, docs, and support
• Adjacent: S1.07.3 Terminology must first be consistent in the source language · S4.05.3 Termbases and style guides provide acceptance criteria
• Search terms: term migration · impact graph · legacy search alias