AI migration is an information migration before it is a model migration.
A typical project plan can make the change sound deceptively simple: choose a model, connect the knowledge base, build an interface, test it, and launch... But the system is not merely moving documents into a new retrieval layer, it is moving the organization’s decisions about which information is trusted, who owns it, who may see it, when it applies, what supersedes it, and what happens when it is wrong.
Those decisions already exist somewhere. They may be explicit in metadata and governance rules. They may also be scattered across folder structures, publishing habits, permissions, undocumented exceptions, and the memories of experienced employees.
AI does not remove that information architecture. It inherits it.
The Visible Migration Is Documents
The visible work is easy to inventory. Teams can:
- identify repositories
- export pages
- normalize file formats
- create indexes
- connect retrieval systems
- test whether the new tool can find material related to a question
That work matters. It is not the whole migration.
A document can survive the transfer while losing the context that made it usable:
- A procedure moves, but its product-version boundary does not.
- A policy moves, but its approval state is no longer visible.
- Customer and internal guidance enter the same index without preserving audience restrictions.
- Duplicate pages survive while the informal rule about which one is canonical disappears.
- A workaround is indexed without the history explaining why it exists or when it should stop being used.
The files migrated. The knowledge did not.
Authority Has to Migrate Too
A useful AI-assisted knowledge system needs more than relevant text. It needs a way to distinguish among plausible sources.
That requires explicit decisions about:
- Canonical sources
- Ownership
- Approval and review state
- Product, version, audience, and environment
- Effective and retirement dates
- Permissions
- Provenance
- Supersession
- Conflicts and uncertainty
If those distinctions currently live only in people’s heads, the migration project has uncovered an undocumented dependency.
That is project work—not cleanup to postpone until after launch.
Permissions Must Survive Transformation
Access control becomes more complicated when content is copied, indexed, summarized, transformed, or assembled into generated answers.
The migration team must determine whether the new system preserves the intent of the old boundaries.
Who can retrieve an internal runbook? Can the model quote from it in an answer to a customer? What happens when a source becomes restricted after it has already been indexed? Which records show what content contributed to an answer?
A permission model that protects the original page but not the generated output is not the same permission model.
Evaluation Is Part of the Migration
A search migration is not complete merely because the new system returns results. An AI migration is not complete merely because the model produces fluent answers.
The team needs a test set representing real work and known risks. It should include questions for which:
- Several sources are relevant, but only one is authoritative.
- Version differences matter.
- The correct response is to refuse or escalate.
- Source material conflicts.
- Permissions differ by audience.
- The answer changed recently.
- A known obsolete page must not win.
- Missing evidence should remain visible instead of being replaced by inference.
These tests become migration acceptance criteria.
They also give the team something concrete to compare before and after changes to the model, retrieval pipeline, corpus, or metadata.
Cutover Requires Rollback and Retirement
Migration plans usually concentrate on the new system. The old one still matters.
Teams must decide:
- When the new experience becomes authoritative
- How users will learn what changed
- Which legacy search and documentation paths will remain available
- What evidence would trigger a rollback
- How corrections will move through both systems during the transition
- When obsolete indexes, duplicated content, and temporary bridges will be retired
Leaving the old system indefinitely searchable can undermine the new one by preserving competing sources of truth.
A migration is not complete while users must guess which system to believe.
Ownership Must Survive the Launch
The migration team also needs to know who owns the system after release.
Someone must remain responsible for source quality, access rules, evaluation, corrections, monitoring, and changes to the corpus. Otherwise, the knowledge system begins drifting as soon as the implementation project ends.
The model may be new. The obligation to maintain trustworthy information is not.
Technical Writers and Knowledge Architects Belong on the Migration Team
This work is part of documentation strategy and content architecture. Technical writers and knowledge architects already investigate source authority, audience, terminology, lifecycle, navigation, permissions, dependencies, and the difference between what a system claims to do and what people actually do with it.
During an AI migration, those skills help the team answer questions model selection alone cannot resolve:
- What information are we moving?
- Which parts are trustworthy?
- What context must survive?
- What should not migrate?
- How will we know the new system is reliable enough to use?
- Who will own it after launch?
AI migration is not only a technology replacement. It is a transfer of organizational knowledge, rules, context, and responsibility into a new operating environment.
What information problem is your AI project quietly inheriting?