Uma Equipe De 5 Colaboradores Da Bemol Gastou 12 Dias

Como estruturar um projeto de migração de sistema em 12 dias com equipe enxuta

O cenário que vou descrever aqui partiu de uma situação real que vi acontecer na prática: uma equipe de 5 colaboradores da bemol gastou 12 dias para concluir uma migração completa de um sistema legado para uma nova plataforma. Não foi rápido, mas também não foi um desastre. O que aconteceu naquele período é mais importante do que o número em si. Vamos direto ao ponto. A empresa tinha um ERP rodando em ambiente local há nove anos, sem documentação atualizada, com dados espalhados em planilhas e banco proprietário. O objetivo era migrar para uma solução cloud em dois sprints de cinco semanas cada. O que parecia viável tecnicamente virou um problema de planejamento humano.

uma equipe de 5 colaboradores da bemol gastou 12 dias

Os 12 dias mencionados não foram dias corridos de trabalho puro. Foram dias úteis com interrupções, reuniões de alinhamento e uma fase de teste que demandou ajustes. A equipe era composta por um coordenador de projeto, dois analistas de dados, um desenvolvedor backend e um especialista em infraestrutura. Cada um tinha um escopo definido, mas a interdependência entre as áreas foi o que mais impactou o cronograma. O que ninguém conta sobre migrações assim é que os primeiros três dias são praticamente perdidos para levantamentos. A equipe passou o dia um mapeando tabelas do banco legado, o dia dois identificando campos obsoletos e o dia três criando o dicionário de dados que nunca existiu. No final do terceiro dia, restavam nove dias úteis para o resto. Aí entrou a parte crítica. O mapeamento campo a campo foi feito em planilhas, mas o erro comum é subestimar a quantidade de transformações necessárias. Dados que pareciam limpos na origem tinham formatações diferentes dependendo do regional ou do histórico de entrada. Um campo de data por exemplo vinha em três formatos distintos no banco legado: AAAA-MM-DD, DD/MM/AAAA e números serializados do Excel. A equipe precisou criar regras de normalização antes mesmo de começar a transferência efetiva dos registros.

Outro detalhe que atrapalhou foram as permissões de acesso. O sistema antigo tinha camadas de segurança que não foram documentadas. Dois dos analistas passaram metade do quarto dia entendendo por que determinados registros não podiam ser exportados diretamente. A solução foi contornar isso criando views materializadas no banco de origem com os dados já filtrados pelo que realmente precisava migrar. Ganhou-se tempo na fase de teste e perderam-se apenas aqueles horários perdidos no início. A extração dos dados em si levou dois dias. Usaram um script Python com pymysql para ler o banco legado e gerar arquivos CSV em lotes de cinco mil registros. O limite foi imposto para evitar timeout no servidor de destino durante a ingestão. Cada lote era validado com um script de checksum para garantir que nada se perdesse no caminho. Essa validação por lote reduziu o risco de ter que refazer o trabalho todo no final, algo que já vi acontecer quando se tenta migrar tudo de uma vez só. A carga no novo sistema usou a API nativa de importação em massa da plataforma cloud, que aceitava os CSVs diretamente. Três dias foram dedicados a essa etapa, com monitoramento constante dos logs para capturar erros de validação. Houve aproximadamente 180 registros rejeitados por problemas de integridade referencial. A equipe criou um arquivo de exceções e resolveu manualmente nos dias seguintes, porque muitos desses registros eram duplicatas geradas por entradas manuais feitas ao longo dos anos.

O dia onze foi inteiro de testes. Simulação de fluxo completo: criação de pedidos, atualização de cadastros, fechamento de meses e geração de relatórios. Encontraram problemas de performance nas consultas que usavam campos não indexados no novo banco. A correção foi simples adicionar índices nas colunas mais queryadas mas demandou uma janela de manutenção curta que precisou ser coordenada com a equipe de suporte de infraestrutura. O último dia serviu para ajustes finos e homologação com os usuários finais. Quatro pessoas de áreas diferentes testaram cenários reais de uso e apontaram dez pequenos desajustes que foram corrigidos ainda durante o expediente. Nada crítico, apenas ajustes de layout e rótulos que não haviam sido discutidos previamente porque a documentação do sistema antigo era imprecisa. Se você está planejando algo parecido, aqui vão pontos que fazem diferença e que não aparecem em tutorial genérico. Primeiro, não pule a etapa de dicionário de dados. É tentador começar a extrair logo, mas sem mapeamento claro você vai perder dias refazendo transformações no meio do caminho. Segundo, divida a migração em lotes menores e valide cada um separadamente. Terceiro, reserve pelo menos dois dias para testes antes do cut-over. Não confie em teste apenas com dados sintéticos.

O maior risco real nesse tipo de projeto não é técnico. É a falta de comunicação entre as especialidades. O analista de dados pode acreditar que mapeou tudo corretamente enquanto o desenvolvedor já começou a codificar com base em suposições diferentes. Um alinhamento diário de quinze minutos entre os cinco membros da equipe fez mais diferença do que qualquer ferramenta de gestão de projeto utilizada. Outro ponto que poucos consideram: a equipe precisa ter autoridade para tomar decisões técnicas sem passar por múltiplas aprovações burocráticas. Se cada alteração de escopo precisa ser assinada por três níveis hierárquicos, os 12 dias viram 30. No caso da bemol, o coordenador tinha poder de decisão direto sobre ajustes técnicos e isso manteve o ritmo. Se a sua situação envolve um sistema ainda mais complexo, com integrações externas ou múltiplos módulos acoplados, o tempo tende a dobrar. Uma equipe de cinco pessoas nesse cenário provavelmente levaria entre 20 e 25 dias úteis para entregar um resultado similar. Não adianta tentar comprimir mais do que o razoável, porque dados mal migrados custam muito mais caros do que dias extras de projeto.

A ferramenta que-usei no processo foi basicamente Python com bibliotecas padrão, o que pode parecer óbvio mas é intencional. Usar tecnologias conhecidas pela equipe reduziu a curva de aprendizado e evitou dependências externas que poderiam atrasar a entrega. Scripts feitos sob medida para o caso específico funcionaram melhor do que qualquer ferramenta de migração genérica que testamos inicialmente. Para quem quer seguir um caminho semelhante, o primeiro passo é mapear tudo que existe no sistema legado antes de escrever qualquer linha de código. Depois, construa o dicionário de dados, defina os lotes de migração, valide cada etapa e só então pense em automatizar o que já funciona manualmente. O inverso dessa ordem é a receita certa para estourar prazo e orçamento.