No hay nada
que migrar.
- 01Nada sale del repositoryNo exportas, conviertes ni subes nada. El markdown se queda exactamente donde está, en su branch, en manos de git y revisado como tu equipo ya lo revisa.
- 02Conectas, lo que lleva unos tres minutosAcceso de solo lectura a los repositories que elijas, una branch elegida de la lista real y la raíz de documentación encontrada por ti. No hay paso de configuración porque no hay configuración.
- 03Mantienes tu herramienta anterior todo el tiempo que quierasConectar no cambia nada de tu sitio actual. Usa los dos, decide con tu equipo y apaga uno, o ninguno. No hay corte ni ventana en la que la documentación no esté disponible.
Qué se traslada y qué no
La segunda lista es la que merece leerse. Todo lo que hay en ella es un no-objetivo deliberado y no una carencia.
Lo que viene contigo
- Todos los archivos markdown
- Se leen tal como están escritos, incluidos los que la configuración de tu herramienta anterior nunca listó.
- Tu estructura de carpetas
- Se convierte en la navegación tal cual: ese es todo el producto.
- Encabezados, tablas, bloques de código, Mermaid
- CommonMark y GFM, bien renderizados.
- Los títulos del front matter
- Se usan cuando existen; si no, el primer encabezado y luego el nombre de archivo.
- Los enlaces relativos entre documentos
- Se resuelven, y se informan como hallazgo de salud cuando uno no lleva a ninguna parte.
- Tu historial de git
- Intacto. Nunca escribimos en tu repository.
Lo que no
- Una navegación ordenada a mano
- El orden se deduce: README primero, luego los prefijos numéricos y después alfabético por título. Si el capítulo tres debe seguir al dos por un motivo que ningún nombre de archivo recoge, esa intención no sobrevive.
- Los componentes MDX personalizados
- Los archivos `.mdx` se indexan y se leen como texto; no se evalúa JSX. Un archivo que sea casi todo componentes se leerá casi vacío.
- Tu tema y tu CSS personalizado
- El reader es una sola superficie con dos temas. Un sitio público usa tu logotipo, tu favicon y tus colores, no tu propio CSS.
- Tus URL públicas y su posicionamiento
- Un sitio público vive en la dirección docsflowy.site de tu equipo, así que las direcciones que tu sitio actual se ha ganado en los buscadores no se mueven con él. Si esas URL importan, deja ese sitio donde está.
- Las reglas de redirección y las rutas personalizadas
- Las rutas salen del repository. No hay tabla de redirecciones.
De dónde llegan los equipos
Desde MkDocs, Docusaurus o GitBook
Tu markdown ya está en el repository y ya está en carpetas. Conéctalo y compara el árbol que construimos con la navegación que mantenías a mano. Si el nuestro está mal, es un fallo de detección que merece la pena contarnos.
Desde Mintlify
Sus páginas se construyen alrededor de sus propios componentes y de su archivo de navegación, así que no llegan tal cual. Si tu sitio para clientes funciona, consérvalo y apúntanos a los repositories internos que nunca iban a estar en él. Si quieres páginas públicas escritas con el trabajo, el manual las publica como versiones con nombre.
Desde una wiki
Es el único caso con trabajo real: primero el contenido tiene que convertirse en markdown dentro de un repository. Una vez ahí, conectar lleva los mismos tres minutos que cualquier otra cosa.
Desde cero
El caso habitual. Los documentos existen, en seis repositories, y nadie les ha puesto nunca delante una herramienta de documentación porque todas pedían primero un archivo de configuración.
Desconectar es un clic, y no deja nada detrás
La misma propiedad que abarata la llegada abarata la salida, y un producto fácil de abandonar es un producto que tiene que ganarse que te quedes.
Desconecta un repository y dejamos de leerlo. Revoca la GitHub App desde los ajustes de GitHub y no podremos leerlo, paremos o no: el interruptor está de tu lado, no del nuestro. Tu markdown está donde siempre estuvo, en la misma branch, con un historial en el que nunca escribimos.
Lo que perderías es la capa que añadimos encima: los estados de revisión e implementación, las notas, los acuses de lectura, los hallazgos de salud y los artifacts que haya archivado un agente. Están de nuestro lado porque nunca existieron en tu repository, y si eso te importa, conviene preguntarlo antes de empezar y no después.
Apúntalo a un repository y deja todo lo demás funcionando.
No hay corte que programar, así que no hay nada que deshacer si cambias de opinión.
Empezar gratis