Si ejecutas Jira Server en 2026, estás ejecutando software sin soporte. Atlassian terminó el soporte el 15 de febrero de 2024. Sin parches de seguridad. Sin correcciones de errores. Sin soporte del proveedor.
El 30 de marzo de 2026, Atlassian dejó de aceptar nuevas suscripciones de Data Center de clientes nuevos. Los clientes existentes pueden seguir realizando ciertas compras hasta el 30 de marzo de 2028 y renovaciones hasta el 28 de marzo de 2029, cuando los productos afectados pasan a ser de solo lectura según el calendario de fin de vida de Data Center publicado por Atlassian.
Entonces, ¿y ahora qué?
Hay tres opciones autoalojadas serias que vale la pena comparar en 2026: OpenProject, Plane y Redmine. Este artículo las compara por arquetipo de caso de uso en lugar de por una lista de funciones, examina el Jira Migrator oficial de OpenProject, ahora en beta para las versiones compatibles de Jira Server y Data Center, y termina con el contrapunto honesto: cuándo Jira Cloud sigue siendo la respuesta correcta.
Si estás aquí porque "tenemos que migrar antes de 2029 y necesito conocer mis opciones reales", sigue leyendo. Si estás aquí porque "quiero una tabla comparativa con 47 columnas", hay otros artículos para eso. Este no es uno de ellos.
La versión corta
- Jira Server ya no tiene soporte y Jira Software Data Center está siendo retirado. Las nuevas ventas de Data Center a clientes nuevos terminaron en 2026; las suscripciones existentes afectadas llegan al fin de su vida útil en 2029.
- Tres caminos autoalojados reales en 2026. OpenProject para equipos que quieren un reemplazo con la forma de Jira y una herramienta de migración, Plane para equipos liderados por ingeniería que quieren la UX de Linear sin la factura SaaS, Redmine para equipos que quieren un gestor de incidencias de bajos recursos que lleva dos décadas funcionando.
- OpenProject incluye un Jira Migrator en beta para Jira Server y Data Center 10.x y 11.x, no para Jira Cloud. Sus fuentes oficiales están actualmente desincronizadas: la guía técnica de mayo enumera un conjunto de datos básico más estrecho, mientras que las páginas más recientes de julio dicen que el Migrator también importa el historial de incidencias, los comentarios y los usuarios y grupos implicados. Trata esas afirmaciones nuevas como dependientes de la versión y confírmalas en un piloto sobre la versión exacta de OpenProject que vayas a desplegar. Plane, por su parte, anuncia una importación controlada desde Jira y soporte de migración personalizado para equipos con más de 100 licencias. Redmine no tiene una vía propia comparable.
- El dimensionamiento del VPS es modesto. Las guías oficiales sitúan el punto de partida de OpenProject y Plane en 4 GB de RAM; Plane recomienda 8 GB para producción. La imagen de Redmine de Cloudzy indica 2 GB de RAM como mínimo.
- Jira Cloud sigue siendo lo correcto para algunos equipos, sobre todo los que no tienen capacidad de operaciones. Los precios de Atlassian varían según el número de licencias y la periodicidad de facturación, así que consulta la página de precios actual de Jira en lugar de fiarte de una tarifa antigua fijada a mano.
El reloj de cuenta atrás de Atlassian: qué está pasando realmente
Tres fechas que marcan el reloj de Jira:
- 15 de febrero de 2024: Atlassian terminó el soporte de Jira Server. No se proporciona soporte técnico, actualizaciones de seguridad ni correcciones de errores para los productos o aplicaciones Server.
- 30 de marzo de 2026: Atlassian dejó de vender nuevas suscripciones de Data Center y aplicaciones de Marketplace para Data Center a clientes nuevos. Los clientes existentes aún pueden renovar.
- 28 de marzo de 2029: las suscripciones y aplicaciones de Data Center afectadas caducan y pasan a ser de solo lectura. Atlassian señala que puede haber mantenimiento extendido excepcional para determinados clientes.
Los equipos están reaccionando de tres maneras aproximadamente. Algunos migran a Jira Cloud, pagan la factura por licencia y aceptan la simplificación operativa. Otros se apoyan en las renovaciones de Data Center hasta 2029 y tratan la fecha límite como un problema de su yo futuro. Otros evalúan ya alternativas autoalojadas para evitar tanto el precio como el plazo.
Si estás en el segundo grupo ("ya lo resolveremos más adelante"), la valoración honesta es que "más adelante" solo será un problema de 2029 si además no tienes nada más en tu hoja de ruta hasta entonces. La mayoría de los equipos que he visto hacer esto acaban migrando con prisas, porque el calendario avanza más rápido de lo que nadie espera.
Consejo pro: Si tu equipo está en Server, el riesgo de seguridad por sí solo justifica tratar esto como un problema de 2026, no de 2029. Un gestor de incidencias sin soporte sigue siendo superficie de ataque, y suele quedar en baja prioridad para la revisión de seguridad precisamente porque "simplemente funciona".
Conclusión de la sección: El reloj tiene fechas, es público y es oficial. Planifica en torno a 2026-2027, no a 2029.
Los tres caminos autoalojados realistas en 2026
En el ecosistema de código abierto hay decenas de gestores de incidencias. Para mantener el foco, este artículo cubre tres caminos distintos: OpenProject para la gestión de proyectos formal y la herramienta de migración más directa; Plane para un flujo de trabajo de ingeniería moderno; y Redmine para un tracker maduro y extensible. Taiga, Tuleap, Kanboard y otros proyectos pueden seguir encajando mejor en requisitos más acotados.
Esto es lo que es realmente cada uno.
OpenProject
OpenProject es una aplicación Ruby on Rails respaldada por PostgreSQL. La Community Edition es GPLv3 y gratuita para autoalojar; los planes de pago Enterprise on-premises añaden soporte y funciones Enterprise.
El posicionamiento de UX es utilitario y denso en funciones. Parece software de gestión de proyectos empresarial porque lo es. Buen soporte de diagramas de Gantt, informes formales de cartera de proyectos, colaboración basada en BCF para construcción e ingeniería y flujos de responsabilidad de las partes interesadas. Si tu equipo ha pedido alguna vez "Gantt de verdad" o "dependencias entre épicas de distintos proyectos", esta es tu herramienta.
El equipo que mejor encaja con OpenProject es el que necesita que la cascada tradicional y lo ágil convivan en la misma instancia, informes formales hacia arriba y una vía de migración oficial desde versiones compatibles de Jira Server o Data Center. Hablaremos del Migrator, y de sus límites actuales, más abajo.
El punto débil es la curva de aprendizaje. Los miembros del equipo que vengan de Jira Cloud o Linear te dirán que OpenProject se siente pesado. No se equivocan. Muchos conceptos centrales de Jira tienen equivalente en OpenProject, pero puede que necesites leer documentación para encontrarlos.
OpenProject está en el el marketplace de Cloudzy como despliegue en un clic si quieres saltarte el baile de Compose.
Plane
Plane es un proyecto más joven, fundado en 2022. Su distribución autoalojada actual es un despliegue empaquetado de Docker o Kubernetes con varios servicios de aplicación más PostgreSQL, Redis y almacenamiento de objetos, en lugar de una simple pila de cinco contenedores.
- Servicios web y de API
- Trabajadores en segundo plano
- PostgreSQL
- Redis
- Almacenamiento de objetos
La Community Edition está licenciada bajo AGPLv3.
El posicionamiento de UX se inspira abiertamente en Linear. Ciclos, módulos, proyectos, vistas. Moderno, rápido, con criterio propio. Si alguna vez te gustaron los atajos de teclado por defecto de Linear o su modelo de incidencias, Plane te resultará familiar en menos de una hora.
El equipo que mejor encaja está liderado por ingeniería: startups, equipos de producto independientes, pequeñas consultoras de desarrollo donde los ingenieros son los usuarios principales y la herramienta de gestión de proyectos es sobre todo un gestor de incidencias más un tablero de sprint. Ahí es donde Plane brilla.
Hay debilidades reales que conviene reconocer. El proyecto es más joven que los otros, lo que implica un ecosistema de integraciones más pequeño y una superficie de despliegue que cambia más rápido. Su licencia AGPLv3 también merece una revisión antes de modificar el software para un servicio de red comercial.
Plane no está en la marketplace de Cloudzy a fecha de julio de 2026, así que este requiere el propio despliegue Docker o Kubernetes de Plane en el VPS que elijas. Es manejable para un equipo que ya se maneje con contenedores, pero añade más instalación y mantenimiento que una imagen de un clic.
Redmine
Redmine es el veterano. Su primera versión es de 2006. Ruby on Rails, backend MySQL o PostgreSQL. GPLv2. Ligero para los estándares actuales, en parte porque el núcleo es realmente pequeño y en parte porque casi todo lo que la gente quiere de Redmine llega vía plugins.
La UX es más antigua. No tiene sentido fingir lo contrario. Redmine 7.0 se convirtió en la última rama estable en junio de 2026, pero su interfaz por defecto sigue teniendo un aire tradicional. El tema Bleuclair moderniza Redmine 6.1; verifica la compatibilidad del tema y los plugins antes de pasar a Redmine 7. Si una UX moderna es un requisito ineludible, mira Plane.
El equipo que mejor encaja es el que ya usa Redmine, o el que quiere un gestor de incidencias estable y de bajos recursos sin un flujo de trabajo dogmático impuesto por la herramienta. El ecosistema de plugins es enorme:
- Tableros ágiles
- Gantt
- Seguimiento de tiempo
- Integraciones SCM
- Flujos de trabajo personalizados
Si un equipo tiene una necesidad concreta de flujo de trabajo, seguramente exista un plugin de Redmine para eso.
La debilidad es doble. La UX, como ya se ha visto. Y el propio ecosistema de plugins, que es un arma de doble filo: los plugins resuelven problemas, pero generan quebraderos de cabeza de compatibilidad de versiones al actualizar. Una instancia de Redmine con ocho plugins es una instancia donde cada actualización menor exige pruebas.
Una nota para equipos que ya usan Redmine: si la única queja es la UX y estás en Redmine 6.1, el tema Bleuclair es un experimento barato que puede eliminar la necesidad de migrar de plataforma. Pruébalo primero y verifica la compatibilidad antes de cualquier actualización a Redmine 7.
Conclusión de la sección: Elige por arquetipo. OpenProject para un reemplazo con la forma de Jira. Plane para la UX de Linear sin la factura SaaS. Redmine para un seguimiento de incidencias estable con un plugin para todo.
Comparación lado a lado
Ahora que hemos cubierto cada herramienta en detalle, pongámoslas en un formato fácil de distinguir.
| Dimensión | OpenProject (Community) | Plane (Community) | Redmine |
|---|---|---|---|
| Primera versión | 2012 | 2022 | 2006 |
| Pila | Ruby on Rails más PostgreSQL | Aplicación empaquetada más PostgreSQL, Redis y almacenamiento de objetos | Ruby on Rails más MySQL o PostgreSQL |
| Licencia | GPLv3 | AGPLv3 | GPLv2 |
| Mínimo de dimensionamiento (equipo pequeño) | 4 núcleos, 4 GB de RAM | Desde 4 GB de RAM, 8 GB recomendados para producción | Desde 2 GB de RAM |
| el marketplace de Cloudzy | Sí (en un clic) | No (despliegue autogestionado) | Sí (en un clic) |
| Vía de migración desde Jira propia | Beta integrada: Server/Data Center 10.x a 11.x | Importación guiada; acompañamiento personalizado a partir de 100 licencias | Ninguna |
| Su punto fuerte | Gestión de proyectos formal, Gantt, informes de cartera | UX moderna, equipos de ingeniería | Seguimiento de incidencias ligero, plugins |
| Su punto débil | UX más pesada; el migrador sigue en beta | Ecosistema más joven; mínimo de RAM más alto | UX por defecto envejecida; compatibilidad de plugins |
El Jira Migrator de OpenProject: qué hace realmente
Este es el detalle que la mayoría de comparativas de 2026 se saltan o relegan a una nota al pie. Es también la razón de peso por la que OpenProject es la elección más natural para los equipos que hoy están en Jira.
OpenProject puso su Jira Migrator en beta a disposición en 2026 como parte de la Community Edition. Se conecta por API y con un Personal Access Token de administrador a Jira Server o Data Center 10.x y 11.x. Jira Cloud no está soportado actualmente.
Lo que las páginas oficiales actuales de OpenProject dicen en conjunto que importa:
- Proyectos e identificadores de proyecto
- Incidencias: resumen o título, descripción, adjuntos, historial, comentarios, fecha de vencimiento, horas estimadas y horas restantes; los identificadores de incidencia también están soportados en beta
- Usuarios y grupos implicados, incluidos nombres, direcciones de correo, pertenencia a proyectos y pertenencia a grupos
- Campos personalizados soportados que tienen equivalente en OpenProject
- Estados y tipos de incidencia
Lo que aún debes considerar no soportado:
- Relaciones entre incidencias y asignaciones de sprint
- Flujos de trabajo, permisos y esquemas a nivel de proyecto
- Etiquetas, versiones, componentes y otros campos no listados como cubiertos deben considerarse no soportados hasta que un piloto demuestre lo contrario
- Jira Cloud, datos de aplicaciones del Marketplace, reglas de automatización e integraciones externas
Dos detalles operativos importan tanto como la lista de campos. Las importaciones aterrizan primero en un modo de revisión, y una importación puede revertirse mientras siga en revisión. Una vez que apruebas la importación, ya no es posible revertirla. Y como la cobertura sigue cambiando de una versión a otra, consulta la documentación actual antes de cada migración.
Un modelo mental razonable: el Migrator en beta gestiona un conjunto creciente de datos básicos de proyecto, no un entorno completo de Jira. Planifica un piloto controlado y reserva tiempo para reconstruir la lógica de flujo de trabajo, los permisos, las aplicaciones y las integraciones no soportadas.
Nota: la guía técnica del 6 de mayo de OpenProject enumera un conjunto de datos más estrecho que sus páginas más recientes de julio, que añaden el historial, los comentarios y los usuarios y grupos implicados. Como el Migrator sigue en beta, confirma la cobertura en la versión exacta que vayas a desplegar y pruébala contra un proyecto de Jira representativo antes del cambio.
Un camino de migración de alto nivel más seguro tiene este aspecto:
- Levanta una instancia de OpenProject fuera de producción en un VPS (la imagen de un clic de Cloudzy sirve, o usa los métodos de despliegue soportados por OpenProject).
- Confirma que el origen es Jira Server o Data Center 10.x u 11.x y crea después un Personal Access Token de administrador.
- Haz una copia de seguridad de la instancia de prueba de OpenProject y luego configura el Migrator con la URL de Jira y el token.
- Ejecuta un piloto sobre un proyecto representativo y verifica los identificadores de proyecto, los usuarios, las pertenencias a grupos, los estados, los tipos de incidencia, los campos personalizados soportados, los adjuntos, el historial, los comentarios, las fechas de vencimiento, las estimaciones y las horas restantes.
- Revisa el piloto con cuidado. Mientras la importación esté en revisión, revíértela si los mapeos son incorrectos; tras la aprobación, esa importación ya no se puede revertir.
- Planifica la migración a producción solo cuando el piloto haya salido bien. Usa una ventana de mantenimiento, congela las escrituras en Jira, conserva las copias de seguridad y reconstruye por separado los flujos de trabajo e integraciones no soportados.
Plane anuncia ahora una importación desde Jira propia y controlada que mapea proyectos, incidencias, sprints, tipos de incidencia, estados, campos personalizados, comentarios y adjuntos; los equipos con más de 100 licencias pueden solicitar acompañamiento personalizado en la migración. La vía de Redmine sigue siendo menos directa y depende de plugins de la comunidad o flujos con CSV que hay que probar contra versiones y configuraciones concretas.
Conclusión de la sección: El Migrator en beta de OpenProject soporta Jira Server/Data Center 10.x y 11.x, pero sus fuentes oficiales no coinciden sobre la cobertura actual. Valida tu versión exacta. Plane ofrece importación guiada; Redmine no tiene una vía propia comparable. Haz un piloto de OpenProject y de Plane antes de producción.
Dimensionamiento del VPS: qué necesita realmente cada herramienta
El coste de infraestructura para autoalojar estas herramientas es modesto. La fiabilidad, las copias de seguridad, las pruebas de restauración y la monitorización importan más que meter la pila en el plan más pequeño. Cloudzy publica actualmente un SLA de uptime del 99,95%, y sus planes de VPS se pueden redimensionar a medida que crece el uso.
| Aspecto de planificación | OpenProject | Plane | Redmine |
|---|---|---|---|
| Recomendación inicial | 4 núcleos, 4 GB de RAM | 2 núcleos, 4 GB de RAM | Desde 2 GB de RAM (imagen de Cloudzy) |
| Nota para producción | Mínimo en servidor único; hasta 200 usuarios en total | Recomienda 8 GB de RAM | Los plugins y la concurrencia marcan la carga |
| Escala cuando | Suben las colas, la latencia de la base de datos o la RAM | Los servicios compiten por RAM y CPU | Sube la latencia de la base de datos o la carga de los plugins |
Algunas notas que importan a nivel operativo:
- El mínimo oficial de OpenProject para una instalación en un solo servidor es una CPU de cuatro núcleos, 4 GB de RAM y 20 GB de espacio libre en disco. Su ejemplo de instancia pequeña enumera por separado 2 núcleos de CPU y 4 GB de RAM para la aplicación, más 2 núcleos de CPU y 4 GB de RAM para PostgreSQL.
- Los requisitos oficiales de autoalojamiento de Plane especifican un mínimo de 2 núcleos de CPU y 4 GB de RAM, con 8 GB recomendados para producción.
- La imagen de Redmine de Cloudzy indica 2 GB de RAM como mínimo. No lo traduzcas en un número garantizado de usuarios: los plugins, el volumen de adjuntos, las peticiones concurrentes y el comportamiento de la base de datos determinan la capacidad real.
Como referencia, el plan estándar de 4 GB de Cloudzy ofrece 2 vCPU, 120 GB de almacenamiento NVMe y 5 TB de transferencia. Cumple el mínimo de RAM de OpenProject pero no el mínimo oficial de cuatro núcleos de CPU, así que usa un plan o configuración a medida con al menos 4 vCPU para OpenProject. Vigila la latencia de la base de datos, las colas de los workers y la presión de memoria antes de escalar; no prometas un multiplicador de rendimiento fijo basándote solo en el tipo de almacenamiento.
Construye sobre un VPS Linux con acceso root, NVMe y la potencia de AMD EPYC.
Ver planes LinuxConclusión de la sección: Redmine puede empezar cerca de 15 $ al mes y Plane cerca de 29 $ al mes con los precios de lista estándar actuales de Cloudzy, antes de promociones. OpenProject necesita al menos cuatro núcleos de CPU según su mínimo oficial, así que calcula su precio a partir de una configuración acorde y no del plan de 2 vCPU y 4 GB.
Cuándo Jira Cloud sigue siendo la respuesta correcta
Autoalojar cambia dólares por tiempo. Existe una configuración de equipo en la que los dólares valen más que el tiempo que ahorrarías, y ese equipo debería pagar a Atlassian.
Precios de lista de Jira Cloud en julio de 2026, tomados de la página pública de precios de Atlassian (las tarifas las fija Atlassian, varían según la periodicidad de facturación y el número de licencias, y cambian sin previo aviso, así que trata cada cifra de abajo como una instantánea de 2026 y confírmala en la página de precios actual de Jira antes de hacer tu presupuesto):
- Gratis: hasta 10 usuarios.
- Standard: around $8 per user per month as of mid-2026.
- Premium: around $14 per user per month as of mid-2026.
- Enterprise: contratos anuales, precios a medida.
At that rate, 25 seats total roughly $2,400 per year. A Cloudzy 4 GB VPS is $28.95 per month at standard list price, or about $347 per year before promotions. Jira Cloud's subscription is therefore roughly seven times the VPS infrastructure cost on those 2026 figures, but that comparison excludes operator time, backups, monitoring, paid support, and any Enterprise features.
Ahora hazte la pregunta honesta: ¿quién se hará cargo de las copias de seguridad, las pruebas de restauración, las actualizaciones, el mantenimiento de Postgres, la monitorización, los certificados SSL, el alta de usuarios y la respuesta a incidentes? Compara la suscripción de Jira Cloud con el coste completo de operar la pila autoalojada, no solo con la factura de la VM. Si nadie asume ese trabajo, el ahorro aparente puede evaporarse rápido.
El valor de Jira Cloud es sobre todo operativo. Atlassian se encarga de la plataforma, las actualizaciones, los parches y las copias de seguridad a nivel de servicio; tu equipo sigue siendo responsable de las políticas de acceso, la integración de identidades, la gobernanza de aplicaciones y las decisiones de retención de datos. Para un equipo en el que nadie puede operar una pila de gestión de proyectos, esa capa gestionada vale de verdad.
Dicho con honestidad: autoalojar encaja en equipos que ya tienen un VPS en marcha, cuentan con un ingeniero cómodo con Docker y tienen capacidad para asumir el trabajo operativo. Jira Cloud encaja en equipos donde nadie de la plantilla quiere ser quien se levante de madrugada porque a Postgres se le acabó el disco.
Si no tienes claro qué tipo de equipo eres, haz un piloto de OpenProject de dos semanas en un VPS. Si tu origen es una versión soportada de Jira Server o Data Center, importa un proyecto representativo con el Migrator en beta; Jira Cloud todavía no está soportado. O el equipo lo adopta y descubres la carga operativa real, o la factura del servicio gestionado de Jira Cloud empieza a parecer más razonable.
Veredicto rápido
- Migras desde una versión soportada de Jira Server o Data Center y quieres una beta integrada de autoservicio: OpenProject. Valida la cobertura de campos específica de la versión antes de producción.
- Equipo liderado por ingeniería que quiere UX moderna y una importación guiada desde Jira: Plane. Requiere 4 GB de RAM, recomienda 8 GB para producción y ofrece acompañamiento personalizado en la migración para equipos con más de 100 licencias.
- Ya usas Redmine y quieres un gestor de incidencias estable en un VPS de bajos recursos: quédate en Redmine. Prueba el tema Bleuclair antes de plantearte una migración.
Preguntas frecuentes
¿Jira Server sigue teniendo soporte en 2026?
No. Atlassian terminó el soporte de Jira Server el 15 de febrero de 2024. Quien lo ejecute en 2026 está sobre software sin soporte y sin parches de seguridad. Los clientes nuevos ya no pueden comprar Jira Data Center, así que las vías realistas con soporte son Jira Cloud o una alternativa mantenida; los clientes existentes de Data Center pueden continuar según el calendario de retirada publicado por Atlassian.
¿Todavía puedo comprar Jira Data Center?
No, no como cliente nuevo. Atlassian dejó de vender Data Center a clientes nuevos el 30 de marzo de 2026. Los clientes existentes pueden comprar nuevas suscripciones, aplicaciones y ampliaciones hasta el 30 de marzo de 2028 y renovar las suscripciones existentes hasta el 28 de marzo de 2029. Después, los productos afectados pasan a ser de solo lectura salvo que Atlassian conceda una prórroga excepcional.
¿Cómo migro de Jira a OpenProject?
El Jira Migrator de OpenProject está actualmente en beta. Se conecta por API a Jira Server o Data Center 10.x y 11.x mediante un Personal Access Token de administrador; Jira Cloud no está soportado. Las páginas oficiales más recientes de julio de 2026 indican que importa proyectos e identificadores; incidencias con descripciones, adjuntos, historial y comentarios; usuarios y grupos implicados; estados y tipos; y campos personalizados soportados. La guía técnica de mayo de OpenProject todavía enumera un conjunto más estrecho, así que confirma la cobertura exacta en la versión que despliegues. Los flujos de trabajo, permisos, esquemas, relaciones entre incidencias y asignaciones de sprint siguen sin soporte o están en la hoja de ruta.
¿Cuál es la alternativa a Jira autoalojada más barata?
Según los puntos de partida documentados actualmente, Redmine sobre la imagen de 2 GB de Cloudzy es la opción más barata. El mínimo de OpenProject en servidor único es de cuatro núcleos de CPU y 4 GB de RAM. Plane requiere 2 núcleos y 4 GB de RAM, con 8 GB recomendados para producción. Las ediciones Community no añaden costes de licencia de software, pero el soporte de pago, las copias de seguridad, la monitorización y el tiempo del operador siguen contando.
¿Plane es un reemplazo real de Jira?
Para equipos liderados por ingeniería, sí. La UX de Plane está más cerca de Linear que de Jira, y su modelo de incidencias encaja con los flujos de trabajo de ingeniería. Plane documenta una importación desde Jira controlada que cubre proyectos, incidencias activas y del backlog, asignaciones, etiquetas, prioridades, sprints, tipos de incidencia, estados, campos personalizados, comentarios y adjuntos. También ofrece acompañamiento personalizado a partir de 100 licencias, pero los equipos con aplicaciones del Marketplace o flujos complejos deberían validar igualmente un piloto.
¿Redmine tiene una herramienta de migración desde Jira?
Oficialmente no. Existen plugins de importación de la comunidad y flujos con CSV, pero la compatibilidad y la cobertura de datos varían según la versión de Jira y de Redmine. Prueba el camino exacto con un proyecto representativo. OpenProject tiene un Migrator integrado en beta para orígenes soportados de Jira Server o Data Center, mientras que Plane ofrece una importación propia guiada.
¿Puedo ejecutar alguno de estos en un VPS pequeño?
La imagen de Redmine de Cloudzy indica 2 GB de RAM como mínimo, lo que son 14,95 $ al mes a precio de lista estándar. OpenProject requiere al menos cuatro núcleos de CPU y 4 GB de RAM. Plane requiere 2 núcleos y 4 GB de RAM, con 8 GB recomendados para producción. El plan estándar de 4 GB de Cloudzy tiene 2 vCPU y figura a 28,95 $ al mes, y a veces las promociones lo bajan. Ejecutar los tres en un mismo VPS pequeño no es un diseño de producción sensato.
