Migração Oracle Forms para PostgreSQL

Migração Oracle Forms para PostgreSQL é um projeto de modernização que precisa analisar simultaneamente a aplicação Oracle Forms, a lógica de negócio, o código PL/SQL, o banco de dados Oracle, as integrações e a arquitetura de execução. Diferentemente de uma migração exclusivamente de banco de dados, uma aplicação Forms possui componentes que podem depender diretamente de recursos específicos do Oracle.

O Oracle Forms Services utiliza uma arquitetura de múltiplas camadas na qual o Forms Runtime executa a aplicação e se comunica com o banco de dados. A documentação atual da Oracle descreve o ambiente como uma arquitetura de três camadas, com componentes de cliente, middle tier e banco de dados.

Por esse motivo, migrar uma aplicação Oracle Forms para PostgreSQL exige identificar quais componentes pertencem ao banco, quais pertencem à aplicação e quais dependem da plataforma Oracle.

O objetivo pode ser simplesmente substituir o banco Oracle mantendo a aplicação Forms durante uma etapa intermediária, ou pode envolver uma modernização mais ampla da aplicação. Essas duas estratégias são diferentes e devem ser avaliadas separadamente.

O que está envolvido em uma aplicação Oracle Forms

Uma aplicação Oracle Forms tradicional pode conter diversos componentes interdependentes.

• Forms Modules;
• data blocks;
• canvas;
• windows;
• menus;
• triggers;
• program units;
• PL/SQL;
• packages;
• procedures;
• functions;
• libraries;
• alertas;
• relatórios;
• consultas SQL;
• integrações com outros sistemas;
• rotinas de autenticação;
• processos batch.

Uma parte significativa da lógica de negócio pode estar distribuída entre os Forms e o banco de dados. A documentação da Oracle sobre modernização de Forms destaca justamente a importância de identificar triggers, program units e eventos que concentram lógica de negócio.

Essa característica torna o assessment fundamental antes da definição da estratégia.

Arquitetura do Oracle Forms e impacto da migração

O Oracle Forms Services não deve ser confundido com o próprio Oracle Database.

Na arquitetura tradicional, existem diferentes responsabilidades:

• interface da aplicação;
• execução dos módulos Forms;
• comunicação entre cliente e servidor;
• lógica de aplicação;
• acesso ao banco;
• processamento SQL;
• lógica PL/SQL;
• integrações externas.

Na arquitetura atual do Oracle Forms Services, o Forms Runtime executa o código da aplicação e atua como cliente do banco de dados, enquanto a infraestrutura intermediária gerencia a execução e a comunicação com os clientes.

Consequentemente, a substituição do Oracle Database por PostgreSQL pode afetar diretamente componentes que assumem comportamento específico do Oracle.

Estratégias possíveis para migrar Oracle Forms

Não existe uma única estratégia para todos os ambientes Oracle Forms.

Manter Oracle Forms e substituir o banco

Nessa abordagem, o objetivo inicial é preservar a aplicação Forms e migrar o banco Oracle para PostgreSQL ou EDB Postgres.

É uma estratégia de menor transformação funcional, porém exige uma análise detalhada da compatibilidade da aplicação com o novo banco.

Migrar o banco e modernizar gradualmente a aplicação

Nesse modelo, o banco é migrado primeiro e a modernização da camada de aplicação ocorre posteriormente.

Essa abordagem pode reduzir o risco de executar simultaneamente uma transformação de banco e uma reconstrução completa da aplicação.

Modernizar a aplicação junto com a migração

Em determinados projetos, a organização decide substituir o Forms por uma aplicação web, APIs ou outra plataforma moderna.

Nesse cenário, a migração deixa de ser apenas Oracle Forms para PostgreSQL e passa a ser um projeto de modernização de aplicação.

Estratégia híbrida

Também é possível manter parte das aplicações Forms e modernizar módulos progressivamente.

Essa abordagem pode ser adequada quando o ambiente possui centenas de telas, grande quantidade de usuários ou aplicações críticas que não podem ser substituídas simultaneamente.

Assessment da aplicação Oracle Forms

Antes de converter qualquer componente, deve ser criado um inventário técnico da aplicação.

Inventário dos módulos

• quantidade de Forms;
• versões utilizadas;
• módulos compartilhados;
• libraries;
• menus;
• relatórios;
• dependências externas;
• componentes obsoletos.

Inventário do código

• triggers;
• program units;
• procedures;
• functions;
• packages;
• SQL embutido;
• funções Oracle;
• variáveis específicas;
• comandos dependentes do Oracle.

Inventário das dependências

• Oracle Database;
• Oracle Forms Services;
• WebLogic;
• Oracle Reports;
• diretórios compartilhados;
• serviços externos;
• APIs;
• jobs;
• processos batch;
• autenticação corporativa.

A instalação atual do Oracle Forms envolve componentes como WebLogic Server, Administration Server, Node Manager e, conforme a arquitetura, serviços adicionais como Forms Application Deployment Services e Oracle HTTP Server.

Identificação das dependências Oracle

O principal objetivo do assessment é descobrir onde a aplicação depende diretamente do Oracle.

Entre os exemplos estão:

• packages Oracle;
• sequences;
• synonyms;
• database links;
• views de catálogo;
• tipos de dados Oracle;
• funções Oracle;
• procedures;
• triggers;
• SQL específico;
• recursos de transação;
• mecanismos de autenticação;
• rotinas administrativas.

Quanto maior a quantidade de dependências específicas, maior tende a ser o esforço de conversão.

PL/SQL dentro das aplicações Oracle Forms

O PL/SQL é um dos pontos mais importantes da análise.

O código pode estar presente em:

• triggers de Forms;
• program units;
• packages do banco;
• procedures;
• functions;
• triggers de tabelas;
• jobs;
• rotinas de processamento.

Nem todo código PL/SQL apresenta o mesmo nível de dependência do Oracle.

Uma análise técnica deve classificar cada componente em categorias como:

• código compatível;
• código que exige pequenos ajustes;
• código que exige conversão;
• código que precisa ser reescrito;
• código que pode ser eliminado.

O EDB Postgres Advanced Server oferece compatibilidade Oracle em diversas áreas, incluindo PL/SQL, tipos de dados, objetos compatíveis, extensões SQL e packages Oracle. Isso pode reduzir o esforço de conversão em determinados cenários, mas não significa compatibilidade integral com todas as funcionalidades do Oracle.

Oracle Forms para PostgreSQL ou EDB Postgres?

A escolha do banco de destino precisa considerar o nível de dependência existente na aplicação.

PostgreSQL

O PostgreSQL pode ser adequado quando a aplicação possui baixo acoplamento às funcionalidades proprietárias do Oracle ou quando existe disposição para realizar a conversão necessária.

EDB Postgres Advanced Server

O EDB Postgres Advanced Server pode ser particularmente relevante quando a aplicação possui dependências Oracle que podem ser atendidas por seus recursos de compatibilidade.

A EDB documenta compatibilidade com objetos específicos do Oracle, tipos de dados, extensões SQL, PL/SQL e views de catálogo, entre outros recursos.

Essa escolha deve ser baseada no assessment, e não simplesmente na quantidade de código existente.

Conversão dos componentes do Oracle Forms

A conversão deve ser executada por componente e não como uma única operação.

Forms e Data Blocks

Os data blocks normalmente representam estruturas diretamente relacionadas às tabelas, views e consultas do banco.

Durante a migração devem ser avaliados:

• consultas utilizadas;
• relacionamentos;
• chaves;
• validações;
• triggers;
• procedimentos chamados;
• tratamento de erros.

Triggers

Triggers podem conter uma parcela importante da lógica da aplicação.

Devem ser classificados por evento e responsabilidade, identificando quais dependem de recursos Oracle.

Program Units

Program Units podem conter regras de negócio, cálculos, chamadas de procedures e funções e operações SQL.

Esses componentes precisam ser analisados individualmente.

Packages

Packages Oracle devem ser avaliados tanto pela estrutura quanto pelas dependências internas.

Quando o destino for EDB Postgres Advanced Server, parte das funcionalidades Oracle pode ser preservada ou adaptada com menor esforço graças aos recursos de compatibilidade disponíveis.

Migração dos dados Oracle para PostgreSQL

A aplicação Forms depende da consistência do banco de dados. Por isso, a migração dos dados deve ocorrer paralelamente à análise da aplicação.

Devem ser avaliados:

• tabelas;
• views;
• índices;
• constraints;
• sequences;
• particionamento;
• LOBs;
• tipos de dados;
• dados históricos;
• volume de crescimento.

O EDB Migration Toolkit é uma ferramenta voltada a migrações de dados entre diferentes bancos e, no cenário Oracle para EDB Postgres Advanced Server, é utilizado principalmente para migrações do tipo snapshot. A EDB também disponibiliza o Migration Portal para assessment e conversão de schemas Oracle.

Integrações e interfaces externas

Uma aplicação Forms raramente existe isoladamente.

O assessment deve identificar integrações com:

• ERP;
• sistemas financeiros;
• sistemas de faturamento;
• serviços web;
• APIs;
• arquivos;
• mensageria;
• processos batch;
• outros bancos de dados.

Também devem ser identificadas chamadas feitas diretamente a recursos Oracle, pois essas dependências podem deixar de funcionar após a substituição do banco.

Relatórios Oracle Forms

Ambientes antigos frequentemente utilizam Oracle Reports ou mecanismos associados ao ecossistema Oracle.

Esses componentes devem ser inventariados separadamente da aplicação Forms.

Para cada relatório, devem ser identificados:

• fonte dos dados;
• queries;
• procedures utilizadas;
• packages;
• parâmetros;
• agendamentos;
• formato de saída;
• integrações.

Um relatório que depende de SQL ou PL/SQL específico do Oracle pode exigir conversão mesmo quando a tela Forms correspondente apresentar poucas dependências.

Performance após a migração

A substituição do banco pode alterar o comportamento das consultas executadas pelas aplicações Forms.

Devem ser monitorados:

• tempo de resposta das telas;
• tempo das consultas;
• transações;
• locks;
• uso de CPU;
• memória;
• IO;
• conexões simultâneas;
• consultas de longa duração;
• processamento batch.

Consultas que apresentavam bom desempenho no Oracle precisam ser analisadas novamente no PostgreSQL. Índices, estatísticas, planos de execução e parâmetros podem precisar de ajustes.

Alta disponibilidade para aplicações Oracle Forms

Se a aplicação Forms é crítica para o negócio, a arquitetura PostgreSQL precisa atender aos requisitos de disponibilidade da aplicação.

Isso pode envolver:

• PostgreSQL primário;
• standby;
• replicação;
• failover;
• balanceamento;
• monitoramento;
• backup;
• procedimentos de recuperação.

A camada de aplicação também deve ser considerada. Não adianta criar alta disponibilidade somente no banco se os componentes responsáveis pela execução do Forms continuarem representando um ponto único de falha.

Segurança

A migração deve preservar ou aprimorar os requisitos de segurança existentes.

Devem ser avaliados:

• autenticação;
• autorização;
• roles;
• permissões;
• contas técnicas;
• credenciais;
• criptografia;
• auditoria;
• conexões entre aplicação e banco;
• acesso administrativo.

As credenciais utilizadas pela aplicação devem ser revistas durante a migração, evitando transportar configurações antigas sem avaliação.

Testes de uma aplicação Oracle Forms migrada

Os testes precisam validar tanto a aplicação quanto o banco.

Testes funcionais

• abertura das telas;
• consultas;
• inclusões;
• alterações;
• exclusões;
• validações;
• processos;
• navegação.

Testes de regras de negócio

• triggers;
• procedures;
• functions;
• packages;
• cálculos;
• validações;
• transações.

Testes de integração

• APIs;
• arquivos;
• serviços externos;
• processos batch;
• relatórios.

Testes de performance

• tempo de abertura de telas;
• consultas críticas;
• operações concorrentes;
• processamento de grandes volumes;
• processos batch.

Estratégia de coexistência

Em ambientes grandes, pode ser necessário manter Oracle e PostgreSQL simultaneamente durante uma fase de transição.

Essa coexistência permite:

• migrar aplicações por etapas;
• validar módulos individualmente;
• reduzir o risco do cutover;
• manter o ambiente legado disponível;
• realizar testes comparativos;
• planejar a retirada gradual do Oracle.

Entretanto, a coexistência também aumenta a complexidade operacional e deve possuir prazo, responsabilidades e critérios claros de encerramento.

Cutover da aplicação Oracle Forms

O cutover precisa ser planejado como uma operação técnica controlada.

O checklist pode incluir:

• bloqueio ou controle das alterações no ambiente Oracle;
• sincronização final dos dados;
• validação da consistência;
• ativação do ambiente PostgreSQL;
• alteração das configurações da aplicação;
• testes de conectividade;
• testes funcionais;
• liberação gradual dos usuários;
• monitoramento intensivo.

O procedimento também deve possuir critérios objetivos para determinar se a migração foi concluída com sucesso.

Plano de rollback

O rollback deve ser definido antes do cutover.

Entre os pontos necessários estão:

• condições para acionamento;
• responsáveis pela decisão;
• estado dos dados;
• retorno das configurações da aplicação;
• restauração da conectividade com Oracle;
• comunicação aos usuários;
• procedimentos de recuperação.

Quanto maior a criticidade da aplicação, maior deve ser o rigor dos testes do procedimento de rollback.

Modernização do Oracle Forms após a migração

A migração do banco pode ser utilizada como primeira etapa de uma modernização maior.

Depois que a aplicação deixa de depender diretamente do Oracle Database, a organização pode avaliar uma evolução gradual da camada de aplicação.

Entre as possibilidades estão:

• interfaces web;
• APIs;
• arquiteturas orientadas a serviços;
• modernização de módulos;
• separação da lógica de negócio;
• substituição gradual de telas legadas.

A Oracle também documenta estratégias para modernizar aplicações Forms para Oracle APEX, demonstrando que a modernização da interface pode ser tratada como uma etapa distinta da transformação do banco de dados.

Para uma estratégia direcionada ao PostgreSQL, entretanto, a arquitetura de modernização deve ser definida de acordo com os requisitos da organização e não simplesmente replicar uma arquitetura Oracle.

Principais riscos da migração Oracle Forms para PostgreSQL

• subestimar a quantidade de código PL/SQL;
• não identificar dependências Oracle;
• migrar somente as tabelas e ignorar a aplicação;
• não testar todas as telas críticas;
• ignorar relatórios;
• não validar integrações;
• subestimar consultas de alta complexidade;
• não testar performance;
• não testar failover;
• não possuir rollback;
• tentar modernizar toda a aplicação simultaneamente sem planejamento.

Metodologia para Migração Oracle Forms para PostgreSQL

Uma metodologia estruturada pode dividir o projeto em etapas controláveis.

• assessment da aplicação;
• inventário dos módulos Forms;
• inventário do banco Oracle;
• mapeamento das dependências;
• análise de compatibilidade;
• classificação do esforço de conversão;
• definição da arquitetura PostgreSQL;
• conversão dos objetos;
• migração dos dados;
• adaptação do código;
• testes funcionais;
• testes de performance;
• testes de integração;
• homologação;
• cutover;
• operação assistida.

Benefícios da migração Oracle Forms para PostgreSQL

Quando executada com planejamento adequado, a migração pode contribuir para uma arquitetura mais flexível e preparada para modernização.

• redução da dependência do Oracle Database;
• maior flexibilidade de infraestrutura;
• possibilidade de adoção de PostgreSQL Enterprise;
• possibilidade de utilização de EDB Postgres Advanced Server;
• modernização gradual da aplicação;
• padronização tecnológica;
• flexibilidade para ambientes físicos, virtuais e cloud;
• redução da dependência de tecnologias proprietárias;
• preparação para evolução arquitetural.

O resultado efetivo depende da complexidade do ambiente, da quantidade de código proprietário, da arquitetura de destino e do nível de modernização pretendido.

Migração Oracle Forms para EDB Postgres Advanced Server

Para aplicações Forms fortemente acopladas ao Oracle, o EDB Postgres Advanced Server pode ser avaliado como destino intermediário ou definitivo para o banco de dados.

A EDB disponibiliza recursos de compatibilidade Oracle que abrangem PL/SQL, objetos, tipos de dados, comandos SQL, funções, operadores, views de catálogo e packages, entre outros componentes.

Essa compatibilidade pode reduzir o volume de conversões necessárias, especialmente em ambientes com grande quantidade de código Oracle.

Entretanto, o assessment continua sendo indispensável porque a compatibilidade não significa que toda aplicação Forms possa ser executada sem alterações.

Links Relacionados

• Migração Oracle para PostgreSQL
• Planejamento de Migração Oracle para PostgreSQL
• Estratégia de Migração Oracle para PostgreSQL
• Ferramentas de Migração Oracle para PostgreSQL
• Migração de Dados Oracle para PostgreSQL
• Migração de Aplicações Oracle para PostgreSQL
• PL/SQL no PostgreSQL
• Packages Oracle
• Procedures Oracle
• Triggers Oracle
• Testes Pós-Migração Oracle para PostgreSQL
• PostgreSQL Enterprise

Recursos Oficiais

• Oracle — Oracle Forms Services Architecture
• Oracle — Oracle Forms
• Oracle — Installing and Configuring Oracle Forms
• EDB — Migration Handbook
• EDB — EDB capabilities for the migration journey
• EDB — Oracle Support and Compatibility
• EDB — Migration Toolkit
• EDB — Migration Portal
• PostgreSQL — Documentação Oficial

FAQ — Perguntas Frequentes

É possível migrar Oracle Forms para PostgreSQL?

Sim. Porém, é necessário distinguir a migração do banco de dados da modernização da aplicação Forms. A substituição do Oracle Database por PostgreSQL exige análise das dependências SQL, PL/SQL, packages, procedures, triggers e demais recursos Oracle utilizados pela aplicação.

É necessário abandonar o Oracle Forms durante a migração?

Não necessariamente. Uma estratégia possível é migrar primeiro o banco de dados e manter a aplicação durante uma fase de transição. Outra possibilidade é modernizar simultaneamente a camada de aplicação. A decisão depende do assessment.

O Oracle Forms funciona diretamente com PostgreSQL?

Não deve ser assumido que uma aplicação Forms existente funcionará sem alterações apenas porque o banco de dados foi substituído. O comportamento depende das interfaces de acesso, SQL utilizado, PL/SQL, objetos Oracle e demais dependências da aplicação.

EDB Postgres Advanced Server pode facilitar a migração?

Em determinados cenários, sim. O EDB Postgres Advanced Server possui recursos de compatibilidade Oracle, incluindo PL/SQL, tipos de dados, objetos, funções, operadores, packages e views de catálogo. Isso pode reduzir o esforço de conversão, mas não elimina a necessidade de testes.

O código PL/SQL do Oracle Forms precisa ser convertido?

Depende do código. Cada trigger, program unit, procedure, function e package deve ser classificado de acordo com seu nível de dependência das funcionalidades Oracle.

É possível migrar apenas o banco e manter as telas Forms?

Essa pode ser uma estratégia de transição, desde que a aplicação seja compatível com o banco de destino ou possa ser adaptada. O assessment deve identificar as alterações necessárias antes do cutover.

O que acontece com os Oracle Forms Triggers?

Os triggers devem ser analisados individualmente. Alguns contêm somente lógica de interface, enquanto outros executam regras de negócio ou chamadas a funcionalidades específicas do Oracle. O tratamento depende da responsabilidade de cada trigger.

Como migrar Packages Oracle utilizados pelo Forms?

Os packages devem ser analisados em conjunto com suas dependências. Quando o destino for EDB Postgres Advanced Server, recursos de compatibilidade podem permitir o aproveitamento de parte da implementação, enquanto outras estruturas podem exigir conversão.

É possível fazer a migração sem downtime?

Dependendo da arquitetura, do volume de dados e dos requisitos do negócio, pode ser possível reduzir significativamente a indisponibilidade. Entretanto, a possibilidade de zero downtime precisa ser comprovada durante o planejamento e os testes.

Quanto tempo demora uma migração Oracle Forms para PostgreSQL?

O prazo depende da quantidade de módulos, volume de código, complexidade do banco, quantidade de integrações, criticidade das aplicações, estratégia de conversão e nível de modernização pretendido.

Qual é a principal diferença entre migrar Oracle Forms e migrar somente Oracle Database?

Na migração de banco, o foco principal está em dados e objetos. Em uma aplicação Forms, também precisam ser analisados a interface, triggers, program units, PL/SQL, integrações, relatórios, runtime e demais componentes da aplicação.

O Oracle Forms pode ser modernizado depois da migração para PostgreSQL?

Sim. A migração do banco pode ser utilizada como uma etapa de desacoplamento tecnológico, permitindo que a modernização da aplicação seja realizada posteriormente e de forma gradual.

Conclusão

A Migração Oracle Forms para PostgreSQL deve ser conduzida como um projeto de aplicação e banco de dados, e não apenas como uma conversão de tabelas.

O primeiro passo é compreender a arquitetura existente, identificar onde estão as regras de negócio, mapear as dependências Oracle e classificar o esforço necessário para cada componente.

Em ambientes fortemente dependentes de Oracle, o EDB Postgres Advanced Server pode ser avaliado devido aos seus recursos de compatibilidade. Em aplicações com menor dependência proprietária, o PostgreSQL também pode ser uma alternativa adequada.

A estratégia mais segura é combinar assessment, conversão incremental, testes funcionais, validação de dados, testes de performance, homologação, planejamento de cutover e operação assistida.

Dessa forma, a organização pode transformar uma aplicação Oracle Forms legada em uma arquitetura baseada em PostgreSQL Enterprise, preservando os requisitos essenciais do negócio enquanto cria condições para uma modernização progressiva da aplicação.

Modernize seu Banco de Dados com a Dominus Tech

👉 Planejando uma Migração Oracle para PostgreSQL?

A Dominus Tech é Parceira Gold da EnterpriseDB e apoia empresas em todas as etapas da modernização de bancos de dados Oracle para PostgreSQL. Nossa equipe atua em assessment, planejamento, análise de compatibilidade, arquitetura, migração, otimização de desempenho, alta disponibilidade, observabilidade e suporte especializado para ambientes PostgreSQL Enterprise.

✔ Parceira Gold da EnterpriseDB no Brasil

O planejamento adequado permite transformar uma migração complexa em um projeto estruturado, com riscos identificados, responsabilidades definidas, critérios de sucesso e estratégia de execução. A Dominus Tech pode apoiar sua organização desde a avaliação inicial até a estabilização do ambiente PostgreSQL em produção.

Entre em contato com nossos especialistas e solicite uma avaliação técnica do seu ambiente Oracle. Descubra a melhor estratégia para migrar para PostgreSQL com segurança, desempenho e redução de riscos.

O post Migração Oracle Forms para PostgreSQL: Estratégia, Conversão e Modernização apareceu primeiro em Dominus Tech Conecta.