Contexto — fin de venta y EOL de Jira Data Center
Atlassian dejó oficialmente de vender nuevas licencias de Jira Data Center a nuevos clientes el 30 de marzo de 2026. Los clientes Data Center existentes conservan la posibilidad de comprar ampliaciones de licencias y renovaciones hasta el 30 de marzo de 2028, fecha a partir de la cual esas opciones también desaparecen. La etapa final es el EOL del 28 de marzo de 2029: en esa fecha, los productos Data Center pasan a modo de solo lectura. Sus datos siguen accesibles para consulta, pero cualquier creación o modificación de tickets, de proyectos o de configuración se vuelve imposible.
Este calendario parece dejar tiempo. En la práctica, una migración de gestión de proyectos moviliza semanas de preparación: inventario de los proyectos activos, limpieza de los tickets obsoletos, reconfiguración de los flujos de trabajo, formación de los equipos y un periodo de doble ejecución para validar la continuidad. Esperar a 2028 equivale a llevar a cabo la migración de urgencia, bajo la presión de la fecha límite, con un riesgo elevado de pérdida de datos o de interrupción de la producción.
Cinco razones para migrar ahora en lugar de hacerlo de urgencia
- Coste de las licencias Data Center por puesto — el modelo de tarificación de Data Center factura por usuario activo, con tramos anuales cuyas revisiones de precios por parte de Atlassian escapan a su control. Salir ahora permite calcular con calma el TCO de la nueva solución.
- Calendario cerrado, sin sorpresas — la fecha del 28 de marzo de 2029 es definitiva. Una migración realizada en 2026 o 2027 deja tiempo para una ejecución en paralelo y para una eventual marcha atrás; una migración realizada en 2028 no deja ni lo uno ni lo otro.
- Riesgo de solo lectura en el EOL — si su instancia Data Center no está migrada el 28 de marzo de 2029, sus equipos pierden la capacidad de crear o modificar tickets. Un incidente bloqueante durante el periodo de congelación es un escenario que conviene eliminar de antemano.
- Control de los datos y de las copias de seguridad — en un VPS con acceso root, usted elige la frecuencia de las copias de seguridad, el cifrado, la retención y la ubicación de los datos. Ningún tercero decide la duración de retención en su lugar.
- Oportunidad de limpieza — una migración es el momento ideal para archivar los proyectos inactivos, armonizar los estados y los tipos de tickets, y partir de una base limpia en lugar de transferir años de artefactos acumulados.
- Estabilidad de las integraciones — los conectores de Jira (CI/CD, Confluence, Slack, plugins de terceros) tendrán que reconstruirse de todos modos al pasar a una nueva plataforma. Hacerlo hoy permite elegir integraciones abiertas, basadas en API estándar, sin dependencia de un ecosistema propietario.
- Eliminación de plugins no portados — Atlassian ha anunciado que algunos plugins de Data Center no se portarán más allá de 2028; las funcionalidades que dependen de ellos deben identificarse y reemplazarse antes del EOL.
Requisitos previos concretos antes de empezar
Antes de elegir entre OpenProject y Plane, compruebe que su VPS cubre las exigencias mínimas de cada herramienta. OpenProject requiere un procesador quad-core de al menos 2 GHz y 4 GB de RAM para acoger hasta 200 usuarios en total: es la configuración recomendada por el editor para un uso de producción estable. Por debajo, las operaciones en segundo plano (notificaciones, actualización de los atributos calculados) se ralentizan. Plane necesita como mínimo 2 vCPU, 4 GB de RAM y 20 GB de almacenamiento para su despliegue AIO (All-In-One) en Docker.
En cuanto a los requisitos comunes: debe producirse y verificarse una exportación XML completa de su instancia Jira Data Center antes de tocar nada en el entorno de destino. Exporte proyecto por proyecto en las instancias voluminosas — Jira impone límites de tamaño en las exportaciones globales. Disponga de una copia de seguridad completa de todos sus proyectos, incluidos los archivos adjuntos. El VPS de destino debe ser accesible por SSH con acceso root, y Docker con docker compose v2 debe estar instalado o poder instalarse libremente. Prevea también un dominio o subdominio (p. ej. pm.suempresa.com) y los registros DNS correspondientes antes de generar los certificados TLS.
OpenProject vs Plane — comparación de los criterios clave
Desplace la tabla
| Criterio | OpenProject | Plane |
|---|---|---|
| Licencia | GPL-3.0 | AGPL-3.0 |
| Estrellas en GitHub | ~15 900 | ~56 000 |
| RAM mínima (producción) | 4 GB — quad-core ≥ 2 GHz (hasta 200 usuarios) | 4 GB — 2 vCPU, 20 GB de almacenamiento |
| Jira Migrator nativo | Sí — Beta (desde OpenProject 17.4, mayo de 2026) | Importación nativa desde una exportación XML de Jira |
| Interfaz | Cercana a Jira — work packages, roadmaps, Gantt integrado | Moderna y depurada — issues, cycles, modules |
| Curva de aprendizaje | Moderada — vocabulario y conceptos cercanos a Jira | Ligera para los equipos habituados a herramientas ágiles modernas |
| Autenticación federada | LDAP y SAML incluidos en la versión Community | LDAP incluido en self-hosted; SAML disponible en self-hosted |
OpenProject — migración con el Jira Migrator oficial
Exportar los datos desde Jira Data Center
En la administración de Jira, vaya a Sistema → Copia de seguridad y exportación. Lance una exportación XML por proyecto en las instancias voluminosas, en lugar de una exportación global: Jira Data Center impone límites de tamaño que truncan silenciosamente las exportaciones demasiado grandes. Incluya los archivos adjuntos en la exportación. Compruebe el tamaño del archivo generado y compare el número de tickets exportados con el contador en base de datos antes de continuar.
Desplegar OpenProject con Docker
En el VPS, cree una carpeta de trabajo y descargue el archivo
docker-compose.ymloficial de OpenProject. Defina las variables de entorno obligatorias:SECRET_KEY_BASE(genere una cadena aleatoria de 64 caracteres),OPENPROJECT_HOST__NAME(su dominio),OPENPROJECT_HTTPS=true. Lance la pila condocker compose up -dy espere a que terminen las migraciones de base de datos (visibles en los registros del contenedorweb).Configurar y activar el Jira Migrator
El Jira Migrator de OpenProject está disponible en Beta desde la versión 17.4 (mayo de 2026). En la administración de OpenProject, vaya a Módulos → Jira Migration. La herramienta le pide el archivo XML de Jira exportado en el paso anterior. Antes de lanzarla, lea las limitaciones conocidas documentadas en openproject.org/docs/installation-and-operations/jira-migration/ — algunos tipos de campos personalizados o de configuraciones de flujo de trabajo pueden requerir un tratamiento manual tras la importación.
Lanzar la migración y vigilar el progreso
Inicie la importación desde la interfaz del Jira Migrator. En las instancias de gran tamaño (varias decenas de miles de tickets), el proceso puede tardar varias horas. Vigile en paralelo los registros del contenedor
workerde OpenProject: los errores de importación aparecen ahí antes de agregarse al informe final de migración. No detenga la pila Docker durante la importación.Validar los work packages, archivos adjuntos y campos personalizados
Una vez terminada la importación, el Jira Migrator muestra un informe con el número de elementos importados y los posibles errores. Compruebe una muestra representativa de work packages: título, descripción, estado, tipo, archivos adjuntos, historial de comentarios. Controle los campos personalizados de tipo texto, número, fecha y lista de selección: son los cuatro tipos migrados por la Beta. Los campos de tipo fórmula o en cascada no se migran automáticamente.
Configurar los usuarios y los permisos
El Jira Migrator crea usuarios de OpenProject correspondientes a las cuentas de Jira, basándose en la dirección de correo electrónico. Los usuarios cuyo correo no coincide con ninguna cuenta OpenProject existente se crean como inactivos. Actívelos manualmente, asígnelos a los grupos y proyectos adecuados y configure los roles. Si utiliza LDAP o SAML, conecte el directorio antes de esta etapa para que las cuentas queden vinculadas a la autenticación centralizada desde la primera conexión.
Configurar las notificaciones y el servidor de correo
En Administración → Configuración de correo electrónico, indique los datos de su servidor SMTP. OpenProject envía notificaciones para las menciones, los cambios de estado y las fechas de vencimiento. Envíe un correo de prueba antes de validar la configuración. Defina las preferencias de notificación por defecto para los nuevos usuarios, con el fin de evitar una avalancha de correos en cuanto se abra la plataforma a los equipos.
Plane — importación nativa desde una exportación XML de Jira
Exportar los datos desde Jira Data Center
Proceda de la misma forma que para OpenProject: exportación XML por proyecto desde la administración de Jira, con los archivos adjuntos incluidos. Si su instancia de Jira supera los límites de la exportación global, divida por proyecto e impórtelos secuencialmente en Plane. Conserve los archivos XML originales hasta la validación completa de la migración.
Desplegar Plane en modo AIO con Docker
Plane ofrece un despliegue AIO (All-In-One) con Docker que integra todos los servicios en una configuración simplificada. Clone el repositorio oficial, copie el archivo
.env.examplecomo.enve indique como mínimoWEB_URL(su dominio),SECRET_KEYy los parámetros de base de datos. Lance condocker compose -f docker-compose.yml up -d. Los servicios que arrancan incluyen el frontend Next.js, la API Django, el worker Celery, la base de datos PostgreSQL y Redis.Importar desde el XML de Jira en la interfaz de Plane
Una vez Plane accesible, cree un espacio de trabajo. Acceda a los ajustes del espacio de trabajo → Importadores → Jira. Plane le pide que suba el archivo XML exportado desde Jira. La importación crea un proyecto Plane por cada proyecto Jira contenido en el archivo, con las issues, las descripciones, los archivos adjuntos y los comentarios. Los estados de Jira se mapean a estados de Plane que puede renombrar tras la importación.
Validar las issues y los archivos adjuntos
Tras la importación, revise una muestra de issues por proyecto: título, descripción en Markdown, archivos adjuntos, comentarios históricos. Compruebe que los estados personalizados se han mapeado correctamente. Las issues cuyos archivos adjuntos superan el tamaño permitido por la exportación de Jira pueden aparecer sin su archivo adjunto: consulte el informe de importación en los ajustes del espacio de trabajo.
Configurar los cycles, modules y miembros
Plane organiza el trabajo en cycles (el equivalente de los sprints de Jira) y en modules (agrupaciones temáticas). Estas estructuras no se importan automáticamente desde Jira: hay que recrearlas según la organización deseada para la nueva plataforma. Invite a los miembros del equipo por correo electrónico o configure el SSO SAML en los ajustes del espacio de trabajo antes de abrir el acceso al conjunto de los usuarios.
Lo que ninguna de las dos herramientas recupera
Antes de anunciar la migración a sus equipos, documente explícitamente lo que no se transferirá — es la principal fuente de decepción y de resistencia al cambio.
Las automatizaciones y reglas de Jira (triggers sobre cambio de estado, reasignación automática, transiciones condicionales) no se migran. OpenProject y Plane tienen cada uno su propio sistema de automatización, pero debe reconfigurarse desde cero. Planifique un taller con los equipos para cartografiar las automatizaciones existentes antes de la migración.
Las integraciones de terceros — conectores de Confluence, bots de Slack, webhooks hacia sistemas CI/CD, plugins del Marketplace de Jira — tendrán que reconstruirse sobre las API de OpenProject o de Plane. Ambas herramientas exponen API REST documentadas, pero la lógica de integración debe reescribirse.
Los flujos de trabajo de proyecto con condiciones complejas (permisos por rol en cada transición, restricciones de validación) no los migra el Jira Migrator Beta. OpenProject permite reconfigurar flujos de trabajo completos, pero únicamente a través de su interfaz de administración — no automáticamente en la importación.
Los datos históricos de sprint — velocidad, burndown, capacidad planificada frente a realizada — no se transfieren. El historial de las issues y de los comentarios se conserva, pero las métricas ágiles agregadas se quedan en Jira. Si esos datos tienen valor para el equipo, expórtelos en CSV desde Jira antes de cerrar la instancia.
Por último, los tipos de tickets de Jira Service Management (incidentes, solicitudes de servicio, problemas en el sentido ITSM) no se corresponden directamente con los tipos de issues de ambas herramientas. Si utiliza Jira a la vez para el desarrollo y para el soporte ITSM, evalúe si OpenProject o Plane cubren sus necesidades ITSM o si debe desplegarse una solución dedicada (Zammad, Mattermost, Freshdesk autoalojado) como complemento.
Cree siempre una cuenta de administrador local antes de activar la autenticación SSO (SAML o LDAP). Si la configuración SSO contiene un error — identificador de entidad incorrecto, certificado caducado, mapeo de atributos erróneo — quedará definitivamente excluido de la interfaz en el primer intento de conexión SSO. La cuenta local permite corregir la configuración sin intervenir en el servidor. En OpenProject, esta cuenta debe crearse antes de activar el módulo LDAP en los ajustes; en Plane, desactive el SSO mientras valida la conexión de administrador. Haga también una exportación XML completa de Jira y una copia de seguridad del conjunto de los proyectos antes de cualquier operación en el entorno de destino.
Solución de problemas — errores frecuentes durante la migración
Varios errores se repiten en la gran mayoría de las migraciones de Jira hacia OpenProject o Plane.
Identificadores no mapeados. El Jira Migrator (y el importador de Plane) asocian los usuarios de Jira a cuentas de la plataforma de destino mediante la dirección de correo electrónico. Si un usuario de Jira tiene una dirección de correo distinta de la de su cuenta OpenProject o Plane, sus tickets aparecen sin asignación o con un asignado genérico. Solución: cree previamente todas las cuentas de usuario con las mismas direcciones de correo que en Jira antes de lanzar la importación.
Archivos adjuntos ausentes. Las exportaciones de Jira Data Center incluyen los archivos adjuntos en el archivo ZIP, pero Jira puede imponer un límite de tamaño global en las exportaciones. Si el archivo está truncado, faltan los adjuntos de los tickets más recientes. Compruebe el tamaño del archivo exportado y compárelo con el espacio en disco real de su directorio de attachments de Jira. En las instancias voluminosas, exporte por proyecto y verifique proyecto por proyecto.
Timeout en las exportaciones voluminosas. En los proyectos con decenas de miles de tickets, la exportación XML global de Jira puede expirar del lado del servidor. Utilice la funcionalidad de exportación parcial por proyecto disponible en la interfaz de administración de Jira DC. Importe después cada archivo secuencialmente en OpenProject o Plane.
Problemas de codificación de caracteres en el XML. Las exportaciones de Jira que contienen caracteres especiales (comillas tipográficas, caracteres acentuados en ciertas configuraciones regionales, emojis insertados en descripciones) pueden producir archivos XML mal formados. Valide el archivo XML con una herramienta como xmllint antes de la importación. Si aparecen errores de codificación, abra el archivo en un editor con detección de codificación y corrija las secuencias no válidas.
Errores Beta del Jira Migrator de OpenProject. El Jira Migrator está en Beta desde la versión 17.4 (mayo de 2026) y su comportamiento puede evolucionar entre versiones menores. En caso de error bloqueante, consulte la página de limitaciones conocidas en openproject.org/docs/installation-and-operations/jira-migration/ antes de abrir un ticket de soporte. La mayoría de los errores Beta están documentados con un procedimiento alternativo.
VPS con acceso root + OpenProject o Plane — una salida limpia de Jira Data Center
La migración desde Jira Data Center no es un proyecto de varios meses si se aborda de forma metódica. Una exportación XML limpia, un VPS dimensionado según los requisitos de la herramienta elegida y una jornada de trabajo bastan para transferir las issues, los archivos adjuntos, los campos personalizados esenciales y el historial de comentarios hacia OpenProject o Plane.
La elección entre ambas depende de su contexto: OpenProject está más cerca de Jira en sus conceptos (work packages, roadmaps, Gantt) y dispone de un Jira Migrator oficial, lo que la convierte en la migración menos arriesgada para los equipos habituados al vocabulario de Atlassian. Plane es más moderna en su enfoque y está más ampliamente adoptada por los equipos de desarrollo que quieren partir de bases más ligeras.
En ambos casos, usted recupera el control completo: acceso root al servidor, copias de seguridad dominadas, ausencia de tarificación por puesto revisable unilateralmente por un editor y datos alojados en la infraestructura de su elección. La salida de Jira Data Center deja de ser una restricción para convertirse en una oportunidad de saneamiento de su herramienta de gestión de proyectos.
