Por qué migrar ahora y no en 2028
Atlassian ha publicado dos fechas que toda agencia que administre Confluence Data Center debe conocer. La primera: el 30 de marzo de 2026, Atlassian dejó de vender nuevas licencias de Confluence Data Center — fuente: falconer.com/guides/confluence-data-center-end-of-life/. La segunda: el 28 de marzo de 2029, todas las instancias existentes de Confluence Data Center pasarán a solo lectura — fuente: docmost.com/blog/atlassian-confluence-data-center-eol/. Entre ambas, una tercera fecha que conviene anotar: el 30 de marzo de 2028, los clientes existentes pierden la posibilidad de renovar o ampliar sus licencias Data Center.
Estos hitos delimitan una ventana de tres años. En la práctica, una migración de wiki corporativo — inventario de los espacios, exportación de las páginas, conversión del marcado Confluence, tratamiento de las macros no compatibles, formación de los colaboradores — lleva entre cuatro y doce semanas según el tamaño de la instancia. Si su cliente tiene doscientas páginas en un espacio, es viable en dos sprints. Si tiene tres mil repartidas en quince espacios con macros personalizadas, es un proyecto en sí mismo que no se lanza seis meses antes del vencimiento.
Seis razones para migrar a Docmost en lugar de esperar
- Fecha límite firme y documentada — el 28 de marzo de 2029, la instancia pasa a solo lectura: ninguna página nueva, ninguna modificación, ninguna revisión. La fecha es pública e irrevocable.
- Fin de los parches de seguridad — en modo solo lectura, Atlassian dejará de publicar parches para Confluence DC; una instancia expuesta en la red se convierte en un objetivo sin protección.
- Edición colaborativa en tiempo real — Docmost ofrece la coedición en directo con cursores en vivo y sincronización instantánea entre usuarios, sin conflictos de versión, una función ausente en Confluence Data Center sin plugin de terceros.
- Diagramas nativos — los bloques Mermaid (sintaxis de texto), Draw.io (organigramas, UML, diagramas de red) y Excalidraw están integrados sin configuración adicional; los diagramas de Confluence requerían licencias de addon aparte.
- Coste previsible — Docmost es de código abierto y se despliega en una infraestructura que usted controla: sin tarificación por usuario revisable unilateralmente, sin renovación anual impuesta.
- Exportación a Markdown y HTML — las páginas de Docmost se exportan en Markdown estándar o en HTML, lo que simplifica las copias de seguridad y hace que las futuras migraciones a cualquier herramienta compatible sean independientes del editor.
- Despliegue Docker en tres contenedores —
docmost,db(PostgreSQL) yredis, un archivodocker-compose.ymloficial, un reverse proxy: la instancia está operativa en menos de una hora.
El importador Confluence de Docmost: lo que conserva y lo que no
Docmost ofrece un importador Confluence nativo, disponible en la edición Enterprise (docmost.com). Según el editor, conserva los espacios de Confluence, la jerarquía de las páginas, los archivos adjuntos, los enlaces internos y los diagramas draw.io. La importación se realiza a partir de la exportación XML generada por Confluence (formato estándar disponible en la administración de Confluence mediante Backup Manager).
Lo que se conserva. La estructura en árbol de los espacios y de las páginas, los archivos adjuntos asociados a las páginas, los enlaces internos entre páginas y los diagramas draw.io integrados se transfieren automáticamente mediante el importador.
Lo que no se conserva: las macros de Confluence. Confluence se apoya en un sistema de macros (bloques dinámicos insertados en las páginas) cuya mayor parte no tiene equivalente directo en Docmost. Las macros más habituales se comportan así durante la importación:
- Macros de maquetación (expand, panel, section/column) — el contenido textual se recupera por lo general, pero el formato estructurado desaparece.
- Macros de contenido dinámico (children, include, excerpt-include) — estas macros que inyectan contenido desde otras páginas no se reproducen.
- Macros de panel de control y de reporting (recently-updated, task-report, roadmap) — estos widgets no existen en Docmost; desaparecen sin sustituto automático.
- Macros de código (code) — el contenido del bloque de código se conserva por lo general; el resaltado de sintaxis depende del tipo de bloque disponible en el editor de Docmost.
- Macros de terceros (plugins del Marketplace de Confluence instalados por el administrador) — no se migran.
Antes de lanzar una importación, elabore el inventario de las macros utilizadas en los espacios que va a migrar. Exporte un espacio de prueba y abra su XML para identificar las etiquetas <ac:structured-macro> y los atributos ac:name: cada valor corresponde a una macro. Esto le da la lista exacta de lo que habrá que tratar manualmente después de la importación.
Si la edición Enterprise no entra en el presupuesto, la migración es manual: exportación HTML o PDF desde Confluence (Administración → Backup Manager o exportación por espacio), y después recreación de la estructura en Docmost (espacios, árbol de páginas) y copiar y pegar los contenidos página por página.
Dividir la migración en sprints: el método para instancias voluminosas
Una migración de wiki no es un evento de conmutación. Es una secuencia de sprints que permite entregar valor de forma progresiva, corregir los errores antes de que se propaguen y mantener el wiki Confluence en paralelo hasta la validación completa de cada lote.
Sprint 0 — inventario y clasificación (1 a 2 días). Exporte la lista completa de los espacios desde la administración de Confluence. Para cada espacio, anote: el número de páginas, la fecha de última modificación, las macros utilizadas (localice las <ac:structured-macro> en el XML de una exportación de prueba) y el equipo propietario. Clasifique los espacios en tres categorías: activos (modificados en los últimos seis meses), archivados (de solo lectura de facto) y obsoletos (candidatos a la eliminación). No importe los espacios obsoletos: son ruido.
Sprint 1 — espacio piloto (3 a 5 días). Elija un espacio activo de tamaño medio, sin macros críticas. Impórtelo con el importador Confluence Enterprise o manualmente. Valide página por página: jerarquía, archivos adjuntos, enlaces internos, renderizado de los bloques de código. Identifique las macros que hayan producido contenido degradado y defina su tratamiento estándar. Este sprint produce su tabla de referencia para todos los sprints siguientes.
Sprints 2 a N — espacios por lotes (1 semana por lote). Agrupe los espacios por afinidad e impórtelos por lotes. Después de cada importación, asigne las páginas degradadas a sus propietarios para su corrección. Mantenga una tabla de seguimiento con el estado de cada espacio.
Sprint final — conmutación y archivado. Una vez validados todos los espacios en Docmost, desactive los permisos de escritura en Confluence para los espacios migrados. Tras 30 días sin ninguna petición de vuelta atrás, archive las exportaciones XML y apague la instancia de Confluence.
Regla práctica para las agencias. No migre nunca la totalidad de los espacios de un cliente en una sola importación, aunque el importador lo permita técnicamente. Lotes de 200 a 300 páginas por sprint permiten corregir los errores a escala de un equipo, no de una organización.
Requisitos previos, con cifras, antes de empezar
Docmost se despliega con tres contenedores Docker: docmost (la aplicación principal), db (PostgreSQL 18) y redis (Redis 8). El archivo docker-compose.yml oficial está disponible en la documentación del editor. El editor no publica requisitos de hardware con cifras en su sitio; para un uso en producción con un equipo de 10 a 50 usuarios, un VPS con 2 vCPU, 4 GB de RAM y 40 GB de almacenamiento es una base razonable — ajuste el almacenamiento según el volumen de archivos adjuntos de sus espacios de Confluence.
En cuanto a los requisitos de red y de sistema: un VPS accesible por SSH con acceso root, Docker y docker compose v2 instalados, un dominio o subdominio que apunte al VPS, y los certificados TLS generados antes de abrir el acceso a los usuarios. Si utiliza Nginx como reverse proxy, configure proxy_pass hacia el puerto interno de Docmost y ajuste proxy_read_timeout a un valor suficiente para las importaciones voluminosas (300 segundos).
Para la importación desde Confluence, prepare además: una exportación XML de cada espacio de Confluence (Administración → Backup Manager → Exportación del espacio, formato XML, archivos adjuntos incluidos), el inventario de las macros utilizadas y un VPS con espacio en disco suficiente para almacenar los archivos XML durante toda la migración.
Procedimiento de migración paso a paso
Exportar los espacios desde Confluence Data Center
En la administración de Confluence, vaya a Administración general → Backup Manager. Seleccione la exportación por espacio (no la exportación global si su instancia supera unos cientos de páginas: las exportaciones globales se truncan de forma silenciosa más allá del límite de tamaño). Para cada espacio, marque la inclusión de los archivos adjuntos. Descargue el archivo ZIP generado y compruebe su tamaño: un archivo anormalmente pequeño en relación con el número de páginas indica una exportación incompleta. Repita el proceso para cada espacio que vaya a migrar.
Desplegar Docmost en el VPS con Docker
Obtenga el archivo
docker-compose.ymloficial desde la documentación de Docmost. Cree junto a él un archivo.envcon las variables obligatorias:APP_URL(su dominio con protocolo, p. ej.https://wiki.client.com),APP_SECRET(cadena aleatoria de 32 caracteres como mínimo) y los parámetros de conexión a PostgreSQL (DB_URL). Levante la stack condocker compose up -dy espere a que terminen las migraciones de base de datos. Configure Nginx como reverse proxy delante del puerto de la aplicación Docmost y genere los certificados TLS con Certbot.Crear los espacios de destino en Docmost
En la interfaz de Docmost, cree un espacio por cada espacio de Confluence que vaya a migrar. Respete los nombres de los espacios de Confluence para facilitar la correspondencia durante la validación. Si su instancia de Docmost está en edición Enterprise, no necesita crear la estructura manualmente: el importador la recrea a partir de la exportación XML.
Lanzar el importador Confluence (edición Enterprise)
En los ajustes del espacio de Docmost, vaya a Import y seleccione el formato Confluence. Suba el archivo ZIP exportado desde Confluence. El importador de Docmost conserva la jerarquía de las páginas, los archivos adjuntos, los enlaces internos y los diagramas draw.io según la documentación del editor. Para las instancias sin edición Enterprise, proceda manualmente: descomprima el archivo ZIP, recupere los archivos HTML de las páginas desde la carpeta
pages/y copie el contenido página por página en Docmost.Validar las páginas importadas y tratar las macros degradadas
Después de cada importación de espacio, recorra una muestra representativa de páginas: jerarquía en el panel lateral, renderizado de los bloques de código, presencia de los archivos adjuntos, funcionamiento de los enlaces internos. Para las páginas que contengan macros no migradas, utilice la tabla de referencia establecida en el sprint piloto para aplicar el tratamiento estándar. Asigne las correcciones a los propietarios de las páginas afectadas en lugar de resolverlas usted mismo.
Configurar los usuarios y los permisos
Docmost gestiona los accesos por espacios y por grupos, con RBAC (control de acceso basado en roles). Cree los grupos correspondientes a los equipos de su cliente y asigne los espacios a esos grupos con los niveles de permiso adecuados. La edición Enterprise incluye el SSO mediante SAML 2.0, OpenID Connect y LDAP.
Configurar las copias de seguridad y la supervisión
Configure una copia de seguridad diaria de la base de datos PostgreSQL (
pg_dumpen un script cron o mediante una herramienta de backup automatizado) y del volumen Docker que contiene los archivos adjuntos. Compruebe que las copias se almacenan fuera del VPS (almacenamiento de objetos, servidor remoto). Active los logs de la aplicación Docmost y configure una alerta de disponibilidad sobre la URL principal de la instancia.
Lo que Docmost no recupera de Confluence
Antes de anunciar la migración a sus clientes, documente explícitamente lo que no se transferirá.
Las macros dinámicas. Las macros de contenido dinámico (children, include, excerpt-include), de reporting (recently-updated, task-report) y las macros de terceros del Marketplace de Confluence no se migran.
El historial de versiones completo. El importador transfiere la versión actual de las páginas. El historial de revisiones de Confluence no se conserva. Si el historial tiene un valor legal o de cumplimiento para su cliente, expórtelo en PDF desde Confluence antes de la migración.
Las páginas de blog de Confluence. Confluence distingue entre páginas estándar y páginas de tipo Blog. Estas últimas no tienen entidad equivalente en Docmost: su contenido puede importarse como páginas estándar, pero se pierde el formato de blog.
Las plantillas de página. Las plantillas de Confluence definidas a nivel de espacio o de instancia no se importan. Recree en Docmost las plantillas más utilizadas después de la migración.
Las integraciones con Jira. Las macros de Confluence que mostraban datos de Jira en tiempo real (macro jira, paneles de tickets) desaparecen en la importación.
Exporte siempre un espacio de prueba en XML y ábralo en un editor de texto antes de lanzar la importación de producción. Busque las etiquetas <ac:structured-macro ac:name="...">: cada valor de ac:name es una macro. En diez minutos tiene la lista exacta de las macros que habrá que tratar manualmente para ese espacio. Esta comprobación previa evita las malas sorpresas en el momento de la validación y permite calibrar correctamente el tiempo de corrección en su planificación de sprints.
Docmost en un VPS: una salida limpia de Confluence Data Center
La migración desde Confluence Data Center no es un proyecto de varios meses si se aborda por sprints progresivos. Un inventario de los espacios por prioridad, un sprint piloto para calibrar el tratamiento de las macros y el importador Confluence de Docmost (edición Enterprise) bastan para transferir la jerarquía, los archivos adjuntos y los enlaces internos de los wikis de sus clientes sin pérdida de estructura.
Para los presupuestos fuera de Enterprise, la migración manual sigue siendo viable en volúmenes limitados: la exportación HTML de Confluence es legible y copiar y pegar los contenidos página por página es una operación sin riesgo técnico. La limitación es el tiempo, no la viabilidad.
En ambos casos, usted recupera el control completo: acceso root al servidor, copias de seguridad bajo su control, datos alojados en la infraestructura que elija y un wiki colaborativo con coedición en tiempo real, diagramas nativos y búsqueda de texto completo, sin tarificación por usuario revisable unilateralmente.
