Os principais problemas que você vai encontrar no dia a dia
Muita gente pergunta quais eram os principais pontos de atenção quando se trabalha com integração de sistemas legados e migração de dados. A resposta não é longa, mas exige experiência prática porque a teoria quase nunca avisa sobre os detalhes que realmente doem.
quais eram os principais gargalos técnicos
O primeiro problema é sempre a documentação. Ou melhor, a falta dela. Você chega no projeto e descobre que o sistema atual foi construído sobre decisões tomadas por pessoas que saíram há três anos. O código existe, mas ninguém sabe por quê certas tabelas foram normalizadas daquele jeito ou por que o pipeline de dados tem aquele delay de 45 minutos. Eu aprendi da forma mais custosa: passei duas semanas tentando entender um job que processava arquivos CSV sem saber que ele dependia de um arquivo de configuração que não estava no repositório, só no disco de uma máquina que depois foi descartada. A solução foi rodar um strace no processo antes de matá-lo e capturar todas as chamadas de sistema. Levou seis horas, mas salvou o prazo. O segundo gargalo é a qualidade dos dados que chegam. Sempre chega pior do que o esperado. Campos com formatação inconsistente, datas em formatos diferentes dentro da mesma tabela, valores nulos que na verdade significam coisas distintas. Se você não validar isso antes de começar qualquer migração, vai passar semanas corrigindo erros em produção. Recomendo rodar um script de profiling rápido em todos os campos antes de mais nada — conta quantos valores únicos, quantos nulos, qual a distribuição de tamanho. Em cinco minutos você descobre se o campo "CEP" tem 15% de entradas vazias ou se o campo "data_criacao" mistura ISO 8601 com barras.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O terceiro ponto é dependência de APIs que não estão documentadas. Sistemas legados frequentemente expõem endpoints que ninguém mais usa, mas que algum outro serviço ainda consome. Eu vi um caso em que uma API REST interna foi descontinuada oficialmente, mas um microserviço de relatórios continuava chamando ela todos os minutos porque ninguém havia removido o agendamento. O endpoint retornava 404 silenciosamente e o relatório simplesmente não gerava mais dados. A equipe de relatórios achava que estava tudo funcionando porque o job executava sem erro. Descubra essas dependências escondidas rodando um rastreamento de rede nos containers ou serviços críticos durante um período de uso normal. Leva alguns dias, mas evita surpresas na virada do ambiente. Outro detalhe que ninguém avisa: a latência entre ambientes. Desenvolvimento, homologação e produção rodam em hardwares diferentes, com volumes de dados diferentes. Uma query que leva 2 segundos em homologação pode levar 40 minutos em produção só porque o índice que existe na base de teste não foi replicado. Sempre valide performance em produção antes de fechar qualquer migração. Testes em homologação dão uma falsa sensação de segurança.
A questão da governança também é subestimada. Quando você começa a mexer em dados que várias áreas usam, cada uma tem uma versão diferente do que "aquela coluna significa". Eu já vi dois times concordarem com o esquema de banco de dados em uma reunião e no dia seguinte cada um aplicar uma transformação diferente porque a definição de "cliente ativo" era diferente para cada um. Resolver isso exige um dicionário de dados assinado por todas as partes interessadas antes de qualquer linha de código ser escrita. Sem isso, você vai passar mais tempo resolvendo conflitos de interpretação do que implementando. Por fim, a questão operacional pós-migração. A maioria dos projetos foca 90% do esforço em transferir os dados e testa a aplicação. Poucos pensam em monitoramento, rollback e responsabilidade. Se a migração falhar às 3h da manhã, quem recebe o alert? Qual é o procedimento de rollback e ele foi testado? Quanto tempo leva para voltar ao estado anterior? Eu recomendo criar um playbook de recuperação com tempos estimados para cada cenário antes de fazer o cutover. Sem isso, você está torcendo para não precisar dele.
