Sistema antigo que funciona: quando vale mexer

"Está funcionando, não mexe." A frase tem seu fundo de razão. Mexer em um sistema que atende a empresa há anos tem risco, custa dinheiro e raramente aparece para o cliente. O problema é quando ela vira a única política de manutenção.

Um sistema parado no tempo continua funcionando até o dia em que alguma coisa em volta dele muda. Aí a empresa precisa mexer com pressa, que é a pior condição para isso.

Estável e sem manutenção são coisas diferentes

Um sistema estável é aquele que alguém acompanha: as atualizações de segurança entram, o backup é testado e há quem saiba alterar uma regra quando o negócio pede. Um sistema sem manutenção pode ter a mesma cara por fora. A diferença aparece em perguntas simples:

• Quando foi a última vez que alguém alterou o código?
• A versão da linguagem e do banco de dados ainda recebe correções do fabricante?
• Se o servidor fosse perdido hoje, quanto tempo levaria para colocar tudo de pé em outro?
• Quem, na empresa ou fora dela, consegue fazer uma mudança nesse sistema?

Se as respostas forem "faz anos", "não sei", "não sabemos" e "ninguém", o sistema está há anos sem ninguém olhar, e isso é diferente de estar estável.

O que costuma forçar a mudança

Quase sempre vem de fora do sistema:

• O fornecedor encerra o suporte de uma versão e as correções de segurança param de chegar.
• Um parceiro troca a forma de integração e dá um prazo.
• Uma exigência legal pede um dado ou um controle que o sistema não tem.
• A pessoa que conhecia o código sai da empresa.
• O negócio cresce e o sistema, que atendia bem um volume, fica lento com outro.

Nenhum desses eventos avisa com muita antecedência. Quem já sabe como está o sistema consegue reagir com um plano. Quem não sabe começa pelo levantamento, com o prazo correndo.

Quando faz sentido não mexer

Nem todo sistema antigo precisa ser trocado. Se ele atende a um processo que não muda, está isolado da internet, tem backup testado e a empresa aceita o risco de ficar sem ele por um tempo, deixar como está pode ser a decisão certa.

O importante é que seja uma decisão, tomada por alguém que conhece esses fatos, e revista de tempos em tempos. Marcar uma data para olhar de novo, daqui a seis meses ou um ano, evita que a decisão vire esquecimento.

Como decidir por onde começar

Quando a conclusão é que precisa mexer, tentar atualizar tudo de uma vez assusta e trava. Ajuda ordenar por risco:

1. Backup que nunca foi restaurado e versão sem correção de segurança vêm antes de qualquer melhoria.
2. Em seguida, o que só uma pessoa sabe. Registrar como publicar uma versão, como restaurar o backup e onde ficam as senhas já diminui a dependência dela.
3. Depois vem a parte do sistema que impede uma mudança que a empresa quer fazer agora.
4. Tecnologia fora de moda que funciona, tem suporte e alguém mantém pode esperar.

Essa ordem permite começar pequeno. As duas primeiras etapas não mexem no que o usuário vê e já reduzem o risco.

Reescrever ou atualizar

A vontade de jogar tudo fora e fazer de novo é compreensível, sobretudo para quem herdou um código difícil. Só que o sistema antigo carrega anos de regras de negócio que ninguém escreveu em outro lugar. Reescrever do zero significa redescobrir cada uma, quase sempre do jeito mais caro, com o usuário reclamando.

Na maioria dos casos, atualizar em partes dá menos susto. A reescrita completa fica para quando a tecnologia de base não tem mais caminho de atualização, ou quando o negócio mudou tanto que o sistema já não descreve o que a empresa faz.

Um olhar de fora ajuda nessa decisão

Se a sua empresa tem um sistema que funciona e ninguém sabe dizer até quando, vale conversar antes que o prazo venha de fora. A consultoria da Jornada trabalha com escopo, arquitetura e processos de desenvolvimento, e planeja a atualização de uma tecnologia em uso para a operação seguir rodando durante a mudança.