# Migracao banco dados: checklist 9 etapas sem downtime

> O checklist de 9 etapas para migração de banco de dados sem downtime abrange planejamento, replicação síncrona, validação de consistência e rollback. O processo evita perda de dados e indisponibilidade ao executar migração incremental com failover controlado. A validação pós-migração garante integridade antes de desativar o banco original.

*PosUp · Apps e Software · 30 de julho de 2026 · Patrícia Lemos*

Migrar um banco de dados sem interromper as operações é um dos maiores desafios de infraestrutura. Este checklist de 9 etapas cobre desde o planejamento até a validação pós-migração, ajudando a evitar perda de dados e indisponibilidade.

## Checklist: 9 etapas para migrar banco de dados sem downtime

Migrar um banco de dados sem interromper o serviço é um dos processos mais delicados em infraestrutura. Uma falha pode causar perda de dados, inconsistências ou horas de indisponibilidade. Este checklist organiza as 9 etapas essenciais para uma migração segura, com foco em replicação contínua e validação de integridade.

Use este guia quando precisar trocar de servidor, mudar de provedor de nuvem, atualizar a versão do SGBD ou consolidar bancos, sempre que o uptime for crítico.

## Planejamento e mapeamento

### 1. Mapear dependências e fluxo de dados

Antes de mover um byte, identifique todos os sistemas, aplicações e jobs que consomem ou escrevem no banco de origem. Um diagrama simples de fluxo evita surpresas: uma fila de mensageria esquecida pode travar a migração. Liste também as tabelas mais críticas e o volume de transações por minuto.

### 2. Definir estratégia de replicação

Escolha entre replicação síncrona (dados idênticos em tempo real, mas com latência) ou assíncrona (menor impacto na origem, com atraso controlado). Para bancos relacionais, ferramentas nativas como MySQL Replication ou PostgreSQL Streaming Replication funcionam bem. Para NoSQL, verifique a compatibilidade do driver de replicação.

## Preparação do ambiente

### 3. Provisionar destino com mesma capacidade

O banco de destino deve ter pelo menos a mesma capacidade de CPU, memória e armazenamento que a origem. Dados compactados ou índices diferentes alteram o tamanho real, faça uma estimativa com base no dump de uma réplica de staging.

### 4. Configurar monitoramento e alertas

Antes de iniciar a replicação, ative métricas de latência de replicação, taxa de erro de conexão e uso de espaço em disco. Ferramentas como Prometheus + Grafana ou o próprio painel do SGBD permitem detectar desvios antes que virem incidentes.

## Execução da migração

### 5. Realizar migração incremental em staging

Nunca vá para produção sem testar. Monte um ambiente de staging idêntico ao de produção e execute a migração completa, incluindo réplica e validação. Meça o tempo necessário e documente cada comando executado, esse log será seu roteiro na produção.

### 6. Iniciar replicação contínua em produção

Com o ambiente preparado, configure a replicação do banco de origem para o destino. Monitore a latência: ela não deve ultrapassar alguns segundos. Durante essa fase, o banco de origem continua atendendo normalmente. Se a latência crescer, pause e investigue antes de prosseguir.

### 7. Validar consistência dos dados

Compare a contagem de registros, checksums ou hashes de tabelas críticas entre origem e destino. Ferramentas como pt-table-checksum (MySQL) ou queries de diff ajudam a garantir que nenhum registro foi perdido ou corrompido. Valide também índices, constraints e chaves estrangeiras.

## Cutover e pós-migração

### 8. Executar cutover com janela controlada

Mesmo com replicação contínua, o cutover (troca de tráfego) exige uma janela curta de manutenção, tipicamente de 1 a 5 minutos. Redirecione as aplicações para o novo banco, pare a replicação e confirme que todas as conexões estão ativas. Uma estratégia comum é usar um DNS TTL baixo ou um balanceador de carga.

### 9. Validar aplicações e manter rollback pronto

Após o cutover, execute testes funcionais nas principais rotas da aplicação. Monitore logs de erro e métricas de performance por pelo menos 24 horas. Mantenha o banco de origem operacional e a replicação reversa configurada, se algo falhar, você pode voltar em minutos.

## O erro mais comum

O erro mais frequente em migrações sem downtime é subestimar a validação de consistência. Equipes confiam na replicação cega e descobrem dados divergentes dias depois, quando o rollback já não é mais viável. Teste a integridade antes do cutover e mantenha um script de reversão testado. Dado sem verificação não é dado confiável.

## FAQ

### Qual a diferença entre migração síncrona e assíncrona?

Na migração síncrona, cada transação é confirmada em ambos os bancos antes de ser considerada concluída. A assíncrona confirma na origem e replica depois. A síncrona oferece consistência imediata, mas aumenta a latência; a assíncrona é mais rápida, mas pode perder dados se a origem falhar antes da replicação.

### Quanto tempo leva uma migração de banco de dados sem downtime?

O tempo varia conforme o volume de dados, a largura de banda de rede e a estratégia de replicação. Migrações incrementais com replicação contínua podem levar de algumas horas a dias. O cutover, porém, costuma durar menos de 5 minutos.

### Preciso pausar as aplicações durante a migração?

Durante a replicação inicial e a validação, as aplicações podem continuar operando normalmente. Apenas no momento do cutover, a troca de tráfego para o novo banco, é necessária uma pausa curta, geralmente de 1 a 5 minutos.

### Como garantir que nenhum dado foi perdido?

Compare checksums ou hashes de tabelas críticas entre origem e destino. Ferramentas como pt-table-checksum (MySQL) ou queries de diff ajudam a detectar divergências. Valide também índices, constraints e chaves estrangeiras.

### O que fazer se a replicação apresentar latência alta?

Pause a migração, investigue a causa, pode ser falta de recursos no destino, rede congestionada ou conflitos de chave, e corrija antes de prosseguir. Nunca force o cutover com latência alta.

### É possível reverter a migração depois do cutover?

Sim, desde que o banco de origem seja mantido operacional e a replicação reversa esteja configurada. O rollback segue o mesmo processo: replicar de volta e trocar o tráfego. Quanto mais tempo passa, maior o risco de divergências.

---

Fonte (canonical): https://posup.com.br/apps-e-software/migracao-banco-dados-checklist-9-etapas-sem-downtime/