Estimativa de uma migração de dados

A migração em si é a parte fácil. A etapa de reconciliação que você esqueceu é onde estão as dificuldades.

Uma migração de dados — transferir dados de um sistema para outro, ou de um formato para outro dentro do mesmo sistema — se assemelha a uma transformação. Ler da fonte, transformar, gravar no destino, redirecionar o tráfego. A equipe vota na transformação. A transformação costuma ser a menor parte do trabalho na história. Os pontos-chave estão nas coisas que a transformação não percebe: registros que parecem corretos, mas fazem referência a dados que não foram transferidos; registros que parecem corrompidos, mas na verdade estão corretos de uma forma que a especificação não captou; casos extremos que sobreviveram apenas porque o sistema antigo os tolerava e o novo não.

Esse é um problema diferente de uma migração de banco de dados. Uma migração de esquema altera a estrutura de um banco de dados com os dados já armazenados nele. Uma migração de dados transfere dados entre sistemas, e a questão não é “o comando ALTER será concluído a tempo?” — e sim “o que fazemos com as linhas que não correspondem a nenhum dos lados?” A maior parte do trabalho envolve reconciliação, estratégia de transição e reversão. O código de transformação é a parte que você escreve mais rápido e termina por último.

O que se fala na sala

Backend: “É um script. Ler, mapear, gravar. No máximo dois dias.”

Engenharia de dados: “Já verificamos o quanto a fonte está suja?”

SRE: “Qual será a estratégia de transição — ‘big bang’ ou ‘dual-write’?”

Líder: “Quem resolve os conflitos nas linhas que não são migradas corretamente?”

PM: “Quando vamos descontinuar o sistema antigo?”

A pergunta do PM é o que deve orientar a estimativa. Se o sistema antigo for descontinuado em um mês, você precisa de uma estratégia que atinja 100% de precisão; se ele continuar em uso junto com o novo por dois trimestres, você pode deixar a “cauda longa” para mais tarde. A estimativa não é sobre a transformação — é sobre a estratégia.

Perguntas que vale a pena fazer antes de votar

Qual é a qualidade dos dados de origem — limpos, sujos ou desconhecida?
Estratégia de migração: “big bang”, gravação dupla, leitura em cópia de segurança, gradual?
Por quanto tempo os dois sistemas coexistirão? Há uma data prevista para o fim da coexistência?
Quem está reconciliando as linhas que não são migradas corretamente, e qual é o limite?
Qual seria o plano de reversão caso o novo sistema recebesse dados incorretos após a migração?
Existem consumidores a jusante (relatórios, integrações) que precisam ser migrados simultaneamente?

Se a equipe votar em 5 e alguém perguntar “espera aí, e os registros do log de auditoria?”, você não teve um problema de estimativa; você teve duas histórias fingindo ser uma só. Divida: a transformação é um ticket, e a reconciliação e o plano de transição são outro.

Votem na estratégia, não na transformação. A transformação dura dois dias. A estratégia abrange o trimestre.

Consulte como estimar uma migração de banco de dados para a variante de mudança de esquema em um único sistema e os outros exemplos práticos de estimativa. Inicie uma sessão gratuita de planning poker assim que a estratégia de transição estiver esboçada.