Resgate da migração de ERP Oracle de 50 TB em saúde

Resumo executivo

Uma das maiores operadoras de saúde e seguros dos EUA precisava completar a migração de um ERP Oracle mission-critical após uma tentativa anterior, conduzida por outro fornecedor, ter falhado. O ambiente envolvia uma base Oracle de 50 TB sobre arquitetura enterprise: Exadata, RAC, Data Guard, criptografia TDE.

A Redgator entrou para definir e executar uma estratégia segura: replanejamento de risco, plano de cutover detalhado, modelo de rollback inferior a 1 hora, e coordenação técnica entre times de infraestrutura, banco, aplicação e validação. A migração foi concluída dentro da janela contratada, com auditoria Oracle aprovando o processo.

O desafio

A situação era crítica:

Uma tentativa de migração anterior havia falhado e deixado cicatrizes operacionais.
A plataforma ERP era essencial para a operação diária do negócio.
A janela total disponível era de 3 meses — fixa, sem espaço para deslize.
O volume de dados (50 TB) tornava cada estratégia técnica mais arriscada que o normal.
A regulação de saúde + seguros exigia conformidade rigorosa em criptografia e auditoria.
A janela de downtime tinha que ser absolutamente mínima.
O rollback precisava existir e ter sido ensaiado — não como teoria, mas como botão pronto.
Múltiplos times técnicos e de negócio precisavam coordenar testes e validação.

O projeto não era sobre mover dados. Era sobre proteger continuidade de negócio em um ambiente onde uma falha custaria milhões e abalaria reputação.

A abordagem

A Redgator estruturou o trabalho em torno de quatro princípios: redução de risco, validação contínua, ensaios reais antes do D-zero, e clareza absoluta de responsabilidades.

Fase 1 — Diagnóstico e revisão pós-falha

Análise técnica do que falhou na tentativa anterior — sem apontar dedos, mas com objetivo de não repetir o erro. Mapeamento de dependências, jobs, integrações, regras de criptografia, baseline de performance.

Fase 2 — Estratégia de replicação dual

Combinação de Data Guard (para HA) + GoldenGate (para sincronismo durante coexistência) em arquitetura RAC sobre Exadata. Cada caminho de replicação foi documentado com pré-checks, validação, rollback.

Fase 3 — Ensaios em ambiente espelho

Migração foi ensaiada duas vezes em ambiente mirror — uma em escala parcial (15% do volume) e uma em escala completa com tráfego sintético. Cada ensaio gerou postmortem, ajuste de runbook, e nova rodada.

Fase 4 — Cutover e Go/No-Go

D-zero com janela acordada. Time de Redgator + cliente em call de 14 horas. Decisão Go/No-Go formal aos 8h, com critérios objetivos: integridade, performance, throughput. Rollback ensaiado e pronto para acionar até 1h após cutover.

Decisões técnicas-chave

Replicação → Data Guard + GoldenGate combinados

Data Guard sozinho não cobre cenários de coexistência prolongada. GoldenGate sozinho tem overhead. Combinação permite failover instantâneo (DG) + sincronismo bidirecional opcional (GG).

Criptografia → TDE + Native Network Encryption

TDE em repouso preservada na migração (chaves transferidas com cuidado). NNE em trânsito para o caminho de replicação. Auditoria Oracle revisou ambas as configurações.

Janela → cutover em 14h com fallback fail-safe

Decisão consciente de privilegiar segurança sobre velocidade. Janela de 14h dá margem para validação real + rollback se necessário. Rollback projetado < 1h porque o GoldenGate manteve sincronismo reverso durante a janela.

Test plan → ensaios duplos antes do D-zero

Um ensaio = palpite. Dois ensaios em ambiente mirror = método. Cada ensaio identificou problemas que teriam sido catastróficos em produção (jobs órfãos, DB links esquecidos, particionamento desalinhado).

Métricas

Indicador	Antes	Depois	Como medimos
Tempo de cutover	Estimativa anterior: 24h+	14h reais	Cronometrado em janela controlada
Perda de transações	N/A (anterior falhou)	0	Reconciliação linha-a-linha
Disponibilidade pós-cutover	—	99.97% (primeiro mês)	Monitoração contínua
Rollback testado	Não	Sim, < 1h	Ensaiado em mirror, pronto em produção

Tecnologias e práticas

Oracle Database (versões enterprise, multi-tenant)
Oracle RAC — alta disponibilidade na origem e destino
Exadata — origem com Smart Scan + Storage Indexes; planejamento cuidadoso para preservar características
Data Guard — replicação síncrona/assíncrona configurada por workload
GoldenGate — replicação heterogênea, bidirecional opcional durante coexistência
TDE — criptografia em repouso; gestão segura de chaves durante a migração
Native Network Encryption — criptografia do tráfego de replicação
Práticas: runbook parametrizado, postmortem blameless, Go/No-Go formal, validação cruzada linha-a-linha

O que funcionou bem

Ensaios duplos antes do D-zero — método caro mas que pagou por si só. Dois problemas detectados em ensaio teriam sido catastróficos em produção.
Rollback < 1h ensaiado — não foi marketing. Foi botão real, com switch verificado. Cliente não precisou, mas saber que existia mudou a postura na call de cutover.
Comunicação assíncrona com cliente — daily 15-min sync + runbook compartilhado no GitHub privado. Time do cliente nunca ficou no escuro.
Auditoria Oracle aprovou o processo — não era requisito mandatório, mas validou metodologia.

Próximos passos

Após o handover de 30 dias em plantão silencioso, o cliente engajou Redgator para um segundo projeto de modernização sobre o mesmo ambiente. Migração serviu como base para a relação contínua, não como ponto final.

Executive summary

A leading US healthcare and insurance enterprise needed to complete a mission-critical Oracle ERP migration after a previous attempt, conducted by another vendor, had failed. The environment involved a 50 TB Oracle database on enterprise-grade architecture: Exadata, RAC, Data Guard, TDE encryption.

Redgator stepped in to define and execute a safe strategy: risk-based replanning, detailed cutover plan, sub-1-hour rollback model, and technical coordination across infrastructure, database, application, and validation teams. The migration was completed within the contracted window, with Oracle audit approving the process.

The challenge

The situation was critical:

A previous migration attempt had failed and left operational scars.
The ERP platform was essential to daily business operations.
The total window available was 3 months — fixed, with no room for slippage.
The data volume (50 TB) made every technical strategy riskier than usual.
Healthcare + insurance regulation demanded strict compliance on encryption and audit.
Downtime window had to be absolutely minimal.
Rollback had to exist and have been rehearsed — not as theory, but as a ready button.
Multiple technical and business teams had to coordinate testing and validation.

The project wasn’t about moving data. It was about protecting business continuity in an environment where a failure would cost millions and shake reputation.

The approach

Redgator structured the work around four principles: risk reduction, continuous validation, real rehearsals before D-day, and absolute clarity of responsibilities.

Phase 1 — Diagnosis and post-failure review

Technical analysis of what failed in the previous attempt — without finger-pointing, but with the goal of not repeating the mistake. Mapping of dependencies, jobs, integrations, encryption rules, performance baseline.

Phase 2 — Dual replication strategy

Combination of Data Guard (for HA) + GoldenGate (for sync during coexistence) on RAC architecture over Exadata. Each replication path was documented with pre-checks, validation, rollback.

Phase 3 — Rehearsals in mirror environment

Migration was rehearsed twice in a mirror environment — once at partial scale (15% volume) and once at full scale with synthetic traffic. Each rehearsal produced a postmortem, runbook tweak, and new round.

Phase 4 — Cutover and Go/No-Go

D-day with agreed window. Redgator team + client in a 14-hour call. Formal Go/No-Go decision at the 8-hour mark, with objective criteria: integrity, performance, throughput. Rollback rehearsed and ready to trigger up to 1 hour after cutover.

Key technical decisions

Replication → Data Guard + GoldenGate combined

Data Guard alone doesn’t cover prolonged coexistence scenarios. GoldenGate alone has overhead. The combination enables instant failover (DG) + optional bidirectional sync (GG).

Encryption → TDE + Native Network Encryption

TDE at rest preserved in the migration (keys transferred carefully). NNE in transit for the replication path. Oracle audit reviewed both configurations.

Window → 14h cutover with fail-safe fallback

Conscious choice to favor safety over speed. A 14h window gives room for real validation + rollback if needed. Rollback designed at < 1h because GoldenGate kept reverse sync during the window.

Test plan → double rehearsals before D-day

One rehearsal = a guess. Two rehearsals in a mirror environment = a method. Each rehearsal identified problems that would have been catastrophic in production (orphaned jobs, forgotten DB links, misaligned partitioning).

Metrics

Indicator	Before	After	How we measured
Cutover time	Prior estimate: 24h+	14h actual	Timed in controlled window
Transaction loss	N/A (prior attempt failed)	0	Row-by-row reconciliation
Post-cutover availability	—	99.97% (first month)	Continuous monitoring
Rollback tested	No	Yes, < 1h	Rehearsed in mirror, ready in production

Technologies and practices

Oracle Database (enterprise editions, multi-tenant)
Oracle RAC — high availability at source and destination
Exadata — source with Smart Scan + Storage Indexes; careful planning to preserve characteristics
Data Guard — synchronous/asynchronous replication configured per workload
GoldenGate — heterogeneous replication, optionally bidirectional during coexistence
TDE — encryption at rest; secure key management during migration
Native Network Encryption — encryption of replication traffic
Practices: parameterized runbook, blameless postmortem, formal Go/No-Go, row-by-row cross-validation

What worked well

Double rehearsals before D-day — an expensive method that paid for itself. Two issues detected in rehearsal would have been catastrophic in production.
Rehearsed < 1h rollback — wasn’t marketing. It was a real button, with verified switch. The client didn’t need it, but knowing it existed changed posture on the cutover call.
Async client communication — daily 15-min sync + runbook shared in private GitHub. The client team never stayed in the dark.
Oracle audit approved the process — not a mandatory requirement, but validated the methodology.

Next steps

After the 30-day silent-on-call handover, the client engaged Redgator for a second modernization project on the same environment. The migration served as the foundation for the ongoing relationship, not as the endpoint.