Manutenção de Sistemas Legados em Brasil

Sistema legado carrega incerteza, e o modelo de cobrança existe para administrá-la. A hora avulsa serve para o pontual — um erro específico, um ajuste de relatório —, mas deixa a empresa sem garantia de agenda no dia em que o sistema parar. O contrato mensal com banco de horas inverte isso: a empresa paga pela disponibilidade e por um tempo de resposta definido, e as horas cobrem correções, pequenas melhorias e atualizações de segurança. O valor da mensalidade acompanha a criticidade (sistema de faturamento exige resposta mais rápida que relatório gerencial), a tecnologia — linguagens raras têm menos profissionais e custam mais — e o estado do código. Por isso o diagnóstico inicial fechado é dinheiro bem gasto: o profissional examina código, banco e infraestrutura e devolve um relatório do que existe, dos riscos e do esforço típico das manutenções. Sem esse mapa, todo orçamento embute gordura para o desconhecido. Desconfie de propostas mensais muito baixas para sistemas críticos: na primeira urgência real, a conta da indisponibilidade aparece.

O tempo de correção em legado tem duas fases invisíveis para quem está de fora: entender e proteger. Entender porque o código antigo acumula camadas de remendos, variáveis sem nome claro e regras de negócio que ninguém lembra por que existem — a investigação da causa costuma consumir mais horas do que a correção em si. Proteger porque mexer num ponto pode quebrar outro: sem testes automatizados, que legados raramente têm, o profissional cuidadoso valida ao redor da mudança antes de publicar, e essa prudência é o que evita transformar um defeito em três. Com o tempo, o ciclo encurta: cada atendimento aumenta o conhecimento acumulado sobre o sistema, e é essa curva que torna o contrato contínuo mais eficiente do que chamar alguém novo a cada incidente. Nos acordos de manutenção, o compromisso formal é o tempo de resposta por severidade — sistema parado tem prioridade sobre tela lenta —, enquanto o prazo de solução se estima caso a caso. Mantenha ambiente de homologação disponível: corrigir direto em produção é a receita clássica do desastre em legado.

A linha divisória do contrato de manutenção é o tamanho da mudança. Dentro da mensalidade vivem as demandas do dia a dia: o erro que aparece, o relatório que precisa de uma coluna, o certificado que vence, a atualização de segurança do servidor, o backup verificado. Bons contratos incluem também uma parcela de manutenção preventiva — atacar aos poucos os pontos mais frágeis do código antes que virem incidente — e a documentação progressiva do sistema, que diminui a dependência da memória de uma pessoa só. Fora da mensalidade ficam os projetos: um módulo novo de porte, a migração do banco de dados, a modernização de uma tecnologia descontinuada. Cada um nasce de proposta própria, e o histórico da manutenção alimenta essas propostas com informação real. Pontos para deixar escritos: o tempo de resposta por severidade, o destino das horas não usadas no mês (acumulam ou expiram), o canal de abertura de chamados e — inegociável — que todo código produzido e toda documentação pertencem à empresa, entregues em repositório de acesso dela.

Manter legado é uma especialidade própria, e o perfil que a atende não é o mesmo do desenvolvedor de produto novo. O primeiro filtro é a tecnologia exata: pergunte há quantos anos o profissional trabalha com aquela linguagem e versão, e peça para conversar com um cliente cujo sistema ele sustenta hoje — a pergunta certa para essa referência é como ele se comporta em incidente de madrugada, não se o código é bonito. O segundo filtro é o método: quem versiona o código, testa em homologação e registra cada alteração está protegendo a sua operação; quem edita direto em produção vai derrubá-la, é questão de tempo. O terceiro é a atitude diante do sistema: desconfie de quem propõe reescrever tudo na primeira reunião, antes de entender por que o sistema é como é — legado que fatura há quinze anos merece diagnóstico, não demolição. Feche com um período de transição assistida com quem mantém o sistema hoje, se essa pessoa existir, e garanta em contrato o acesso da empresa a códigos, senhas e servidores desde o primeiro dia.

A reescrita total é o projeto mais sedutor e mais perigoso do software corporativo: promete recomeço limpo e entrega, com frequência, anos de desenvolvimento paralelo enquanto o legado continua exigindo manutenção — dois custos ao mesmo tempo, e o risco de o sistema novo não cobrir regras de negócio que só existiam no código antigo. Por isso a análise começa por sinais objetivos de esgotamento: dificuldade real de contratar quem trabalhe na tecnologia, fornecedor da plataforma encerrando suporte, incidentes crescendo em frequência, ou o sistema impedindo movimentos do negócio, como vender online ou integrar com parceiros. Sem esses sinais, manter e melhorar aos poucos vence a conta. Quando a modernização se impõe, a estratégia gradual reduz o risco: extrair um módulo por vez para tecnologia nova, mantendo o resto do legado em operação, começando pelo pedaço que mais dói. O diagnóstico técnico pago é o instrumento certo para decidir — um relatório independente sobre o estado do código e as opções com custos comparados, feito por quem não será o beneficiário automático da resposta.

A escolha do modelo depende de quanto o escopo está claro. Se o sistema é bem definido, com telas e regras conhecidas, o preço fechado protege o orçamento — mas qualquer alteração vira aditivo, e isso precisa estar previsto. Se o produto ainda vai ser descoberto, cobrança por hora ou por sprint evita a ficção de estimar o desconhecido, desde que haja teto acordado e relatórios de horas. Alocação mensal faz sentido em produto vivo, com fila constante de melhorias. Em qualquer modelo, some os custos de infraestrutura, serviços de terceiros e licenças, que são recorrentes e não fazem parte do desenvolvimento. Peça uma proposta com premissas explícitas: o que está incluído, o que não está e o que acontece quando uma premissa se mostra falsa.

O prazo cai bastante quando o escopo inicial é cortado ao essencial: o objetivo da primeira versão é colocar em uso o fluxo que gera valor, não cobrir todos os casos. Peça um plano com entregas incrementais e ambiente de homologação disponível desde as primeiras semanas — acompanhar telas funcionando é a única forma confiável de saber se o projeto anda. Reserve tempo para o que costuma ser esquecido: migração de dados existentes, permissões, relatórios, integrações com sistemas de terceiros e testes com usuários reais. Homologações dependem de você e entram no cronograma. Defina desde o início critérios de aceite por entrega, para que aprovação não vire discussão subjetiva, e combine como serão tratados os defeitos encontrados durante o período de garantia.

Escopo definido apenas em conversa é a origem da maior parte dos conflitos em projetos de software. Invista na descoberta: mapear os processos atuais, listar perfis de usuário, desenhar os fluxos principais e escrever as regras que o sistema precisa respeitar, incluindo exceções. Protótipos navegáveis ajudam a validar antes de escrever código, quando mudar ainda é barato. Documente também o que está fora do escopo, com a mesma clareza. Estabeleça um processo simples de mudança: pedido escrito, avaliação de impacto, aprovação e ajuste de cronograma. E defina quem, do seu lado, tem autoridade para decidir — projetos com muitos aprovadores e nenhum decisor final acumulam retrabalho. Guarde as decisões num registro acessível às duas partes, com data e responsável por cada definição.

Peça que o contrato descreva quais testes serão feitos, o que a garantia cobre e o que caracteriza defeito em oposição a nova funcionalidade — sem essa distinção, toda solicitação vira discussão. A documentação mínima inclui instruções de instalação e configuração, variáveis de ambiente, dependências, estrutura do banco de dados e procedimentos de publicação. Some a isso acesso ao repositório de código desde o início do projeto, e não apenas na entrega: código versionado em repositório seu é a garantia mais concreta de continuidade. Combine também backup, monitoramento e plano de recuperação, itens frequentemente esquecidos. Por fim, defina o suporte pós-entrega com canal, horário de atendimento e prazo de resposta por severidade, porque é isso que determina o impacto de uma falha em produção.

Na conversa inicial, observe se as perguntas vão além da tecnologia: quem usará o sistema, qual processo ele substitui, qual o volume esperado, o que acontece se ele ficar indisponível. Peça referências de clientes com projetos parecidos e pergunte a eles sobre cumprimento de prazo, transparência e o que aconteceu quando algo deu errado — é aí que a diferença aparece. Verifique práticas de engenharia: versionamento, revisão de código, ambientes separados, testes e publicação automatizada. Confirme quem executará o trabalho e a estabilidade da equipe. Comece, se possível, com um contrato menor de descoberta ou com uma primeira entrega bem delimitada antes de assinar o projeto completo. E garanta desde o primeiro dia a propriedade do código e o acesso aos ambientes.

O tema vai de R$ 20 a cerca de R$ 15.000 no catálogo, cobrindo desde peças gráficas avulsas até desenvolvimento de software. Alguns valores de referência: site institucional de R$ 1.500 a R$ 8.000, landing page de R$ 800 a R$ 3.500, loja virtual de R$ 2.500 a R$ 15.000 e gestão de redes sociais de R$ 800 a R$ 4.000 por mês. O que define o preço é a quantidade de telas ou peças, o nível de personalização, se há integração com outros sistemas e quem produz o conteúdo. Projeto feito sobre tema pronto custa uma fração do desenvolvimento sob medida, e é a escolha certa para muita gente. Lembre dos custos recorrentes que não estão no orçamento do projeto: domínio, hospedagem, licenças e manutenção. Peça a proposta com escopo, entregas e o que fica fora.

A execução dos serviços do tema fica em média em torno de quatro horas nas entregas menores e passa de setenta horas nos projetos maiores — mas o calendário real é sempre maior que a soma das horas técnicas. O que mais atrasa projeto digital não é código: é conteúdo. Texto, fotos, catálogo de produtos, logotipo em alta resolução e acessos a domínio e hospedagem precisam estar prontos, e quase nunca estão. Combine desde o início quem produz cada item e uma data de corte para entrega do material. Estabeleça também quantas rodadas de revisão estão incluídas e qual é o prazo para você responder cada uma; projeto parado esperando aprovação é o cenário mais comum. Peça um cronograma com etapas — descoberta, protótipo, desenvolvimento, testes, publicação — e um ambiente de homologação para revisar antes de o site ir ao ar.