429 migrações. Cada uma com runbook próprio.
A migração de banco é onde a gente se especializou. Não é commodity. Cada engine tem armadilhas próprias, cada workload tem peculiaridade fiscal/regulatória, cada cliente tem janela diferente. O que se repete é o método.
PL/SQL convertido para PL/pgSQL. Packages, sequences, hierarchical queries reescritas linha-a-linha.
RDS for Oracle, Aurora PostgreSQL ou ambos. Licença, custo total, plano de retirada do legado.
O caso difícil. Smart Scan, HCC, particionamento agressivo. Reescrita de plano antes do cutover.
Quando a regulação exige on-prem. Oracle on AIX em arquitetura RAC, com tuning específico de I/O.
PL/SQL para T-SQL, ajuste de tipos, conversão de hints, reconciliação contínua durante a janela.
Conversa em 45 min com DBA sênior.
- 01
Conversão de schema & código
PL/SQL → PL/pgSQL, T-SQL → PL/pgSQL, packages, triggers, sequences, hierarchical queries. Ora2Pg + AWS SCT + revisão linha-a-linha. O que não converte automático, a gente reescreve.
- 02
Cargas iniciais & sincronismo contínuo
Carga full + CDC durante semanas para fechar o delta. Cutover de 30 min em janela de baixa, com fallback ensaiado duas vezes antes.
- 03
Validação cruzada
Reconciliação linha a linha pós-cutover. Em uma migração de 4,2M linhas, divergência tem que ser zero antes de declarar sucesso.
- 04
Tuning pós-migração
Plan que rodava bem em Oracle quase nunca roda igual em PostgreSQL. Reescrita de queries críticas, índices funcionais, particionamento. +27% performance média porque a migração inclui essa fase — não termina no cutover.
- 05
Coexistência prolongada
Quando o legado não pode morrer no D-zero. Réplica bidirecional, roteamento por feature flag, descomissionamento gradual.
Não é metodologia em PDF. É código.
Em 25 anos a gente acumulou um framework próprio de migração — runbooks parametrizáveis, scripts de reconciliação, harness de testes, checklist de pré/pós-cutover. Não é segredo industrial: a gente entrega tudo para o cliente. Mas é o que faz a 400ª migração ser tão sólida quanto a 1ª foi cuidadosa.
- F·01
Discovery automatizado
Inventário de objetos, dependências, jobs, DB links, sequences. Em 4h tem mapa que normalmente leva 2 semanas para alguém escrever no Excel.
- F·02
Runbook parametrizado
YAML que descreve cada onda. Pre-checks, execução, validação, rollback. Mesma estrutura para qualquer engine. Versionado, revisado por PR.
- F·03
Harness de testes estruturados
Sintético + amostragem + reconciliação. Roda em ambiente mirror antes do D-zero. Falha quebra o pipeline — não vira "warning aceitável".
- F·04
Análise de histórico
AWR, Statspack, pg_stat_statements, query store. Cruzamos 30 dias de carga real com o catálogo de objetos para priorizar tuning antes do cutover, não depois.
- F·05
Fallback ensaiado
Roll-forward é fácil. Voltar é o que separa migração séria de bravata. Cada onda tem fallback rodado em ambiente mirror na sexta antes.
- F·06
Postmortem obrigatório
Mesmo sem incidente. Em 5 dias úteis. Vai pro framework: o que aprendemos vira checklist da próxima.
Plataforma própria, construída por quem opera.
gator.red é a plataforma que a gente queria ter quando começou. Inventário vivo de bancos, observabilidade específica para DB, automação das tarefas DBA recorrentes, plantão integrado e — o módulo que mais usamos — o motor de migração com o framework empacotado.
Inventário vivo
Catálogo dos bancos da casa. Versão, patch, owner, contratos, janelas, dependências. Atualiza sozinho — não fica desatualizado em 6 meses.
Observabilidade DB-first
Métricas que importam para DBA: top queries, lock waits, replication lag, fragmentação. Dashboards que o time olha, não que existem para auditoria.
Automação de tarefas
Refresh de homolog, mascaramento, criação de réplica, rotação de credencial, patch coordenado. Self-service para o time do cliente.
Motor de migração
O framework empacotado. Discovery, runbook, harness, reconciliação, fallback. A 429ª migração rodou aqui dentro.
Plantão integrado
Alerta chega no engenheiro com contexto: histórico do banco, runbook do incidente parecido, último postmortem relacionado. Sem abrir 5 abas.
Análise de histórico
30, 60, 180 dias de carga real cruzada com catálogo. Gera priorização de tuning, alerta sobre query que mudou comportamento, sugere índice antes do problema.
Antes do cutover. Depois também.
A diferença entre uma migração tranquila e um sábado de madrugada perdido é teste estruturado. A gente trata banco como sistema de software: tem fixture, tem sintético, tem benchmark, tem regressão.
- 01
Análise de histórico de carga
AWR/Statspack/pg_stat_statements consolidados. Top 50 queries por tempo, por I/O, por execuções. Sabe-se o que dói antes de mexer.
- 02
Workload sintético
Reprodução fiel da carga real em ambiente mirror. Não é sysbench genérico — é o seu workload, na sua proporção.
- 03
Benchmark comparativo
Antes vs. depois, query a query. Latência p50/p95/p99, throughput, contention. Se piorou, fica claro onde e por quê.
- 04
Reconciliação de dados
Hash de partição, count cruzado, amostragem por chave. Em migração regulada (BACEN, BCB, ANS) vai para o auditor.
- 05
Regressão automatizada
Suite que roda em CI a cada release. Migração não é evento único — é cama elástica.
Tem banco difícil para migrar, sincronizar ou converter? Conta o problema.
45 min com um DBA sênior. Sem pitch.