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 (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 é geralmente a menor tarefa da história. Os pontos de dificuldade 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á contidos 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 “o que faremos 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 conclui 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á contaminada?”

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

Líder: “Quem resolve os problemas 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 desativado 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ê tinha 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 a seção sobre estimativa de migração de banco de dados para a variante de mudança de esquema em um único sistema, bem como 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.