Sistema em versão sem suporte: riscos e como sair dela

O sistema funciona. Emite pedido, fatura, gera relatório, e ninguém reclama dele há anos. Até que o provedor avisa que vai desligar o servidor antigo, o novo certificado do banco não é aceito pela biblioteca de comunicação, ou a auditoria pergunta qual é a versão do banco de dados e a resposta é uma que o fabricante não atualiza mais.

Nesse momento a empresa descobre que está rodando um sistema em versão sem suporte: alguma camada dele, seja a linguagem, o framework, o banco de dados ou o sistema operacional do servidor, deixou de receber correções de segurança. O sistema não quebrou. Ele só ficou sem rede de proteção, e o problema cresce em silêncio até virar urgência.

Este texto explica quais são os riscos reais, como descobrir em que situação seu sistema está e como planejar a atualização por etapas, sem cair na tentação de jogar tudo fora e começar do zero.

A resposta curta: quais são os riscos

Rodar software sem suporte traz quatro riscos, e eles se somam com o tempo:

• Segurança. Falhas descobertas depois do fim do suporte não são corrigidas. Elas ficam públicas, documentadas, e qualquer pessoa pode tentar explorá-las. O sistema fica exposto a ataques como ransomware, que já têm receita pronta.
• Compatibilidade. O mundo ao redor continua mudando. Navegadores, certificados digitais, APIs de bancos, de marketplaces e da Receita, bibliotecas de pagamento: cada um deles atualiza seus requisitos, e chega o dia em que a versão antiga simplesmente não conversa mais.
• Mão de obra. Fica cada vez mais difícil achar quem domine aquela versão, e quem domina prefere trabalhar com tecnologia atual. Cada manutenção demora mais e depende de menos pessoas.
• Conformidade. Quem trata dados pessoais precisa adotar medidas de segurança adequadas, e isso é exigência da LGPD. Manter dados de clientes em uma plataforma sabidamente sem correções é difícil de justificar numa auditoria ou depois de um incidente. A avaliação jurídica do seu caso cabe ao advogado ou ao jurídico da empresa.

A saída, na grande maioria dos casos, não é reescrever. É atualizar por camadas, com testes antes de cada passo, como detalhamos ao longo do texto.

Como saber se seu sistema está em versão sem suporte

Não precisa ser programador para fazer o levantamento inicial. Peça à equipe técnica, ou ao fornecedor, uma lista simples com quatro linhas:

Com a lista em mãos, cada versão é comparada com o ciclo de vida publicado pelo fabricante ou pela comunidade. A maioria das tecnologias usadas em sistemas empresariais publica as datas de fim de suporte. A pergunta é direta: essa versão ainda recebe correção de segurança?

Alguns sinais indicam que a resposta provavelmente é "não", mesmo antes do levantamento:

• O servidor nunca foi reinstalado desde que o sistema foi implantado.
• A equipe evita atualizar qualquer coisa porque "da última vez parou tudo".
• Algum componente só funciona em uma máquina específica, com uma configuração que ninguém lembra como foi feita.
• O instalador do sistema pede uma versão antiga de um runtime ou de um driver.
• Ninguém sabe dizer a versão de alguma das quatro camadas.

O último sinal é o mais grave. Se ninguém sabe a versão, ninguém está acompanhando o risco. Se o sistema chegou a esse ponto sem documentação, vale começar pelo roteiro de como assumir um sistema legado sem documentação.

Linguagem, framework, banco e servidor: camadas diferentes

Um erro comum é tratar "o sistema está desatualizado" como um problema único. São quatro problemas, com riscos e esforços bem diferentes.

Sistema operacional do servidor

Costuma ser a camada mais exposta, porque fica de frente para a rede. Também costuma ser a mais simples de resolver quando o sistema roda bem em versões mais novas: monta-se um servidor novo, instala-se a aplicação, testa-se e troca-se. O risco aparece quando a aplicação depende de algo que só existe no sistema operacional antigo, como um componente instalado manualmente ou um driver de impressora fiscal.

Banco de dados

Atualizar o banco é, em geral, mais trabalhoso do que parece. Versões novas mudam o comportamento de consultas, a forma de tratar datas, acentuação e ordenação, e às vezes removem recursos antigos. Uma consulta que funcionava pode ficar lenta ou devolver resultado diferente. Por isso, banco se atualiza com cópia dos dados reais em ambiente separado e comparação de resultados antes da virada. Se a versão nova exige uma licença cara, é a hora de avaliar migrar o banco para PostgreSQL.

Linguagem e runtime

Subir a versão da linguagem quase sempre exige ajustes no código, porque funções antigas são removidas e regras ficam mais rígidas. O tamanho do ajuste depende de quantas versões o sistema pulou. Sair de uma versão um pouco antiga é rotina. Sair de uma versão muito antiga pode exigir passar por versões intermediárias.

Framework e bibliotecas

É onde mora a maior parte do esforço em sistemas web. Frameworks mudam entre versões principais, e bibliotecas de terceiros podem ter sido abandonadas pelo autor. Nesse caso não existe versão nova para atualizar: é preciso substituir o componente por outro, o que já é uma pequena migração.

Separar as camadas permite uma conversa honesta: talvez o servidor e o banco se resolvam rápido, e o trabalho pesado esteja só no framework. Ou o contrário.

Atualizar, migrar ou reescrever

Diante de um sistema sem suporte, a empresa tem três caminhos. A escolha depende do estado do código e do quanto o sistema ainda atende o negócio.

A reescrita total costuma ser a opção mais arriscada, e o motivo é que o sistema antigo carrega anos de regras que não estão documentadas em lugar nenhum. O critério completo para essa decisão está em reescrever ou refatorar um sistema legado.

Na prática, muitas vezes a resposta é uma mistura: atualizar o servidor e o banco, substituir as bibliotecas abandonadas e migrar só o módulo que já precisava mudar por motivo de negócio. Para sistemas que ainda rodam como aplicação instalada em cada máquina, a atualização pode ser a hora de avaliar migrar o sistema desktop para a web, sempre por partes.

Testes antes de atualizar

Atualizar sem testes é trocar um risco conhecido por um desconhecido. O sistema antigo tem problemas de segurança, mas funciona. O atualizado, sem verificação, pode errar um cálculo de imposto sem que ninguém perceba por semanas.

Antes de mexer em qualquer versão, a equipe precisa conseguir responder: como vamos saber que continua funcionando? O mínimo que recomendamos:

1. Listar os fluxos críticos. Emitir pedido, faturar, gerar boleto, calcular comissão, fechar o caixa. São os processos que, se pararem, param a empresa.
2. Criar testes automatizados para esses fluxos. Não é preciso cobrir o sistema inteiro. Basta que os fluxos críticos sejam verificados de forma repetível, com dados conhecidos e resultado esperado.
3. Guardar resultados de referência. Rodar relatórios e cálculos importantes na versão atual e salvar a saída. Depois da atualização, comparar. Diferença inesperada é sinal de alerta.
4. Montar um ambiente de homologação fiel. Cópia do banco de produção, com dados pessoais tratados quando necessário, e a mesma configuração do servidor real.
5. Validar com quem usa. Uma rodada de uso real por pessoas da operação, nos fluxos do dia a dia, encontra o que o teste automatizado não previu.

Esse trabalho não é desperdício. Os testes criados para a atualização continuam servindo depois, em toda mudança futura.

Atualização por etapas: um roteiro prático

Atualizar tudo de uma vez é tentador e perigoso. Se algo der errado, ninguém sabe qual das mudanças causou o problema. O roteiro que seguimos separa o trabalho em passos pequenos e reversíveis:

1. Inventário. Levantar as quatro camadas, as versões, as bibliotecas de terceiros e as integrações externas.
2. Mapa de risco. Para cada item sem suporte, avaliar exposição (está na internet?), dados envolvidos (tem dado pessoal ou financeiro?) e dificuldade de atualizar.
3. Proteções imediatas. Enquanto a atualização não acontece, reduzir a exposição: restringir acesso ao servidor, isolar o banco da internet, revisar senhas e garantir backup testado. Isso não resolve, mas ganha tempo.
4. Rede de testes. Criar os testes dos fluxos críticos descritos na seção anterior.
5. Uma camada por vez. Em geral, começa-se pelo que tem maior risco e menor esforço. Cada passo vai para homologação, é validado e só então vai para produção.
6. Plano de volta. Cada etapa tem um caminho de retorno definido antes de começar: backup do banco, servidor antigo preservado por um período, versão anterior pronta para reinstalar.
7. Virada em janela combinada. Com a operação avisada, em horário de menor movimento e com a equipe acompanhando os primeiros dias.

O prazo varia muito. Uma atualização de servidor e banco com código saudável pode levar algumas semanas. Um sistema que pulou várias versões principais, com bibliotecas abandonadas, pode levar alguns meses, sempre em paralelo com a operação normal. Só o diagnóstico permite estimar com responsabilidade.

Erros comuns nessa situação

• Esperar o problema virar urgência. Atualizar sob pressão, porque o provedor vai desligar o servidor no fim do mês, elimina a chance de testar com calma.
• Atualizar em produção para "ver se funciona". Sem homologação, o teste é feito pelo cliente.
• Achar que isolar a rede resolve. Restringir o acesso ajuda a ganhar tempo, mas falhas na aplicação continuam acessíveis para quem usa o sistema.
• Juntar a atualização com funcionalidades novas. Misturar as duas coisas torna impossível saber se um erro veio da versão nova ou da regra nova.
• Reescrever por impulso. A versão sem suporte é um problema de plataforma. Raramente é motivo, sozinha, para jogar fora as regras de negócio que funcionam.

Como não voltar a essa situação

Sistemas chegam a versões sem suporte por um motivo simples: atualização nunca foi tratada como trabalho recorrente. Ela fica para depois, até que "depois" vire anos. Esse acúmulo é uma das formas mais perigosas de dívida técnica, porque não gera só lentidão, gera risco com data para vencer.

Para evitar a repetição:

• Mantenha um inventário vivo das versões de cada camada, com as datas de fim de suporte anotadas.
• Reserve capacidade fixa em cada ciclo de desenvolvimento para atualizações pequenas e frequentes. Subir uma versão por vez dá muito menos trabalho do que pular várias de uma só vez.
• Automatize a verificação de dependências. Existem ferramentas que avisam quando uma biblioteca usada pelo sistema tem falha conhecida ou versão nova.
• Mantenha os testes dos fluxos críticos em dia. Com eles, cada atualização vira rotina, não projeto.
• Inclua atualização no contrato de manutenção. Quem cuida do sistema deve responder também pela saúde da plataforma, não só por correções e funcionalidades. É parte do que chamamos de manutenção evolutiva de software.

Checklist para levar à próxima reunião

• Sabemos a versão do sistema operacional, do banco, da linguagem e do framework?
• Alguma dessas versões está sem atualização de segurança?
• O servidor ou o banco ficam acessíveis pela internet?
• Temos backup testado, com restauração já feita pelo menos uma vez?
• Existem testes automatizados dos fluxos críticos?
• Temos ambiente de homologação separado da produção?
• Há alguém nomeado responsável por acompanhar versões e fim de suporte?

Se duas ou mais respostas forem "não" ou "não sei", o próximo passo é um diagnóstico, antes que o prazo seja definido por um fornecedor externo ou por um incidente.

Perguntas frequentes

O que significa fim de suporte de um software?

Fim de suporte é a data a partir da qual o fabricante ou a comunidade deixa de publicar correções, inclusive de segurança, para uma versão de software. O sistema continua funcionando, mas falhas descobertas depois dessa data não são corrigidas. A maioria das tecnologias usadas em sistemas empresariais publica essas datas no seu ciclo de vida.

Usar sistema sem suporte descumpre a LGPD?

Não diretamente: a LGPD não proíbe uma versão específica de software, mas exige que quem trata dados pessoais adote medidas de segurança adequadas. Manter dados de clientes numa plataforma sabidamente sem correções de segurança é difícil de justificar numa auditoria ou depois de um incidente. A avaliação jurídica de cada caso cabe ao advogado da empresa.

Isolar o servidor da internet resolve o risco de um sistema sem suporte?

Não resolve, só ganha tempo. Restringir o acesso ao servidor, isolar o banco da internet e revisar senhas reduzem a exposição enquanto a atualização é planejada, mas falhas na aplicação continuam acessíveis para quem usa o sistema. A solução para um sistema sem suporte é atualizar as camadas afetadas, com testes antes de cada passo.

Quanto tempo leva para atualizar um sistema sem suporte?

Varia muito, e só o diagnóstico permite estimar. Uma atualização de servidor e banco de dados com código saudável pode levar algumas semanas; um sistema que pulou várias versões principais, com bibliotecas abandonadas, pode levar alguns meses. Nos dois casos, a atualização acontece por etapas, em paralelo com a operação normal da empresa.

Como a Pervian Tech trabalha atualização de sistemas

Na Pervian Tech, atualizar um sistema sem suporte começa pelo inventário e pelo mapa de risco, dentro do trabalho de arquitetura de software. Levantamos as versões de cada camada, as bibliotecas abandonadas e os fluxos críticos, e devolvemos um plano em linguagem de negócio: o que proteger já, o que atualizar primeiro e onde está o trabalho pesado.

A execução é por etapas, com testes antes de cada passo e caminho de volta definido, para que a operação não pare. Quando parte do sistema precisa de mais do que atualização, o plano se conecta à modernização de sistemas legados, sem reescrita por impulso. Outros textos sobre o tema estão em modernização de sistemas.

Cada plano é sob medida, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se você suspeita que alguma camada do seu sistema está sem suporte, conte como ele está montado hoje.