Migração Oracle para PostgreSQL Aurora na AWS com downtime mínimo
Assessment, automação e ciclos iterativos de validação viabilizaram a migração de uma aplicação corporativa crítica de Oracle para PostgreSQL Aurora na AWS, com downtime mínimo e redução dos custos de licenciamento.
Oracle to PostgreSQL Aurora on AWS migration with minimal downtime
Structured assessment, automation, and iterative validation cycles enabled the migration of a critical enterprise application from Oracle to PostgreSQL Aurora on AWS, with minimal downtime and reduced licensing costs.
Resumo executivo
Uma das maiores companhias aéreas da Europa precisava migrar uma plataforma interna de gestão de colaboradores e serviços corporativos — executada sobre Oracle Database há anos — para PostgreSQL Aurora na AWS. A decisão estratégica estava tomada; o desafio era executar a transição com segurança, minimizando a indisponibilidade de um sistema amplamente utilizado por diversas áreas da organização.
A Redgator conduziu o projeto em quatro etapas: assessment técnico detalhado, preparação e automação da conversão, migração com sincronização contínua via AWS DMS e bateria de validação com cobertura de 100% dos cenários críticos. O resultado foi uma migração produtiva concluída com downtime mínimo, redução dos custos de licenciamento Oracle e uma aplicação corporativa essencial operando em plataforma cloud alinhada à estratégia de longo prazo da empresa.
O desafio
O sistema migrado suportava processos internos de grande escala: gestão de colaboradores, registro de horas, equipamentos corporativos, suporte interno, chamados de TI e outras operações administrativas essenciais ao funcionamento da empresa. Tratava-se de uma aplicação crítica, utilizada diariamente por diferentes áreas, sem tolerância para indisponibilidade prolongada.
O ambiente acumulava anos de evolução sobre Oracle — procedimentos armazenados, funções legadas, consultas complexas, integrações com outros sistemas e regras de negócio nem sempre documentadas de forma completa. Parte dessas dependências era conhecida; outra parte precisava ser descoberta durante o assessment.
Além da conversão técnica, o projeto exigia garantir que os processos críticos continuassem operando normalmente após a transição. Migrar dados e objetos de banco era necessário, mas insuficiente — o sistema precisava se comportar em produção exatamente como antes.
A abordagem
A Redgator estruturou o projeto em ciclos iterativos de migração e validação, aumentando progressivamente a confiança na solução antes de qualquer execução produtiva.
Fase 1 — Assessment e planejamento
O ponto de partida foi um mapeamento completo do ambiente Oracle: schemas, tabelas, índices, procedimentos, funções, integrações, volumes de dados e funcionalidades específicas do Oracle que demandariam adaptação para PostgreSQL.
Ferramentas internas da Redgator automatizaram parte da coleta de informações, gerando inventários técnicos e identificando dependências entre objetos e aplicações de forma mais eficiente do que seria possível manualmente. Com base nesses resultados, o escopo da migração foi definido, os pontos de atenção mapeados e um plano de execução estabelecido com base nos requisitos operacionais do cliente.
Provas de conceito iniciais validaram a estratégia técnica antes do início da conversão em escala.
Fase 2 — Preparação e automação
Com o assessment concluído, a equipe desenvolveu automações para apoiar a conversão de objetos de banco de dados, validações de compatibilidade e comparação de resultados entre Oracle e PostgreSQL.
A estratégia seguiu ciclos sucessivos: converter, validar, ajustar, repetir. A cada iteração, os resultados eram analisados, correções incorporadas e novas validações executadas. Em determinadas etapas, recursos de inteligência artificial foram aplicados para apoiar a análise de funções legadas — auxiliando na identificação de relacionamentos entre objetos, fluxos de utilização e possíveis impactos da conversão.
Essa abordagem reduziu significativamente as atividades manuais, antecipou riscos e permitiu que a equipe chegasse à migração produtiva com procedimentos já amplamente testados.
Fase 3 — Migração e sincronização
A movimentação dos dados foi realizada via AWS Database Migration Service (DMS), mantendo Oracle e PostgreSQL sincronizados durante o período de transição. Essa sincronização contínua foi o mecanismo que tornou possível um cutover com downtime mínimo — a janela de indisponibilidade ficou restrita ao tempo necessário para a troca de conexões e validação final, não ao tempo de transferência de dados.
Os múltiplos dry-runs realizados nas fases anteriores permitiram que a equipe chegasse à execução produtiva com procedimentos já testados, métricas de tempo conhecidas e critérios claros para tomada de decisão durante a migração.
Fase 4 — Validação
A validação foi tratada como parte central do projeto, não como etapa final. Uma bateria automatizada de testes cobriu 100% dos cenários críticos, incluindo:
- Testes funcionais de processos de negócio
- Testes de integridade dos dados migrados
- Validação de consultas e procedimentos armazenados
- Testes de regressão
- Ensaios completos de migração (dry-runs)
Recursos de inteligência artificial também apoiaram a criação e revisão de cenários de teste, ampliando a cobertura e reduzindo o esforço manual de geração de casos de validação.
Resultados
A migração foi concluída com sucesso, mantendo a estabilidade da aplicação e eliminando os riscos identificados no assessment inicial.
| Indicador | Resultado |
|---|---|
| Downtime de cutover | Mínimo |
| Cenários críticos validados | 100% |
| Código legado | Convertido com automação e IA |
| Custos de licenciamento Oracle | Reduzidos |
| Dependências legadas mapeadas | 100% identificadas durante assessment |
| Plataforma | AWS Aurora PostgreSQL |
Além da redução de custos de licenciamento, a organização passou a operar uma aplicação essencial em uma plataforma alinhada à sua estratégia de cloud — com maior escalabilidade e menor dependência de software proprietário.
Próximos passos
A base técnica estabelecida neste projeto — metodologia de assessment, automações de conversão e bateria de testes — está disponível para aplicação em outros sistemas Oracle do ambiente da organização. A companhia aérea segue sua jornada de modernização com um processo de migração já validado em produção.
Executive summary
One of Europe’s largest airlines needed to migrate an internal employee management and corporate services platform — running on Oracle Database for years — to PostgreSQL Aurora on AWS. The strategic decision had been made; the challenge was executing the transition safely while minimizing downtime for a system used across many areas of the organization.
Redgator led the project in four stages: detailed technical assessment, conversion preparation and automation, migration with continuous sync via AWS DMS, and a validation suite covering 100% of critical scenarios. The result was a production migration completed with minimal downtime, reduced Oracle licensing costs, and an essential corporate application running on a cloud platform aligned with the company’s long-term strategy.
The challenge
The migrated system supported large-scale internal processes: employee management, time tracking, corporate equipment, internal support, IT tickets, and other administrative operations essential to the business. It was a critical application, used daily across departments, with no tolerance for extended downtime.
The environment had accumulated years of evolution on Oracle — stored procedures, legacy functions, complex queries, integrations with other systems, and business rules that were rarely fully documented. Some of these dependencies were known; others had to be discovered during the assessment.
Beyond the technical conversion, the project required ensuring that critical processes continued working normally after the transition. Migrating data and database objects was necessary but not sufficient — the system had to behave in production exactly as it had before.
The approach
Redgator structured the project in iterative migration-and-validation cycles, progressively increasing confidence in the solution before any production execution.
Phase 1 — Assessment and planning
The starting point was a complete mapping of the Oracle environment: schemas, tables, indexes, stored procedures, functions, integrations, data volumes, and Oracle-specific features that would require adaptation for PostgreSQL.
Redgator’s internal tooling automated part of the information gathering, generating technical inventories and identifying dependencies between objects and applications more efficiently than manual analysis would allow. Based on these results, the migration scope was defined, risks mapped, and an execution plan established to meet the client’s operational requirements.
Initial proof-of-concept runs validated the technical strategy before full-scale conversion began.
Phase 2 — Preparation and automation
With the assessment complete, the team developed automation to support database object conversion, compatibility validation, and result comparison between Oracle and PostgreSQL.
The strategy followed successive cycles: convert, validate, adjust, repeat. At each iteration, results were analyzed, corrections incorporated, and new validations run. At certain stages, AI capabilities were applied to help analyze legacy functions — assisting with identifying relationships between objects, usage flows, and potential conversion impacts.
This approach significantly reduced manual effort, surfaced risks early, and allowed the team to reach production migration with procedures already thoroughly tested.
Phase 3 — Migration and synchronization
Data transfer was performed via AWS Database Migration Service (DMS), keeping Oracle and PostgreSQL in sync throughout the transition period. This continuous synchronization was the mechanism that made minimal-downtime cutover possible — the unavailability window was limited to the time needed for connection switchover and final validation, not data transfer.
The multiple dry-runs from prior phases meant the team arrived at production execution with tested procedures, known time metrics, and clear decision criteria throughout the migration.
Phase 4 — Validation
Validation was treated as central to the project, not as a final step. An automated test suite covered 100% of critical scenarios, including:
- Functional tests for business processes
- Data integrity tests for migrated data
- Query and stored procedure validation
- Regression testing
- Full migration rehearsals (dry-runs)
AI capabilities also supported the creation and review of test scenarios, expanding coverage and reducing the manual effort of generating validation cases.
Results
The migration was completed successfully, maintaining application stability and eliminating the risks identified in the initial assessment.
| Indicator | Result |
|---|---|
| Cutover downtime | Minimal |
| Critical scenarios validated | 100% |
| Legacy code | Converted with automation and AI |
| Oracle licensing costs | Reduced |
| Legacy dependencies mapped | 100% identified during assessment |
| Platform | AWS Aurora PostgreSQL |
Beyond licensing cost reduction, the organization now runs an essential application on a cloud platform aligned with its cloud strategy — with greater scalability and reduced dependency on proprietary software.
Next steps
The technical foundation built during this project — assessment methodology, conversion automation, and test suite — is available for application to other Oracle systems in the organization’s environment. The airline continues its modernization journey with a migration process already validated in production.
Tem um problema parecido?
45 min com o TL que executou este case. Sem deck.
Got a similar problem?
45 min with the TL who ran this case. No deck.