O que são migrações temporárias e quando realmente fazem sentido
Migrações temporárias são transferências de dados ou infraestrutura que não se destinam a ser permanentes. Você move algo de um ambiente para outro, faz o que precisa fazer, e depois devolve ou descarta. A diferença entre isso e uma migração normal é só o prazo de validade. No dia a dia, eu vejo muito gente confundir os dois conceitos. Acontece que um esquema feito para ser provisório vira permanente quando o prazo passa e ninguém lembra de limpar. Isso gera dívida técnica silenciosa que demora meses para aparecer. O problema mais comum que eu encontrei foi justamente esse: uma migração temporária de banco de dados entre duas instâncias no AWS RDS que deveria durar 48 horas. O processo principal funcionou, mas o rollback nunca foi executado porque a equipe partiu pra outra coisa. A instância antiga ficou rodando por seis meses consumindo recursos sem ninguém usar. Eu descobri apenas porque o relatório de custos do mês seguinte mostrou uma linha nova que não fazia sentido.
A solução que eu adotei foi simples. Comecei a colocar uma tag obrigatória em todo recurso envolvido em migração temporária, com um campo expiry_date formatado como data ISO. Depois criei um lambda que roda todo dia às 8h e mata qualquer resource com expiry_date menor que hoje. Isso reduziu o tempo gasto gerenciando esses recursos de algo em torno de 3 horas por semana para zero. O custo extra do lambda é irrisório.
Planejamento de migrações temporarias
O planejamento começa antes de qualquer comando ser escrito. Você precisa definir três coisas com clareza: qual é o ciclo de vida esperado, qual é a política de rollback, e quem é responsável por extinguir a migração quando o prazo acabar. Se alguma dessas respostas for "dependendo", o projeto vai estourar. Na prática, eu costumo montar um checklist de dez itens que cobre desde a definição do scope até a validação pós-migração. Os itens mais negligenciados são o ponto de restauração e a cópia de segurança do estado original. Sem backup do ponto de partida, você não tem como reverter se algo der errado, e aí a migração temporária vira permanente por falta de opção.
Um detalhe técnico que poucas pessoas levam em conta: a janela de replicação. Se você está migrando tabelas com muitos writes concorrentes, a replicação pode levar horas para alcançar o estado final. Eu já vi uma migração ser marcada como concluída com base em uma contagem de registros, mas os dados estavam desatualizados porque o changelog ainda estava sendo processado. O diagnóstico foi descobrir que o lag de replicação estava em torno de 45 minutos no pico de operação. A correção foi implementar uma verificação de lag antes de fechar a migração, não apenas uma contagem de linhas.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Execução passo a passo
A execução segue uma sequência básica, mas os detalhes importam mais do que o esqueleto. Primeiro, você faz backup do estado atual. Segundo, configura o ambiente de destino com as mesmas versões de software e configurações de compatibilidade. Terceiro, realiza a transferência dos dados. Quarto, valida a integridade. Quinto, redireciona o tráfego ou a aplicação. Sexto, mantém o estado original ativo durante um período de observação. O passo cinco é onde a maioria dos erros acontece. Direcionar o tráfego antes de validar a integridade parece lógico em teoria, mas na prática você está depositando confiança em algo que ainda não foi testado sob carga real. Eu recomendo manter ambos os ambientes funcionando em paralelo por pelo menos um ciclo completo de trabalho. No mínimo, espere até que a próxima janela de backup do ambiente novo seja concluída com sucesso. Isso garante que a replicação inversa funciona se você precisar reverter.
Uma coisa contraintuitiva que eu aprendi: às vezes é mais rápido migração temporária usando uma ferramenta diferente da que você usaria para uma migração permanente. Ferramentas como AWS Database Migration Service ou scripts customizados baseados em CDC (Change Data Capture) podem ser mais adequados para cenários temporários porque oferecem rollback embutido e monitoramento em tempo real. Para migrações permanentes, eu prefiro abordagens mais tradicionais porque o controle é mais fino. A escolha errada da ferramenta pode aumentar o tempo de migração temporaria em até 40% dependendo do volume de dados.
Quando não usar migrações temporárias
Nem todo movimento de dados precisa ser temporário. Se você está migrando regularmente, todos os meses ou mais frequente, o esforço de setup e teardown acaba pesando mais do que simplesmente fazer a migração definitiva. Migrações temporárias custam em torno de 15 a 20% a mais do que migrações permanentes equivalentes quando consideradas todas as operações de rollback e limpeza. O ganho real está nos cenários onde a necessidade é genuinamente pontual: teste de performance, validação de novo esquema, preparação para uma atualização maior que ainda não está pronta. Outro caso onde migrações temporárias falham é quando o volume de dados é muito grande e o tempo disponível é muito curto. Migrar 2 terabytes em uma janela de 4 horas com Validção completa é inviável na maioria das configurações comuns. Nesses casos, uma migração permanente com plano de contingência é mais segura. O downtime é esperado e planejado, ao invés de ser uma consequência de pressa.
Se você tiver dúvida sobre qual abordagem escolher, comece pelo cronograma. Se a migração precisa existir por menos de duas semanas, temporal faz sentido. Se vai existir por mais de três meses, talvez seja melhor tratar como permanente desde o início. A fronteira entre os dois não é rígida, mas a experiência mostra que passar de um mês já indica que a temporary migration está esticando demais o resource que deveria ser descartável.
