Riscos de portal desatualizado: por que adiar a atualização sai mais caro

Por que adiar a atualização encarece a migração

Os riscos de portal desatualizado são três. A versão deixa de receber correções de segurança. Os add-ons e as dependências param de acompanhar a plataforma. E fica cada vez mais difícil encontrar quem conheça aquela versão a fundo. Os três pioram com o tempo: quanto maior a distância entre a versão instalada e a versão suportada, maior o trabalho para atravessá-la. O caminho é sair em etapas, começando por um diagnóstico da instalação.

Este texto é para quem responde pelo portal institucional do órgão, sabe que a instalação está velha e precisa explicar internamente por que a atualização não pode continuar no fim da fila.

A atualização de CMS adiada quase sempre tem motivo razoável: o portal está no ar e sempre aparece uma demanda mais visível. Só que o custo da espera não entra em nenhum relatório.

O custo que cresce a cada versão pulada

CMS é o sistema de gestão de conteúdo, onde a equipe edita e publica as páginas do portal. Cada versão nova de um CMS muda alguma coisa por dentro: a forma de guardar o conteúdo, a maneira como os módulos conversam com a plataforma, os componentes de que ela depende.

Quem atualiza versão a versão absorve essas mudanças aos poucos. Quem pula várias precisa absorver todas de uma vez. E elas não apenas se somam, elas se cruzam. Um ajuste que seria pequeno numa atualização seguida passa a depender de outros ajustes, que dependem de ferramentas de migração que talvez já nem sejam mantidas para aquele ponto de partida.

Na prática, sair de uma versão muito antiga vira um projeto: inventário, testes, adaptação de código e, às vezes, passos por versões que só servem de ponte.

Quando só uma pessoa conhece a instalação

O segundo custo é de conhecimento. Uma instalação antiga costuma carregar configurações feitas há muito tempo, ajustes no servidor e customizações que ninguém documentou, porque na época pareciam óbvias.

Enquanto quem fez esses ajustes está por perto, o portal segue. Quando essa pessoa muda de área ou o contrato termina, o órgão descobre um sistema em produção que ninguém explica por inteiro. Não é descuido de ninguém: é o efeito de um longo período sem uma atualização que obrigasse a registrar o que existe.

Há ainda o mercado. Quanto mais antiga a versão, menos profissionais trabalharam com ela recentemente. Isso pesa no dia em que o órgão precisa de alguém novo para mexer na instalação.

Segurança sem correção: o risco que não aparece no painel

Correção de segurança é uma atualização publicada pelo projeto para fechar uma falha encontrada no software. Enquanto a versão está dentro do período de suporte, as falhas descobertas recebem correção. Depois que ela sai do suporte, as falhas continuam sendo descobertas e divulgadas, mas a correção não chega mais.

É isso que significa um CMS sem suporte de segurança. Não quer dizer que o portal esteja comprometido. Quer dizer que ele acumula falhas conhecidas que ninguém vai corrigir naquela versão. Atualizar também não torna o portal seguro: reduz a exposição a falhas que já são públicas.

Esse risco é adiado por um motivo simples: ele não aparece para quem publica. O painel abre, as páginas carregam, o formulário envia. Nada no uso diário avisa que a versão saiu do suporte.

Como saber se a sua versão ainda recebe correção

A resposta está na política oficial do projeto, e não na impressão de que "está tudo funcionando". No caso do Plone, CMS de código aberto, a política de atualizações de segurança define por quanto tempo cada versão principal recebe correção. E, dentro de cada versão secundária, só a atualização de correção mais recente é coberta. Quem ficou numa atualização anterior da mesma linha já está fora da cobertura.

A mesma política diz que a equipe de segurança do Plone pode, a seu critério, liberar correções para versões que já não têm suporte oficial. É uma exceção, não algo com que o órgão possa contar no planejamento.

Para conferir, bastam duas informações: a versão exata instalada no servidor e a data em que o suporte dela termina, segundo a política. Se o portal usa outro CMS, a lógica é a mesma. Projetos mantidos publicam o próprio ciclo de suporte.

O que fazer enquanto a migração não sai

Entre decidir atualizar e concluir a migração, o portal continua no ar. Algumas medidas reduzem a exposição nesse intervalo. Nenhuma delas substitui a atualização.

• Inventariar o que está instalado: versão do CMS, add-ons e componentes do servidor.
• Desativar add-ons que ninguém usa. Código instalado e esquecido continua exposto.
• Restringir o acesso administrativo a quem realmente precisa e revisar contas antigas.
• Acompanhar os anúncios de segurança do Plone, para saber quando surge uma falha que afeta a sua versão.
• Testar o backup, restaurando a cópia num ambiente separado. Backup que nunca foi restaurado é uma suposição.

Essas tarefas costumam caber na rotina de manutenção do portal. O que esse contrato precisa cobrir está em o que entra na sustentação de um portal.

Add-ons e dependências que param no tempo

Add-on é um módulo que acrescenta uma função ao CMS: um formulário próprio, uma galeria, uma integração com outro sistema. Dependência é qualquer componente de terceiros de que o portal precisa para funcionar, como as bibliotecas de código e a própria linguagem de programação.

Nenhum portal roda só sobre o CMS. E cada peça em volta dele tem o seu próprio ritmo de manutenção.

O add-on que trava a atualização

Muitos add-ons são mantidos por voluntários da comunidade, por outra instituição ou por um fornecedor que já não está no contrato. Quando quem mantém para, o add-on fica preso à última versão do CMS com que funcionava.

Isso transforma um módulo pequeno num obstáculo grande. O portal não pode subir de versão sem ele, porque alguma área depende daquela função. E ele não sobe junto, porque ninguém o adaptou. A atualização fica parada à espera de uma peça que talvez nunca chegue.

As saídas são adaptar o add-on, trocá-lo por outro mantido ou reconstruir a função. Para escolher, é preciso saber quais add-ons existem e quem cuida de cada um.

Linguagem e bibliotecas fora do ciclo de suporte

O mesmo raciocínio vale para a linguagem em que o CMS é escrito. O Plone roda em Python, e o Python publica um ciclo de vida das versões com fases bem definidas. Logo depois do lançamento, uma versão recebe correções de falhas e de segurança. Depois, passa a receber só correções de segurança. Por fim, chega ao fim de vida: segundo a própria documentação, a partir daí nenhuma mudança é feita naquela versão.

Uma instalação antiga tende a depender de uma versão antiga da linguagem e das bibliotecas que a acompanham. O resultado é uma camada a mais sem correção, por baixo do CMS. E atualizar o CMS pode exigir atualizar a linguagem, o que mexe em tudo o que estava apoiado nela.

Planejar a saída em etapas

A atualização de portal de governo raramente cabe num único passo, e não precisa caber. Em etapas, cada decisão é tomada com informação, o risco fica distribuído e o portal segue no ar durante o trabalho.

Diagnóstico da instalação atual

O diagnóstico é o levantamento do que existe hoje, antes de qualquer decisão sobre o destino. Ele responde a perguntas como:

• Qual é a versão exata do CMS e da linguagem em que ele roda.
• Quais add-ons estão instalados, quais estão em uso e quem mantém cada um.
• Quais customizações foram feitas para o órgão: aparência, tipos de conteúdo, fluxos de aprovação.
• Com quais sistemas o portal se integra, como autenticação, ouvidoria ou bases de dados.
• Quanto conteúdo existe, entre páginas, arquivos e imagens, e quanto dele ainda é acessado.
• Quais endereços estão publicados e aparecem citados em documentos, normas e outros sites.

Com essas respostas, custo e prazo deixam de ser estimativa no escuro e passam a depender de fatores conhecidos. É por esse levantamento que começa a frente de migração e atualização de versão de Plone para governo.

Atualizar no mesmo CMS ou trocar de plataforma

O diagnóstico também ajuda a decidir se vale continuar no mesmo CMS. Quando o portal tem muitas áreas publicando, com fluxo de aprovação e permissões por seção, ficar na plataforma costuma preservar mais do que trocá-la. Quando o volume editorial encolheu e a estrutura ficou maior que a necessidade, a troca pode fazer sentido. Os critérios dessa escolha estão na comparação entre Plone e WordPress.

Uma ordem possível para a saída

A sequência muda conforme o diagnóstico, mas costuma seguir esta ordem:

1. Diagnóstico da instalação, com o inventário descrito acima.
2. Decisão sobre cada add-on: adaptar, substituir, reconstruir ou aposentar.
3. Migração em homologação, um ambiente separado da produção, onde a equipe de conteúdo confere o resultado antes de qualquer mudança no ar.
4. Redirecionamento de cada endereço que mudar, seguindo um mapa de redirecionamentos.
5. Virada, com o portal atualizado entrando no lugar do antigo e um plano de retorno caso algo falhe.
6. Sustentação, para que a versão nova receba as próximas atualizações no ritmo certo e o portal não volte ao ponto de partida.

O último item é o que evita repetir a história. Atualizar com regularidade costuma dar menos trabalho do que atravessar várias versões de uma vez.

O primeiro passo é o diagnóstico. Se o portal do seu órgão roda em Plone, conheça a frente de migração e atualização de versão de Plone para governo. Se ele roda em outra plataforma e a decisão for substituí-lo, veja a criação de sites e portais institucionais.