Fin del soporte de Atlassian Connect el 31 de enero de 2027: cómo llevar las aplicaciones propias de Jira y Confluence a Forge

Una pieza de puzle roja entre piezas verdes

El 31 de enero de 2027, Atlassian pone fin al soporte de Connect, el framework con el que se construyeron la mayoría de las aplicaciones antiguas de Jira y Confluence Cloud. A partir de ese día, según dice Atlassian, «solo atenderá las vulnerabilidades de seguridad críticas en Connect», y una aplicación privada que siga funcionando sobre Connect «dejará de tener soporte y puede dejar de funcionar correctamente».

Si todas las aplicaciones de tu sitio vienen del Atlassian Marketplace, esto es trabajo de tus proveedores, y la mayoría ya lo han hecho: Atlassian informó en agosto de 2026 de que «más del 95% de las licencias de aplicaciones de pago se han migrado a Forge».

Este artículo es para el otro caso. Tu empresa tiene una aplicación de Jira o de Confluence que alguien construyó para vosotros: un desarrollador interno, un contratista, un partner. Se instaló mediante un enlace, no se compró. Nadie de fuera de tu empresa la va a trasladar, y puede que quien la escribió ya no esté.

Qué significa el fin del soporte, y qué no

No hay una fecha de apagado publicada. Atlassian no ha dicho que las aplicaciones Connect dejen de funcionar el 1 de febrero de 2027, y su anuncio original del calendario decía que «los clientes que tengan aplicaciones Connect instaladas no perderán el acceso a la aplicación».

No lo interpretes como una garantía. Lo que cambia es que en Atlassian ya nadie se ocupa de Connect:

Solo se corrigen las vulnerabilidades de seguridad críticas. Los errores no críticos se quedan.
«Las retiradas de funcionalidades de Connect se producirán con poca antelación.»
El soporte de Atlassian «no podrá resolver los problemas causados por esa tecnología heredada».
Con palabras de la propia Atlassian: «Connect no se mantendrá estable tras el fin del soporte. Las roturas aumentarán y las brechas de compatibilidad se ampliarán».

Así que el riesgo es gradual, no un precipicio. Un fallo verosímil: Jira cambia una página, un panel de Connect deja de mostrarse y no hay nadie a quien abrirle una incidencia. Si esa aplicación forma parte de una aprobación financiera o de un service desk de cara al cliente, te enterarás por las personas que dependen de ella.

Lo que ya ha pasado

La fecha de enero es el último paso de una secuencia que empezó en 2025.

Septiembre de 2025: el Marketplace dejó de aceptar nuevas aplicaciones Connect.
31 de marzo de 2026: se congelaron las actualizaciones. La guía de Atlassian para aplicaciones a medida lo dijo claramente: después de esa fecha «ya no podrás publicar actualizaciones de las aplicaciones Connect». El código de tu propio servidor sigue siendo tuyo para cambiarlo, pero lo que la aplicación declara a Jira o a Confluence (sus módulos, ámbitos y webhooks) queda fijo.
Marzo de 2026: el calendario también decía que «la posibilidad de instalar nuevas aplicaciones privadas Connect a través de Aplicaciones conectadas dejará de estar disponible». Trata una desinstalación como un camino sin vuelta: no quites una aplicación privada Connect solo para ver qué se rompe.
Agosto de 2026: Atlassian trasladó el fin del soporte de diciembre de 2026 al 31 de enero de 2027. Es un mes más. No cuentes con otro.
Ahora: Atlassian está desplegando avisos en Atlassian Administration, donde las aplicaciones privadas que siguen en Connect aparecen «marcadas con el estado LEGACY».

Cómo encontrar tus aplicaciones privadas

Empieza en Atlassian Administration, en la página de Aplicaciones conectadas. Todo lo que tenga la etiqueta LEGACY funciona sobre Connect. La lista de comprobación de Atlassian para identificar una aplicación privada: si se cumplen la mayoría de estos puntos, te toca a ti trasladarla:

se instaló mediante un enlace directo o en modo de desarrollo, no desde el Marketplace;
no aparece en las búsquedas del Marketplace;
tu organización mantiene el código fuente;
no tiene información de licencias, y tu organización es la única que figura en las instalaciones;
no tiene la barra lateral de enlaces relacionados en su página de Aplicaciones conectadas (las aplicaciones del Marketplace sí la tienen).

Atlassian añade una regla práctica: una aplicación cloud a medida construida hace más de cinco años probablemente es una aplicación Connect, y las aplicaciones Connect se alojan fuera de Atlassian, «normalmente en un servicio como Heroku, AWS, Azure o Google Cloud Platform». El enlace View app details de la aplicación muestra quién es el desarrollador, hasta donde sabe Atlassian.

Para cada aplicación, apunta cinco cosas antes de que nadie toque el código:

Qué hace y quién la usa, en una frase que reconocería un responsable de negocio.
Dónde está el código fuente. Un repositorio que controlas, el portátil de un contratista o ningún sitio.
Dónde se ejecuta, y qué cuenta paga el alojamiento. Si el servidor está en la cuenta cloud de un antiguo contratista, eso es un riesgo hoy, no en enero.
El descriptor. Toda aplicación Connect sirve un fichero atlassian-connect.json en una URL. Enumera todos los módulos, ámbitos y webhooks que usa la aplicación, lo que lo convierte en el inventario más fiable que vas a conseguir.
Qué datos guarda, y dónde: en su propia base de datos, o en propiedades guardadas en las incidencias de Jira y en las páginas de Confluence.

Decide antes de construir

No toda aplicación privada merece una migración. El propio consejo de Atlassian es comprobar si alguna funcionalidad nativa de Jira o de Confluence hace ya el trabajo, y migrar solo lo que la organización sigue necesitando. Las aplicaciones antiguas a menudo cubrían un hueco que el producto ha cerrado desde entonces.

Cada aplicación recibe una de tres respuestas: migrarla, sustituirla por algo con soporte o retirarla. Retirarla es un resultado legítimo. Atlassian recomienda que, si prescindes de una aplicación, avises a sus usuarios y programes su retirada antes del 31 de enero de 2027, en lugar de dejar que falle por su cuenta.

Qué implica pasar a Forge

Forge no es Connect con otro nombre. El modelo de alojamiento, el modelo de seguridad y el modelo de interfaz son distintos, y por eso Atlassian recomienda incluso a los dueños de aplicaciones sencillas que empiecen pronto una prueba de concepto.

Alojamiento

Una aplicación Connect es un servicio web que gestionas tú. Una aplicación Forge se ejecuta en la infraestructura de Atlassian como funciones con límites estrictos: 25 segundos para una función que activa un usuario, y hasta 900 segundos para los eventos asíncronos y los activadores programados. Una aplicación Connect que ejecuta una sincronización de diez minutos mientras el usuario espera tiene que pasar ese trabajo a eventos asíncronos, y todo lo que dure más de quince minutos tiene que dividirse en pasos. Las llamadas salientes también están restringidas: cualquier dominio no declarado en el manifiesto de la aplicación se rechaza.

Conservar el backend que ya tienes

Forge Remote permite que una aplicación Forge llame a servicios que alojas en otro sitio, permite que tu servidor compruebe que una petición viene realmente de Forge y da a tu backend tokens para llamar a las API de Atlassian. Para una aplicación privada con años de lógica de negocio en su servidor, esta suele ser la vía más corta: la interfaz y los puntos de integración pasan a Forge, y la lógica se queda donde está.

La contrapartida: Forge Remote puede hacer que una aplicación deje de cumplir los requisitos del programa Runs on Atlassian. Para una herramienta interna importa menos, pero tu equipo de seguridad debería aceptarlo con conocimiento de causa.

Autenticación y permisos

Las aplicaciones Connect se autentican con JWT firmado con un secreto compartido. Forge lo sustituye por ámbitos OAuth 2.0 declarados en el manifiesto y, para los backends remotos, por un Forge Invocation Token que tu servidor valida en lugar de un JWT.

Cada llamada autenticada a la API de Jira o de Confluence se hace entonces o bien asUser, con los permisos de la persona que usa la aplicación, o bien asApp, que con palabras de Atlassian funciona «independientemente de quién use la aplicación». Repasar cada llamada y elegir de forma deliberada es la revisión de seguridad más importante de toda la migración.

Hay una diferencia que pilla desprevenidos a los equipos. Los módulos de Connect se muestran por defecto a los usuarios sin licencia y anónimos; los de Forge no, salvo que el manifiesto lo active con unlicensedAccess. Si tu aplicación muestra algo a los clientes del service desk o a los lectores anónimos de Confluence, prueba ese camino por separado.

La interfaz de usuario

Las páginas de Connect son iframes que hablan con Jira o con Confluence a través de la API de JavaScript de Atlassian. Forge te da dos opciones:

UI Kit: un framework basado en React que muestra componentes nativos de Atlassian. Rápido y coherente, pero construyes con los componentes de Atlassian: el HTML propio puede no funcionar, y los únicos recursos estáticos que acepta son imágenes.
Custom UI: tu propio HTML, CSS y JavaScript en un iframe, que habla con el producto a través de @forge/bridge.

Un front end en iframe que ya exista suele pasar a Custom UI con el menor número de cambios. Los paneles pequeños y las pantallas de configuración suelen ser más rápidos de rehacer en UI Kit.

Datos

Aquí es donde las migraciones salen mal. Forge tiene su propio almacenamiento alojado: un almacén clave-valor, un almacén de entidades personalizadas, Forge SQL y un almacén de objetos en versión preliminar. Los datos se acotan por instalación y se guardan en la misma ubicación que el sitio de Jira o de Confluence anfitrión, así que la residencia de los datos viene sin configuración adicional.

Lo que eso significa para una aplicación privada:

Los datos que están en la base de datos propia de la aplicación Connect o bien se pasan al almacenamiento de Forge con un proceso de migración puntual, o bien se dejan donde están y se accede a ellos mediante Forge Remote.
Todo lo que la aplicación Connect guardó en el lado de Atlassian con su propia clave de aplicación debería exportarse mientras la aplicación antigua siga funcionando. Comprueba pronto si la nueva aplicación puede leerlo; no lo des por hecho.
Forge conserva los datos alojados durante 28 días después de una desinstalación, pero una reinstalación no los restaura automáticamente.

Escribe la migración como un script repetible con recuentos que puedas comprobar, ensáyala en un sitio de pruebas y guarda la exportación.

La vía incremental, y por qué probablemente no es la tuya

Atlassian creó una vía más suave para las aplicaciones Connect: adoptar Forge de forma incremental, conservar las instalaciones existentes, convertir el descriptor en un manifiesto de Forge y trasladar una familia de módulos cada vez, con migración de datos integrada para algunos módulos como las macros, los campos personalizados y los validadores de flujos de trabajo.

La pega está en el primer párrafo de la guía: «La adopción incremental de Forge solo está disponible para las aplicaciones Connect de Confluence y Jira que ya están publicadas en el Marketplace».

Para una aplicación privada, cuenta con una aplicación Forge nueva. La despliegas en el entorno de producción, la compartes con tu sitio mediante un enlace de instalación desde la consola de desarrollo, la ejecutas junto a la antigua aplicación Connect mientras se migran los datos y los usuarios la prueban, y después quitas la aplicación Connect.

Las guías de adopción siguen siendo útiles por su correspondencia de módulos, igual que la lista de capacidades de Connect que no están disponibles en Forge: varios módulos de Jira Service Management y el soporte para la aplicación móvil figuran como no previstos, y jiraReports sigue en estudio. Compara tu descriptor con esa lista la primera semana. Una carencia ahí cambia el diseño.

Un plan hacia atrás desde el 31 de enero de 2027

Desde principios de octubre de 2026 quedan unas diecisiete semanas, y diciembre es corto para todo el mundo. Un plan que se sostiene:

Esta semana: haz una lista de todas las aplicaciones LEGACY con los cinco datos de arriba. Confirma quién controla el código fuente y la cuenta de alojamiento.
Antes de mediados de octubre: decide migrar, sustituir o retirar cada aplicación. Avisa a los usuarios de todo lo que se vaya a retirar.
Antes de que acabe octubre: una prueba de concepto en Forge de la parte más difícil de la aplicación más difícil. Normalmente es un módulo sin equivalente directo en Forge, o el que guarda más datos.
Noviembre: desarrolla, y ejecuta la migración de datos contra un sitio de pruebas más de una vez.
Principios de diciembre: instala la aplicación Forge junto a la aplicación Connect, migra una copia de los datos y deja que la revisen las personas que la usan a diario.
Enero de 2027: migración final, paso de los usuarios a la nueva aplicación, y retirada de la aplicación Connect solo después de que la nueva haya funcionado sin problemas durante un tiempo.

Un solo panel que lee datos de Jira y no guarda nada es un trabajo pequeño. Una aplicación con su propia base de datos, reglas de flujo de trabajo y conexiones con otros sistemas necesita todas y cada una de esas semanas.

Si no llegas a la fecha, nada de lo que ha publicado Atlassian dice que la aplicación deje de funcionar ese día. Pero entonces estás sosteniendo un proceso de negocio sobre una plataforma que su dueño ha dejado de arreglar. Trata ese tiempo como prestado, y termina el traslado.

Cuando el desarrollador original ya no está

Atlassian aborda este caso directamente. Si no puedes identificar o contactar con el dueño original de la aplicación, o ya no tienes capacidad de desarrollo, sugiere recurrir a un Solution Partner. Y deja igual de claro que, sin el código fuente, «puede ser necesario reconstruirla en Forge desde cero».

Incluso sin código fuente, no empiezas a ciegas. El descriptor enumera todo aquello a lo que se conecta la aplicación, su comportamiento puede observarse en un sitio de pruebas y, si tu empresa paga el servidor, puedes ver qué hay realmente desplegado. Reconstruir a partir de esas piezas es más lento que portar, pero es una magnitud conocida.

Dónde conseguir ayuda

Nos hacemos cargo de código que nadie del equipo actual escribió, averiguamos qué hace realmente y lo trasladamos: en una aplicación Connect, eso significa leer el descriptor y el servidor, construir la aplicación Forge y escribir y ensayar la migración de datos. Nuestro trabajo de mantenimiento de sistemas heredados suele ser el punto de partida, y si tienes desarrolladores pero no suficientes, la ampliación de equipos añade personas a tu equipo mientras dure el trabajo. Cuéntanos qué hace la aplicación y dónde se ejecuta: escribe a office@c9group.dev.