Migrações
Complexas.
Complex
Migrations.
A migração que ninguém quer encarar: AIX→Linux, Oracle→PostgreSQL, Exadata→cloud, SQL Server→PostgreSQL, mainframe→microsserviços. Por ondas, com runbook e fallback ensaiado — não big bang num fim de semana. Começa com assessment de risco; termina com corte sem surpresa e um plano de volta que ninguém precisou usar.
The migration nobody wants to face: AIX→Linux, Oracle→PostgreSQL, Exadata→cloud, SQL Server→PostgreSQL, mainframe→microservices. In waves, with a runbook and a rehearsed fallback — not a big bang over one weekend. It starts with a risk assessment; it ends with a no-surprise cutover and a rollback plan nobody needed to use.
Antes de mover, medir. O risco real, não o do slide.
Migração que falha quase nunca falha por falta de ferramenta — falha por surpresa. Dependência não mapeada, job batch esquecido, integração que ninguém documentou. O assessment levanta o estate real (AWR para carga, inventário para dependência) e transforma incerteza em matriz de risco: o que move fácil, o que precisa de ensaio, o que melhor não tocar agora.
- A·01
Discovery do estate real
Inventário vivo de instâncias, schemas, jobs, integrações e dependências externas. O que está em produção — não o que o diagrama de 2019 diz.
- A·02
Perfil de carga com AWR
AWR e métrica de produção para entender o workload de verdade: pico, P95, janelas de batch. Sizing no destino sai de dado, não de catálogo do fornecedor.
- A·03
Matriz de risco priorizada
Cada componente classificado por esforço e risco. O assessment entrega ondas candidatas, não um "vai dar certo". É o mesmo método dos nossos cases de readiness e discovery.
- A·04
Prova de conceito no que assusta
O ponto mais arriscado vira POC antes do cronograma fechar. Endianness, charset, feature proprietária sem equivalente — descobertos no laboratório, não no corte.
Ondas, não fim de semana herói.
Big bang num fim de semana é a forma mais cara de migrar: todo o risco concentrado numa janela, sem espaço para falhar e corrigir. Aqui a migração é fatiada em ondas — pela dependência, não pela conveniência do calendário. Cada onda tem critério de entrada e saída, ensaio e plano de volta. A primeira onda existe para a gente errar barato.
- E·01
Strangler fig, não substituição total
O sistema novo cresce ao lado do velho, capturando função por função. O legado morre por inanição, sem o salto de fé de desligar tudo de uma vez.
- E·02
Onda piloto de baixo risco
A primeira onda é escolhida para validar o processo com dano mínimo. Aprende-se o runbook real ali — antes de tocar no core.
- E·03
Replicação para corte curto
GoldenGate, Data Guard ou DMS mantêm origem e destino em sincronia. A janela de corte cai de fim de semana para minutos, porque o dado já está lá.
- E·04
Critério de entrada e saída por onda
Cada onda só começa com pré-requisito atendido e só fecha com validação passada. Sem "depois a gente arruma" empurrado para a próxima.
AIX→Linux. Oracle→PostgreSQL. Sem perder o sono.
As migrações difíceis são as que trocam de plataforma ou de banco — onde endianness, charset e SQL proprietário viram armadilha. AIX para Linux com Oracle RAC e Data Guard; Oracle para PostgreSQL com Ora2Pg e reescrita de PL/SQL; Exadata para cloud sem perder o que o Smart Scan dava. Cada uma com ensaio de dados e validação de paridade.
- C·01
AIX → Linux com baixa parada
Cross-platform com cuidado de endianness, Data Guard para sincronizar e RAT para validar a carga no destino antes do corte. É o método dos nossos cases de Exadata e estate de 100 TB+.
- C·02
Oracle → PostgreSQL de verdade
Ora2Pg para schema e dado, reescrita honesta de PL/SQL e de SQL proprietário, teste de paridade funcional. Sem fingir que "é só trocar a string de conexão".
- C·03
Exadata → cloud sem ilusão
Mapeamento do que o Exadata entregava (Smart Scan, IORM) para o equivalente em cloud — ou compensação explícita onde não há. Decisão com número, não marketing.
- C·04
Validação de dados em camadas
Contagem, checksum e reconciliação de negócio. Migrou não é "o job rodou" — é o dado batendo com a origem, conferido.
Plano de volta ensaiado. Que ninguém precisou usar.
O corte é o momento de menos improviso de todo o projeto. Runbook minuto a minuto, papéis definidos, ponto de não-retorno declarado e — acima de tudo — fallback ensaiado em staging antes do dia. Fallback que nunca foi testado não existe. Plantão sênior durante toda a janela, com o engenheiro que construiu a onda, não um número de chamado.
- F·01
Runbook de corte minuto a minuto
Cada passo com responsável, tempo esperado e verificação. Ensaiado em staging até o tempo de janela ser previsível, não esperançoso.
- F·02
Ponto de não-retorno explícito
Definido antes do corte: até aqui, fallback; depois daqui, segue. Sem decisão emocional às 3h com a janela acabando.
- F·03
Fallback ensaiado, não documentado
O plano de volta roda em staging antes do dia. Reverter é decisão de operação, não fracasso — e por isso é rápido e sem pânico.
- F·04
Hypercare e saída
Janela de acompanhamento intensivo pós-corte, depois handover com runbook na wiki do cliente. A migração termina com o time do cliente operando sozinho.
Mover sem modernizar é só mudar o problema de lugar.
- NÃO
Lift-and-shift puro sem ganho
Levar a dívida intacta para a cloud sai caro e não resolve nada. Se é só isso que precisa, um terceirão faz por metade do preço.
- NÃO
Big bang sem ensaio de fallback
Cortar tudo num fim de semana sem plano de volta testado é apostar o negócio numa janela. Não fazemos.
- NÃO
Cronograma fechado antes do assessment
Prometer data sem medir o estate é vender ficção. Primeiro o risco real, depois o cronograma.
Before you move, measure. The real risk, not the slide one.
A migration that fails almost never fails for lack of a tool — it fails by surprise. An unmapped dependency, a forgotten batch job, an integration nobody documented. The assessment surveys the real estate (AWR for load, an inventory for dependencies) and turns uncertainty into a risk matrix: what moves easily, what needs a rehearsal, what is better left untouched for now.
- A·01
Discovery of the real estate
A live inventory of instances, schemas, jobs, integrations, and external dependencies. What is in production — not what the 2019 diagram claims.
- A·02
Load profile with AWR
AWR and production metrics to understand the real workload: peak, P95, batch windows. Sizing at the destination comes from data, not from the vendor catalog.
- A·03
Prioritized risk matrix
Each component classified by effort and risk. The assessment delivers candidate waves, not a "it will be fine". It is the same method as our readiness and discovery cases.
- A·04
A proof of concept for what scares us
The riskiest point becomes a POC before the schedule is set. Endianness, charset, a proprietary feature with no equivalent — found in the lab, not at cutover.
Waves, not a hero weekend.
A big bang over one weekend is the most expensive way to migrate: all the risk concentrated in a single window, with no room to fail and fix. Here the migration is sliced into waves — by dependency, not by calendar convenience. Each wave has entry and exit criteria, a rehearsal, and a rollback plan. The first wave exists so we can fail cheaply.
- E·01
Strangler fig, not full replacement
The new system grows next to the old one, capturing function by function. The legacy dies of starvation, with no leap of faith of switching everything off at once.
- E·02
A low-risk pilot wave
The first wave is chosen to validate the process with minimal damage. The real runbook is learned there — before touching the core.
- E·03
Replication for a short cutover
GoldenGate, Data Guard, or DMS keep source and target in sync. The cutover window drops from a weekend to minutes, because the data is already there.
- E·04
Entry and exit criteria per wave
A wave starts only with prerequisites met and closes only with validation passed. No "we will fix it later" pushed to the next one.
AIX→Linux. Oracle→PostgreSQL. Without losing sleep.
The hard migrations are the ones that switch platform or database — where endianness, charset, and proprietary SQL become traps. AIX to Linux with Oracle RAC and Data Guard; Oracle to PostgreSQL with Ora2Pg and PL/SQL rewriting; Exadata to cloud without losing what Smart Scan gave you. Each one with a data rehearsal and a parity validation.
- C·01
AIX → Linux with low downtime
Cross-platform with care for endianness, Data Guard to sync, and RAT to validate the load at the destination before cutover. It is the method from our Exadata and 100 TB+ estate cases.
- C·02
Oracle → PostgreSQL for real
Ora2Pg for schema and data, an honest rewrite of PL/SQL and proprietary SQL, a functional parity test. No pretending it is "just swapping the connection string".
- C·03
Exadata → cloud with no illusion
Mapping what Exadata delivered (Smart Scan, IORM) to the cloud equivalent — or an explicit compensation where there is none. A decision with a number, not marketing.
- C·04
Layered data validation
Count, checksum, and business reconciliation. Migrated is not "the job ran" — it is the data matching the source, verified.
A rehearsed rollback plan. That nobody needed to use.
The cutover is the least improvised moment of the whole project. A minute-by-minute runbook, defined roles, a declared point of no return, and — above all — a fallback rehearsed in staging before the day. A fallback that was never tested does not exist. Senior on-call throughout the window, with the engineer who built the wave — not a ticket number.
- F·01
Minute-by-minute cutover runbook
Each step with an owner, an expected time, and a check. Rehearsed in staging until the window time is predictable, not hopeful.
- F·02
Explicit point of no return
Defined before the cutover: up to here, fallback; past here, proceed. No emotional decision at 3 a.m. with the window running out.
- F·03
Fallback rehearsed, not documented
The rollback plan runs in staging before the day. Reverting is an operational decision, not a failure — and that is why it is fast and calm.
- F·04
Hypercare and exit
An intensive watch window after cutover, then handover with the runbook in the client wiki. The migration ends with the client team operating on its own.
Moving without modernizing just relocates the problem.
- NO
Pure lift-and-shift with no gain
Carrying the debt intact to the cloud is expensive and solves nothing. If that is all you need, a commodity shop does it for half the price.
- NO
Big bang with no fallback rehearsal
Cutting everything over one weekend with no tested rollback plan is betting the business on a single window. We do not do it.
- NO
A fixed schedule before the assessment
Promising a date without measuring the estate is selling fiction. The real risk first, the schedule second.
Tem uma migração que ninguém quer assumir? Conta o problema.
45 min com um arquiteto de migração. Sem pitch.
Got a migration nobody wants to own? Tell us the problem.
45 min with a migration architect. No pitch.