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 os pontos.

Uma migração de dados (transferência de 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 tarefa da 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 da 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. A migração de dados transfere dados entre sistemas, e a questão não é “o comando ALTER será concluído a tempo?”, mas sim “o que faremos com as linhas que não correspondem a nenhum dos lados?”. A maior parte do trabalho consiste em 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 conclui por último.

O que é dito 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 permanecer 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 sombra, 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 procedimento 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-as: 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.