Migration is not about plugging in documents. It is about redefining question, source, interface, and fallback so users gain trust, not just more context.
In this article +
Your lists
Diagnose what the current chat solves and what it invents
Before migrating, observe real conversations: where the chat helps, where it improvises, and which questions require evidence. Without that baseline, the project will change architecture without fixing the trust failure that triggered the migration.
Trim domains and prepare the corpus by use case
Do not connect the whole company at once. Pick one small domain, remove duplicates, mark owners, and prepare enough metadata so retrieval can distinguish current policy, old note, and draft.
Start with a flow that has stable documents and frequent users.
Remove decorative files that only add semantic noise.
Define from the start which documents must never be cited.
Change the response experience, not only the backend
Users should notice that something changed: visible citations, bounded confidence, partial answers when evidence is missing, and easy access to the source document. If the interface still rewards verbal certainty, RAG will feel like the same chat under a new label.
Redesign evaluation and support
The criterion is no longer only 'sounds useful'. Retrieval precision, citation clarity, permission compliance, and human handoff rate now matter. The operation also needs a short path to report dubious answers and correct the corpus.
Migrate in stages with explicit comparison
For a short period, compare the legacy chat and the RAG flow on the same questions. That comparison reveals where the new system improves, where it loses speed, and which questions still do not deserve document retrieval.
We use necessary cookies for the site and, only with your permission, analytics (Google Analytics, Microsoft Clarity and PostHog when enabled) to improve the experience. Cookie policy · Privacy
Cookie settings
Use Activate all / Deactivate all per category. Expand for individual cookies.
kdx-cookie-consent
Kodex (first-party) · localStorage
Recordar categorías de cookies aceptadas o rechazadas (Aceptar / Rechazar / Ajustes).
kdx_session
Kodex (first-party) · cookie HTTP (HttpOnly, SameSite=Lax, Secure en producción)
Mantener la sesión autenticada de la comunidad Kodex (cuenta, listas guardadas, panel).
CDN / sesión de entrega
Infraestructura / CDN · cookie HTTP / sesión
Entrega segura del sitio, rendimiento y protección básica.
reCAPTCHA
Google · _GRECAPTCHA y relacionadas
Protección antispam en formularios públicos.
kdx-theme-override
Kodex (first-party) · localStorage
Recordar si el usuario forzó tema claro u oscuro.
_ga / _ga_*
Google Analytics 4 · cookie HTTP
Medición agregada de audiencia y uso del sitio (páginas, eventos).
Microsoft Clarity
Microsoft · cookies / almacenamiento de sesión
Mapas de calor, clics y reproducción de sesiones para mejorar UX.
PostHog
PostHog · cookie / localStorage
Analítica de producto y eventos de conversión (si está configurado).