Serviços de modernização de sistemas legados: como avaliar um parceiro

Serviços de modernização de sistemas legados cobrem tudo o que é preciso para levar um sistema envelhecido a um estado mais seguro e mais fácil de mudar enquanto o negócio continua funcionando: auditar o código, garantir acessos e dados, atualizar ou substituir partes da stack e migrar usuários pouco a pouco. Um bom parceiro começa entendendo o seu sistema e os fluxos de dinheiro que não podem quebrar. Um parceiro ruim começa orçando uma reescrita.

Sou um engenheiro sênior brasileiro e liderei a migração de uma plataforma em produção de uma stack legada para uma nova enquanto os usuários continuavam usando o sistema todos os dias. Isso me dá uma preferência por trabalho incremental, então vou deixar claro onde isso pesa. Este guia serve para ajudar você a avaliar qualquer parceiro, seja uma agência, um freelancer ou o seu próprio time.

O que os serviços de modernização de sistemas legados realmente incluem?

O rótulo cobre trabalhos muito diferentes. Pergunte a qualquer fornecedor a quais destes ele se refere:

• Diagnóstico ou auditoria de código: ler o código, a infraestrutura, as dependências e os dados para encontrar o que é frágil, inseguro ou não documentado.
• Estabilização: fazer o build rodar a partir de uma máquina limpa, adicionar monitoramento, backups e testes básicos em torno dos fluxos críticos.
• Refatoração e atualizações: mudar o código ou as versões de framework sem mudar o que o produto faz.
• Replatforming: migrar para uma nova hospedagem ou um novo runtime com poucas mudanças no código.
• Migração incremental: substituir o sistema parte por parte atrás de um mecanismo de roteamento, para que o antigo e o novo rodem lado a lado.
• Migração de dados: mover e sincronizar bancos de dados enquanto os usuários continuam trabalhando.
• Transferência de conhecimento: documentação, runbooks e treinamento para que o seu time assuma o resultado.

Muitas propostas juntam tudo isso sob um único preço. Insista em vê-los como fases separadas, com entregas separadas. Isso permite parar depois do diagnóstico se você não gostar do que descobrir.

O que um bom parceiro deve perguntar antes de orçar?

A qualidade das perguntas é o melhor sinal inicial. Na minha experiência, um parceiro que entende de sistemas legados vai perguntar coisas como:

• Quem tem acesso hoje aos repositórios, servidores, domínios, contas de nuvem e serviços de terceiros? Quem tem as credenciais de administrador?
• O sistema pode ser buildado e publicado do zero, e quem fez o último deploy?
• Por onde passa a receita? Quais telas, jobs ou APIs tratam pagamentos, cadastros ou ações centrais dos usuários?
• O que quebra o negócio se ficar fora do ar por uma hora? E por um dia?
• Existe uma suíte de testes, um ambiente de staging ou documentação, e dá para confiar neles?
• Quem conhece a história do sistema, e essas pessoas ainda estão acessíveis?
• Qual é o motivo real: custo, dificuldade de contratação, segurança, velocidade de mudança ou uma venda ou avaliação de investidores?

Quando analiso um sistema herdado, a pergunta sobre acessos é sempre a primeira que faço, porque todas as outras respostas dependem dela. Mas a última pergunta é a que mais importa. “Queremos que fique moderno” não é um objetivo. “Não conseguimos lançar uma funcionalidade em menos de um mês” é um, e muda o que você deveria contratar.

Quais sinais de alerta indicam uma venda focada em reescrita?

Às vezes a reescrita é a escolha certa, por exemplo quando a plataforma é minúscula ou quando é impossível raciocinar sobre o sistema antigo. Mas ela também é o padrão mais caro, então trate estes pontos como alertas:

• Um preço fechado antes de qualquer acesso ao código. Eles não têm como saber o tamanho do problema.
• “Está tudo ruim” já na primeira reunião. Código antigo que gera dinheiro tem valor. Ele carrega anos de regras de negócio, casos extremos e correções.
• Nenhum plano para rodar os dois sistemas. Uma reescrita significa que o sistema antigo precisa continuar operando em paralelo, e é daí que vêm os custos e atrasos ocultos.
• Uma data de virada big-bang. Um único fim de semana de virada, sem liberação gradual e sem rollback, é uma aposta de que tudo vai dar certo.
• Nenhuma menção aos dados. Mover o banco de dados muitas vezes é mais difícil do que mover o código.
• Uma nova stack escolhida antes de o problema ser entendido. A ferramenta deve vir depois do diagnóstico.
• Propriedade indefinida. Não fica claro quem fica com os repositórios, as contas de nuvem e a documentação no final.

A alternativa a buscar é um plano que coloca um mecanismo de roteamento na frente de tudo antes de escrever código novo e depois move o tráfego pouco a pouco.

Como estruturar os primeiros 30 dias de uma transição?

Entregar um sistema a uma nova agência sem um plano é uma forma comum de perder meses. A ordem que sigo é: primeiro os acessos, depois o build, depois os fluxos de dinheiro, depois os riscos. Os intervalos de dias abaixo são uma regra prática minha, não um cronograma fixo; em um sistema maior, cada fase se estende.

Dias 1–7: acessos

Reúna e verifique cada credencial e conta: controle de versão, hospedagem, DNS, bancos de dados, provedores de pagamento, e-mail, analytics, monitoramento. Transfira a propriedade para contas controladas pela empresa, não por pessoas. Troque os segredos que ex-desenvolvedores conheciam. Confirme que existem backups e que é possível restaurar um deles.

Dias 8–15: o build

Faça o sistema rodar em uma máquina limpa e poder ser publicado por alguém que não seja o desenvolvedor anterior. Anote o que você precisou descobrir. Se você não consegue reproduzir um deploy, não consegue mudar nada com segurança.

Dias 16–23: os fluxos de dinheiro

Rastreie de ponta a ponta o checkout, a cobrança, o cadastro e os fluxos centrais dos usuários. Adicione monitoramento e alguns testes em torno deles. Esses são os fluxos que você protege primeiro e muda por último. Trabalhar no time de carrinho e checkout da Total Wine & More tornou esse hábito permanente para mim: um pequeno erro no checkout custa mais do que um erro grande em quase qualquer outro lugar.

Dias 24–30: os riscos

Agora classifique os problemas: dependências desatualizadas, falhas de segurança, pontos únicos de falha, testes ausentes e problemas nos dados. Transforme-os em um plano sequenciado, com a primeira fatia da migração definida. Um bom parceiro sai desse período com um plano escrito que você pode mostrar a qualquer pessoa, inclusive a outro fornecedor.

Agência, freelancer ou time interno: qual modelo serve para o seu sistema?

Nenhum modelo vence sempre. É assim que eu os comparo, com base na minha própria experiência e não em um estudo publicado. Lembre que já trabalhei com clientes estrangeiros como prestador de serviço (PJ) pela minha própria empresa brasileira, então pondere minha visão sobre a linha do contractor de acordo:

Um padrão que já vi funcionar é um engenheiro sênior externo liderar o diagnóstico e as primeiras fatias da migração, enquanto o seu time interno acompanha e depois assume. Para sistemas grandes, com muitas frentes de trabalho em paralelo, uma agência ou um time misto pode fazer sentido. Em qualquer modelo, pergunte exatamente quem vai mexer no seu código.

Liderar mais de 15 pessoas em web, mobile e e-commerce me ensinou que o gargalo raramente é a velocidade de digitação. É a revisão, as decisões e manter todo mundo trabalhando a partir do mesmo plano.

Que perguntas fazer antes de assinar?

1. O que eu vou ter, por escrito, ao final dos primeiros 30 dias?
2. Como o sistema antigo e o novo vão rodar lado a lado, e como vocês redirecionam o tráfego?
3. Qual é o plano de rollback se uma parte migrada se comportar mal?
4. Como vocês movem e verificam os dados enquanto os usuários continuam trabalhando?
5. Quem vai fazer o trabalho, e qual é a experiência dessa pessoa com sistemas legados?
6. De quem são o código, as contas e a documentação, e como isso é devolvido?
7. Como o trabalho é dividido em fases que eu posso pausar ou interromper?
8. Quais premissas da sua estimativa podem mudar o preço?
9. Posso falar com alguém cujo sistema em produção vocês migraram?

Preste atenção nos detalhes. Respostas fortes mencionam passos concretos, trade-offs e o que pode dar errado. Respostas fracas repetem que tudo será “sem atritos”. Se um contrato envolve propriedade intelectual, proteção de dados ou pagamentos internacionais, peça a um advogado para revisá-lo. Este artigo não é aconselhamento jurídico nem tributário.

Quer uma segunda opinião?

Se você está comparando propostas de modernização ou herdando um sistema, mande um e-mail para me@filipeeduardo.dev com o contexto, e eu digo o que verificaria primeiro.