Se você chegou até este post é porque provavelmente está avaliando — ou está no meio de — uma migração Oracle para OCI. Talvez o contrato com o datacenter vence no ano que vem. Talvez o CFO apertou sobre o custo do suporte Oracle. Talvez alguém da liderança leu que OCI ficou mais barato e quer entender.
Não vamos te vender a migração. Vamos contar o que acontece quando ela realmente é feita, baseado em cinco projetos que rodamos entre 2023 e 2025 — de bancos a operadoras de saúde, de e-commerces a governo.
1. O business case não é onde você pensa
A conversa começa sempre pelo licenciamento. E sim, rodar Oracle em OCI traz BYOL com economia real — tipicamente 20 a 30% no custo total de database-as-a-service comparado a AWS RDS Oracle ou Azure Database for Oracle.
Mas em todos os 5 projetos, o ganho maior não veio do database. Veio de:
- Desligar hardware antigo. Clusters RAC rodando em servidores de 2016-2018 custam caro em manutenção, energia e licenças de VMware. Sair disso era mais urgente do que qualquer otimização de query.
- Reduzir equipe de DBA on-call. Backup automatizado, patching gerenciado e HA nativo cortaram a pressão do time em ~40%.
- Consolidar ambientes. Um cliente tinha 7 ambientes Oracle (dev, qa, staging, hml, prod, dr, sandbox). Em OCI, passamos para 3 com pluggable databases compartilhando recursos.
A planilha que convence o CFO não é “RDS vs OCI”. É “hardware + licença + DBA + downtime + custo de oportunidade” versus “Exadata Cloud com autoscale”.
2. Exadata Cloud é overkill para 80% dos casos
Oracle vende Exadata como “a única forma decente de rodar Oracle na nuvem”. Não é.
Nos nossos 5 projetos:
- 2 usaram Exadata Cloud Service (ambos com workloads OLTP > 10K TPS e datasets > 10 TB)
- 2 usaram Base Database Service em shape standard (workloads típicos de ERP e CRM)
- 1 usou Autonomous Database (ambiente analítico, migrado de um data warehouse on-prem)
A diferença de custo entre Exadata e Base Database é tipicamente 4x a 8x. Se a sua carga não tem características que justificam Exadata (smart scan, storage offloading, IORM), você está pagando para ter um monstro que ninguém alimenta.
Pergunta-chave para decidir:
“Minha query mais lenta tira proveito de smart scan? Consigo benchmark antes/depois com traces?”
Se não tem resposta clara, não é Exadata.
3. Downtime zero é história bonita, não padrão
Todo vendor cloud pinta migração sem downtime como default. Na prática:
| Estratégia | Downtime típico | Complexidade | Custo |
|---|---|---|---|
| Export / Import (data pump) | 4-24h | Baixa | Baixo |
| RMAN backup + restore | 2-8h | Média | Baixo |
| GoldenGate replication | < 5 min | Alta | Alto |
| Zero Downtime Migration (ZDM) | < 5 min | Alta | Médio |
| Data Guard cross-cloud | < 1 min | Muito alta | Alto |
Em 4 dos 5 projetos, o cliente aceitou uma janela de 2-4 horas porque o trade-off de complexidade do GoldenGate não valia a pena. Só o banco, onde cada minuto custa muito, optou por ZDM.
Regra simples: se o cliente não tem time dedicado que já operou GoldenGate antes, não vende GoldenGate. Use o tempo de janela e faça um RMAN bem feito.
4. Os dois erros que todo mundo comete
Erro #1: Migrar com as mesmas shapes da VM antiga
A tentação é pegar o top do servidor on-prem, ver “64 cores, 512 GB RAM” e provisionar o mesmo em OCI. Você acabou de duplicar o custo.
Servidores on-prem têm:
- Overprovisioning deliberado (planejou para 5 anos)
- VMs compartilhando hardware com software antigo que consome baseline
- Peak loads raros que ninguém audita
Em OCI, você paga por shape 24/7. Faça CPU profiling durante 2 semanas antes de dimensionar. A maioria dos workloads roda com 40-60% dos recursos que o time achava necessários.
Erro #2: Tratar OCI como “AWS com outro sotaque”
OCI tem padrões próprios:
- Compartment (namespace + billing unit, nível ainda mais granular que AWS account)
- VCN (parecido com VPC, mas com conceito de “IPv6 prefix lengths” diferentes)
- Resource Manager (IaC nativo baseado em Terraform, não é CloudFormation)
- IAM policies em sintaxe Oracle-specific (“Allow group X to manage Y in compartment Z”)
Times que tentam “fingir que é AWS” perdem semanas em pequenas fricções. Vale 2-3 dias de treinamento específico em OCI antes de começar a desenhar a landing zone.
5. FinOps começa na semana 1, não depois do go-live
O erro mais caro que vimos: cliente migrou 15 databases, ficou 6 meses operando, aí começou a pensar em otimização. Nesse meio tempo, gastou R$ 2,3 MM a mais do que o necessário.
O correto:
- Semana 1 pós go-live: tags em todos os recursos (
project,owner,env,cost-center) - Mês 1: dashboard de custo por compartment, alerta de orçamento
- Mês 2: revisão de shapes — muitos databases aceitam downgrade
- Mês 3: autoscale configurado para staging/hml/dev (ligam 8-18h, desligam à noite)
- Trimestre 1: committed use discounts (CUD) nas cargas estáveis — tipicamente 20-30% de desconto com 1 ano
Sem esse ritmo, a conta de OCI cresce 5-8% ao mês por “drift” natural.
6. Checklist de entrada
Se você está começando, responda antes de pedir proposta:
- Por que agora? (custo, end-of-life de hardware, compliance, consolidação)
- Quantos databases? Versões (11g, 12c, 19c, 21c)? Edition (SE, EE, RAC)?
- Tamanho dos datasets? (total + maior database individual)
- Downtime aceitável? Por database crítico
- Dependências cross-database? (db links, views heterogêneas)
- Compliance? (LGPD, Bacen, ANS, PCI, SOX — afeta region e compartment design)
- Team readiness? (DBA que já operou Oracle Cloud? se não, treine antes)
- Prazo? (realista: 3-9 meses para 5-20 DBs; mais de 20 DBs = programa em ondas)
- Budget de migração? (tipicamente 15-25% do custo anual futuro)
7. Conclusão
Migrar Oracle para OCI não é o hype de “multi-cloud” ou “cloud-native”. É uma decisão de continuidade operacional + otimização de custo + simplificação de time. Funciona bem quando:
- O business case não depende SÓ de licenciamento
- Você escolhe o shape certo (nem tudo é Exadata)
- Você aceita downtime planejado onde ele vale a pena
- Você implementa FinOps na semana 1, não no trimestre 3
Se isso não parece trivial, tem razão. Não é. Mas é fazível com um plano honesto e uma equipe que já viu o filme antes.
Na Redgator: rodamos 11 migrações Oracle→OCI desde 2022, do porte enterprise ao mid-market. Se quiser uma segunda opinião sobre seu plano, fale com um especialista.
Publicado em 10/04/2026. Última revisão: 10/04/2026.