Fim do suporte ao Atlassian Connect a 31 de janeiro de 2027: migrar aplicações personalizadas do Jira e do Confluence para o Forge

A 31 de janeiro de 2027, a Atlassian termina o suporte ao Connect, a framework sobre a qual foi construída a maior parte das aplicações mais antigas do Jira e do Confluence Cloud. A partir desse dia, a Atlassian diz que «só vai corrigir vulnerabilidades de segurança críticas no Connect», e que uma aplicação privada que ainda corra em Connect «deixará de ter suporte e poderá deixar de funcionar corretamente».

Se todas as aplicações do seu site vieram do Atlassian Marketplace, isto é trabalho dos seus fornecedores, e a maioria já o fez: a Atlassian informou em agosto de 2026 que «mais de 95 % dos lugares de aplicações pagas já foram migrados para o Forge».

Este artigo é para o outro caso. A sua empresa tem uma aplicação do Jira ou do Confluence que alguém construiu por encomenda: um programador interno, um prestador externo, um parceiro. Foi instalada por link, não comprada. Ninguém de fora da empresa a vai migrar, e quem a escreveu pode já não estar por perto.

O que significa o fim do suporte, e o que não significa

Não há nenhuma data de desligamento publicada. A Atlassian não disse que as aplicações Connect deixam de funcionar a 1 de fevereiro de 2027, e o anúncio do calendário original dizia que «os clientes que têm aplicações Connect instaladas não vão perder o acesso à aplicação».

Não leia isto como uma garantia. O que muda é que ninguém na Atlassian volta a cuidar do Connect:

• Só se corrigem as vulnerabilidades de segurança críticas. Os bugs não críticos ficam.
• «As descontinuações de funcionalidades do Connect vão acontecer com pouco aviso prévio.»
• O suporte da Atlassian «não vai conseguir resolver problemas causados por essa tecnologia antiga».
• Nas palavras da própria Atlassian: «O Connect não vai manter-se estável depois do fim do suporte. As avarias vão aumentar e as incompatibilidades vão agravar-se.»

Por isso, o risco é gradual, não um precipício. Uma falha plausível: o Jira altera uma página, um painel Connect deixa de ser apresentado, e não há ninguém a quem abrir um pedido de suporte. Se essa aplicação estiver no meio de um circuito de aprovação financeira ou de um service desk virado para os clientes, vai sabê-lo pelas pessoas que dependem dela.

O que já aconteceu

A data de janeiro é o último passo de uma sequência que começou em 2025.

• Setembro de 2025: o Marketplace deixou de aceitar novas aplicações Connect.
• 31 de março de 2026: as atualizações ficaram congeladas. As orientações da Atlassian para aplicações personalizadas diziam-no sem rodeios: depois dessa data, «deixará de ser possível enviar atualizações para aplicações Connect». O código no seu próprio servidor continua a ser seu para alterar, mas o que a aplicação declara ao Jira ou ao Confluence (os seus módulos, scopes e webhooks) fica fixo.
• Março de 2026: o calendário dizia também que «a possibilidade de instalar novas aplicações privadas Connect através de Connected Apps vai deixar de estar disponível». Trate uma desinstalação como um caminho sem volta: não remova uma aplicação privada Connect só para ver o que se estraga.
• Agosto de 2026: a Atlassian adiou o fim do suporte de dezembro de 2026 para 31 de janeiro de 2027. É um mês a mais. Não conte com outro.
• Agora: a Atlassian está a introduzir avisos no Atlassian Administration, onde as aplicações privadas que ainda estão em Connect aparecem «marcadas com o estado LEGACY».

Encontrar as suas aplicações privadas

Comece pelo Atlassian Administration, na página Connected Apps. Tudo o que tiver a etiqueta LEGACY está a correr em Connect. A lista de verificação da Atlassian para identificar uma aplicação privada: se a maioria destes pontos for verdadeira, a migração cabe-lhe a si:

• instalada através de um link direto ou do modo de programador, não a partir do Marketplace;
• não aparece na pesquisa do Marketplace;
• a sua organização mantém o código-fonte;
• não tem informação de licenciamento, e a sua organização é a única que aparece nas instalações;
• não tem a barra lateral de links relacionados na página Connected Apps (as aplicações do Marketplace têm).

A Atlassian acrescenta uma regra prática: uma aplicação cloud personalizada construída há mais de cinco anos é provavelmente uma aplicação Connect, e as aplicações Connect estão alojadas fora da Atlassian, «normalmente num serviço como o Heroku, a AWS, o Azure ou a Google Cloud Platform». O link View app details da aplicação mostra quem é o programador, tanto quanto a Atlassian sabe.

Para cada aplicação, registe cinco coisas antes de alguém mexer no código:

1. O que faz e quem a usa, numa frase que um responsável de negócio reconheça.
2. Onde está o código-fonte. Num repositório que controla, no portátil de um prestador externo, ou em lado nenhum.
3. Onde corre, e que conta paga o alojamento. Se o servidor estiver na conta cloud de um antigo prestador, isso é um risco hoje, não em janeiro.
4. O descritor. Todas as aplicações Connect servem um ficheiro atlassian-connect.json num URL. Lista todos os módulos, scopes e webhooks que a aplicação usa, o que faz dele o inventário mais fiável que vai conseguir.
5. Que dados guarda, e onde: na sua própria base de dados, ou em propriedades guardadas em issues do Jira e páginas do Confluence.

Decida antes de construir

Nem todas as aplicações privadas merecem uma migração. O conselho da própria Atlassian é verificar se uma funcionalidade nativa do Jira ou do Confluence já faz o mesmo trabalho e migrar apenas o que a organização ainda precisa. As aplicações antigas preenchiam muitas vezes uma lacuna que o produto entretanto fechou.

Cada aplicação recebe uma de três respostas: migrar, substituir por algo com suporte, ou retirar. Retirar é um desfecho legítimo. A Atlassian recomenda que, se abandonar uma aplicação, avise os utilizadores e agende a remoção antes de 31 de janeiro de 2027, em vez de a deixar falhar sozinha.

O que implica passar para o Forge

O Forge não é o Connect com outro nome. O modelo de alojamento, o modelo de segurança e o modelo de interface são todos diferentes, e é por isso que a Atlassian diz até aos donos de aplicações simples que comecem cedo uma prova de conceito.

Alojamento

Uma aplicação Connect é um serviço web que a sua equipa gere. Uma aplicação Forge corre na infraestrutura da Atlassian, como funções com limites rígidos: 25 segundos para uma função acionada por um utilizador, até 900 segundos para eventos assíncronos e acionadores agendados. Uma aplicação Connect que faz uma sincronização de dez minutos enquanto o utilizador espera tem de passar esse trabalho para eventos assíncronos, e tudo o que demore mais de quinze minutos tem de ser dividido em passos. As chamadas para o exterior também são restringidas: qualquer domínio não declarado no manifesto da aplicação é rejeitado.

Manter o backend que já tem

O Forge Remote permite que uma aplicação Forge chame serviços alojados noutro lado, permite que o seu servidor confirme que um pedido veio mesmo do Forge e dá ao seu backend tokens para chamar as APIs da Atlassian. Para uma aplicação privada com anos de lógica de negócio no servidor, este é muitas vezes o caminho mais curto: a interface e os pontos de integração passam para o Forge, a lógica fica onde está.

A contrapartida: o Forge Remote pode tornar uma aplicação inelegível para o programa Runs on Atlassian. Para uma ferramenta interna isto pesa menos, mas a sua equipa de segurança deve aceitá-lo com conhecimento de causa.

Autenticação e permissões

As aplicações Connect autenticam-se com JWT assinado com um segredo partilhado. O Forge substitui isso por scopes OAuth 2.0 declarados no manifesto e, nos backends remotos, por um Forge Invocation Token que o seu servidor valida em vez de um JWT.

Cada chamada autenticada à API do Jira ou do Confluence é então feita asUser, com as permissões da pessoa que está a usar a aplicação, ou asApp, que, nas palavras da Atlassian, funciona «independentemente de quem usa a aplicação». Percorrer cada chamada e escolher de forma consciente é a revisão de segurança mais importante de toda a migração.

Há uma diferença que apanha as equipas desprevenidas. Os módulos Connect são apresentados por omissão a utilizadores sem licença e anónimos; os módulos Forge não, a menos que o manifesto o ative com unlicensedAccess. Se a sua aplicação mostra alguma coisa a clientes do service desk ou a leitores anónimos do Confluence, teste esse percurso à parte.

A interface

As páginas Connect são iframes que comunicam com o Jira ou o Confluence através da API JavaScript da Atlassian. O Forge dá-lhe duas opções:

• UI Kit: uma framework baseada em React que apresenta componentes nativos da Atlassian. Rápida e consistente, mas constrói-se a partir dos componentes da Atlassian: o HTML personalizado pode não funcionar, e os únicos recursos estáticos que aceita são imagens.
• Custom UI: o seu próprio HTML, CSS e JavaScript num iframe, a comunicar com o produto através de @forge/bridge.

Um frontend em iframe já existente passa normalmente para Custom UI com menos alterações. Painéis pequenos e ecrãs de definições são muitas vezes mais rápidos de refazer em UI Kit.

Dados

É aqui que as migrações correm mal. O Forge tem o seu próprio armazenamento alojado: um armazenamento chave-valor, um armazenamento de entidades personalizadas, o Forge SQL e um armazenamento de objetos em pré-visualização. Os dados são isolados por instalação e guardados na mesma localização que o site Jira ou Confluence de origem, por isso a residência dos dados vem sem configuração adicional.

O que isto significa para uma aplicação privada:

• Os dados que estão na base de dados própria da aplicação Connect ou são passados para o armazenamento do Forge por uma tarefa de migração pontual, ou ficam onde estão e são acedidos através do Forge Remote.
• Tudo o que a aplicação Connect guardou do lado da Atlassian com a sua própria app key deve ser exportado enquanto a aplicação antiga ainda corre. Teste cedo se a nova aplicação o consegue ler; não parta do princípio de que sim.
• O Forge guarda os dados alojados durante 28 dias após uma desinstalação, mas uma reinstalação não os repõe automaticamente.

Escreva a migração como um script repetível, com contagens que possa verificar, ensaie-a num site de teste e guarde a exportação.

A via incremental, e porque provavelmente não é a sua

A Atlassian criou um caminho mais suave para as aplicações Connect: adotar o Forge de forma incremental, manter as instalações existentes, converter o descritor num manifesto Forge e migrar uma família de módulos de cada vez, com migração de dados integrada para alguns módulos, como macros, campos personalizados e validadores de workflow.

O senão está no primeiro parágrafo do guia: «A adoção incremental do Forge só está disponível para aplicações Connect do Confluence e do Jira que já estejam listadas no Marketplace.»

Para uma aplicação privada, conte com uma aplicação Forge nova. Implementa-a no ambiente de produção, partilha-a com o seu site através de um link de instalação da consola de programador, põe-na a correr ao lado da antiga aplicação Connect enquanto os dados são migrados e os utilizadores testam, e depois remove a aplicação Connect.

Os guias de adoção continuam a ser úteis pela correspondência entre módulos, tal como a lista de funcionalidades do Connect que não existem no Forge: vários módulos do Jira Service Management e o suporte à aplicação móvel estão marcados como não planeados, e o jiraReports ainda está em análise. Compare o seu descritor com essa lista na primeira semana. Uma lacuna aí muda o desenho da solução.

Um plano a contar para trás a partir de 31 de janeiro de 2027

A partir do início de outubro de 2026 faltam cerca de dezassete semanas, e dezembro é curto para toda a gente. Um plano que se aguenta:

1. Esta semana: liste todas as aplicações LEGACY com os cinco factos acima. Confirme quem controla o código-fonte e a conta de alojamento.
2. Até meados de outubro: decida, para cada aplicação, se migra, substitui ou retira. Avise os utilizadores de tudo o que for retirado.
3. Até ao fim de outubro: uma prova de conceito em Forge para a parte mais difícil da aplicação mais difícil. Normalmente é um módulo sem equivalente direto no Forge, ou o que guarda mais dados.
4. Novembro: construir, e correr a migração de dados num site de teste mais do que uma vez.
5. Início de dezembro: instalar a aplicação Forge ao lado da aplicação Connect, migrar uma cópia dos dados e deixar que as pessoas que a usam todos os dias a verifiquem.
6. Janeiro de 2027: migração final, passagem dos utilizadores e remoção da aplicação Connect só depois de a nova ter funcionado sem problemas durante algum tempo.

Um único painel que lê dados do Jira e não guarda nada é um trabalho pequeno. Uma aplicação com base de dados própria, regras de workflow e ligações a outros sistemas precisa de todas essas semanas.

Se falhar a data, nada do que a Atlassian publicou diz que a aplicação deixa de funcionar nesse dia. Mas passa a ter um processo de negócio a correr numa plataforma que o dono deixou de corrigir. Trate esse tempo como emprestado e conclua a migração.

Quando o programador original já não está

A Atlassian trata deste caso diretamente. Se não conseguir identificar nem contactar o dono original da aplicação, ou se já não tiver capacidade de desenvolvimento, sugere recorrer a um Solution Partner. E é igualmente clara quanto ao facto de que, sem o código-fonte, «pode ser necessário reconstruir no Forge a partir do zero».

Mesmo sem código-fonte, não começa às cegas. O descritor lista tudo aquilo a que a aplicação se liga, o seu comportamento pode ser observado num site de teste e, se a sua empresa paga o servidor, pode ver o que está realmente implementado. Uma reconstrução a partir dessas peças é mais lenta do que uma migração, mas é uma quantidade conhecida.

Onde obter ajuda

Pegamos em código que ninguém da equipa atual escreveu, percebemos o que realmente faz e migramo-lo: no caso de uma aplicação Connect, isso significa ler o descritor e o servidor, construir a aplicação Forge e escrever e ensaiar a migração de dados. O nosso trabalho de manutenção de sistemas legados é normalmente onde isto começa, e, se tem programadores mas não os suficientes, o reforço de equipas junta pessoas à sua equipa durante o tempo necessário. Diga-nos o que a aplicação faz e onde corre: escreva para office@c9group.dev.