Checklist de preparacao antes de migrar sistema em producao

Migrar um sistema em produção sem preparo é receita para downtime, perda de dados e noites sem dormir. Antes de migrar sistema em producao, verifique: (1) backup completo e testado do estado atual, (2) ambiente staging idêntico ao de produção, (3) script de rollback validado, (4) checklist de impacto em dependências, (5) janela de downtime aprovada e comunicada. Pule um desses e a migração vira incidente.

Pré-requisitos de infraestrutura

Ambiente staging espelhado. O staging precisa replicar produção em hardware, versões de SO, middleware e carga de dados. Diferenças geram falsos positivos nos testes.

Janela de downtime definida e comunicada. Sem acordo de janela, stakeholders podem depender do sistema no meio da migração. Documente horário, duração estimada e impacto esperado.

Acesso root/admin validado. Verifique se as credenciais de acesso aos servidores, bancos e serviços estão ativas e com permissões corretas. Nada trava mais que um "permission denied" na hora do deploy.

Dados e estado do sistema

Backup completo e testado. Não basta gerar o dump. Restaure-o em um ambiente isolado e confira a integridade. Um backup corrompido não serve para rollback.

Snapshot do banco de dados. Antes de qualquer alteração estrutural, tire um snapshot do banco. Permite voltar ao estado exato pré-migração, sem depender de restore completo.

Lista de dependências externas. APIs de terceiros, webhooks, filas de mensageria, cada dependência precisa ser testada no staging com a versão nova do sistema. Uma API que mudou o contrato quebra a migração.

Plano de rollback e contingência

Script de rollback testado. Escreva o script que desfaz cada alteração, migração de schema, troca de versão, alteração de configuração. Teste-o no staging antes de ir para produção.

Critério de aborto definido. Estabeleça um gatilho objetivo: se após X minutos o sistema não responder, ou se o erro Y aparecer, aborta e executa rollback. Decisão emocional na hora do stress é receita para desastre.

Comunicação de contingência. Tenha um canal (Slack, Teams, telefone) para notificar times impactados se o rollback for acionado. Ninguém deve descobrir pelo monitoramento.

O erro mais comum ao migrar sistema em producao é confiar que "deu certo no staging, vai dar certo em produção". Diferenças de carga, concorrência e dados reais sempre aparecem. O checklist não elimina riscos, mas transforma imprevisto em procedimento.

FAQ

Qual a diferença entre backup e snapshot?

Backup é uma cópia completa do banco ou sistema, geralmente armazenada em outro local. Snapshot é uma imagem do estado atual do disco ou banco em um instante, mais rápida de gerar e restaurar, mas dependente do mesmo storage.

Quanto tempo antes devo testar o rollback?

Teste o rollback pelo menos 48 horas antes da janela de migração. Se encontrar falhas, dá tempo de corrigir e testar novamente. Testar na véspera é jogar contra o relógio.

Preciso migrar em horário comercial?

Não. Migrações devem ocorrer na janela de menor uso, geralmente madrugada ou finais de semana. Horário comercial aumenta o impacto de downtime e a chance de usuários ativos corromperem dados.

O que fazer se a migração exceder a janela?

Execute o rollback imediatamente. Estender a janela sem aviso gera desconfiança e pode afetar operações críticas. Remarque a migração para a próxima janela com as lições aprendidas.

Como garantir que o staging é idêntico à produção?

Use infraestrutura como código (Terraform, Ansible) para provisionar ambos ambientes. Compare variáveis de ambiente, versões de dependências e volume de dados. Um staging com 10% dos dados não testa performance real.