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.
If you got to this post, you are probably evaluating — or in the middle of — an Oracle to OCI migration. Maybe the datacenter contract expires next year. Maybe the CFO is pushing back on Oracle support cost. Maybe someone in leadership read that OCI got cheaper and wants to understand.
We will not sell you the migration. We will tell you what actually happens when it is done, based on five projects we ran between 2023 and 2025 — from banks to health insurance operators, from e-commerce to government.
1. The business case is not where you think
The conversation always starts with licensing. And yes, running Oracle in OCI brings BYOL with real savings — typically 20 to 30% on total database-as-a-service cost compared to AWS RDS Oracle or Azure Database for Oracle.
But in all 5 projects, the biggest gain did not come from the database. It came from:
- Shutting down old hardware. RAC clusters running on 2016-2018 servers cost a lot in maintenance, energy and VMware licensing. Getting out of that was more urgent than any query optimization.
- Reducing on-call DBA headcount. Automated backup, managed patching and native HA cut team pressure by ~40%.
- Consolidating environments. One client had 7 Oracle environments (dev, qa, staging, hml, prod, dr, sandbox). On OCI, we cut to 3 with pluggable databases sharing resources.
The spreadsheet that convinces the CFO is not “RDS vs OCI”. It is “hardware + license + DBA + downtime + opportunity cost” versus “Exadata Cloud with autoscale”.
2. Exadata Cloud is overkill for 80% of cases
Oracle sells Exadata as “the only decent way to run Oracle on the cloud”. It is not.
Across our 5 projects:
- 2 used Exadata Cloud Service (both with OLTP workloads > 10K TPS and datasets > 10 TB)
- 2 used Base Database Service on standard shape (typical ERP and CRM workloads)
- 1 used Autonomous Database (analytical environment, migrated from an on-prem data warehouse)
The cost difference between Exadata and Base Database is typically 4x to 8x. If your workload does not have characteristics that justify Exadata (smart scan, storage offloading, IORM), you are paying for a monster nobody feeds.
Key question to decide:
“Does my slowest query take advantage of smart scan? Can I benchmark before/after with traces?”
If you do not have a clear answer, it is not Exadata.
3. Zero downtime is a pretty story, not the default
Every cloud vendor paints zero-downtime migration as default. In practice:
| Strategy | Typical downtime | Complexity | Cost |
|---|---|---|---|
| Export / Import (data pump) | 4-24h | Low | Low |
| RMAN backup + restore | 2-8h | Medium | Low |
| GoldenGate replication | < 5 min | High | High |
| Zero Downtime Migration (ZDM) | < 5 min | High | Medium |
| Data Guard cross-cloud | < 1 min | Very high | High |
In 4 of the 5 projects, the client accepted a 2-4 hour window because the GoldenGate complexity trade-off was not worth it. Only the bank, where every minute costs a lot, chose ZDM.
Simple rule: if the client does not have a dedicated team that has operated GoldenGate before, do not sell GoldenGate. Use the window time and do a well-executed RMAN.
4. The two mistakes everyone makes
Mistake #1: Migrating with the same shapes as the old VM
The temptation is to grab top from the on-prem server, see “64 cores, 512 GB RAM” and provision the same in OCI. You just doubled the cost.
On-prem servers have:
- Deliberate overprovisioning (planned for 5 years)
- VMs sharing hardware with old software that consumes baseline
- Rare peak loads that nobody audits
In OCI, you pay for shape 24/7. Do CPU profiling over 2 weeks before sizing. Most workloads run with 40-60% of the resources the team thought were needed.
Mistake #2: Treating OCI as “AWS with a different accent”
OCI has its own standards:
- Compartment (namespace + billing unit, even more granular than AWS account)
- VCN (similar to VPC, but with different “IPv6 prefix lengths” concept)
- Resource Manager (native IaC based on Terraform, not CloudFormation)
- IAM policies in Oracle-specific syntax (“Allow group X to manage Y in compartment Z”)
Teams that try to “pretend it is AWS” lose weeks in small friction. It is worth 2-3 days of specific OCI training before starting to design the landing zone.
5. FinOps starts in week 1, not after go-live
The most expensive mistake we saw: client migrated 15 databases, operated for 6 months, then started thinking about optimization. In that meantime, they spent R$ 2.3M more than necessary.
The right way:
- Week 1 post go-live: tags on every resource (
project,owner,env,cost-center) - Month 1: cost dashboard per compartment, budget alert
- Month 2: shape review — many databases accept downgrade
- Month 3: autoscale configured for staging/hml/dev (on 8-18h, off at night)
- Quarter 1: committed use discounts (CUD) on stable workloads — typically 20-30% off with 1 year
Without that cadence, OCI bill grows 5-8% per month from natural drift.
6. Entry checklist
If you are starting, answer these before requesting a proposal:
- Why now? (cost, hardware end-of-life, compliance, consolidation)
- How many databases? Versions (11g, 12c, 19c, 21c)? Edition (SE, EE, RAC)?
- Dataset sizes? (total + largest individual database)
- Acceptable downtime? Per critical database
- Cross-database dependencies? (db links, heterogeneous views)
- Compliance? (LGPD, Bacen, ANS, PCI, SOX — affects region and compartment design)
- Team readiness? (DBA who has operated Oracle Cloud? If not, train first)
- Timeline? (realistic: 3-9 months for 5-20 DBs; over 20 DBs = waves program)
- Migration budget? (typically 15-25% of future annual cost)
7. Conclusion
Migrating Oracle to OCI is not the “multi-cloud” or “cloud-native” hype. It is a decision of operational continuity + cost optimization + team simplification. It works well when:
- The business case does not depend ONLY on licensing
- You choose the right shape (not everything is Exadata)
- You accept planned downtime where it is worth it
- You implement FinOps in week 1, not in quarter 3
If this does not seem trivial, you are right. It is not. But it is doable with an honest plan and a team that has seen the movie before.
At Redgator: we have run 11 Oracle→OCI migrations since 2022, from enterprise to mid-market. If you want a second opinion on your plan, talk to a specialist.
Published on 2026-04-10. Last review: 2026-04-10.