Seu Oracle Forms ainda roda — mas o Java Applet que o sustenta foi descontinuado em 2015.
Modernizamos sistemas Oracle Forms e Reports para APEX, Java ou REST via ORDS — preservando as regras de negócio em PL/SQL que levaram anos para amadurecer.
Manter via workaround ou migrar definitivamente — avaliamos com você.
O Forms funciona. O browser não suporta mais o que o Forms precisa.
Quem tem Oracle Forms em produção — e por quê não sai fácil.
Oracle Forms foi o padrão de desenvolvimento para sistemas de gestão de órgãos públicos nos anos 90 e 2000. A base instalada no setor público brasileiro é enorme.
APEX, Java ou REST — o PL/SQL pode continuar.
A lógica de negócio em PL/SQL é um ativo real. A estratégia certa preserva isso.
Modernização dentro do Oracle
- Telas Forms → aplicação Oracle APEX
- PL/SQL, procedures e packages reaproveitados
- Interface web moderna, sem plugin, sem Applet
- Acesso mobile nativo, sem configuração especial
- Menor risco: banco Oracle permanece como está
Saída completa do ecossistema Oracle
- Forms → Java Spring Boot + React ou Angular
- PL/SQL migrado para Java service layer
- ORDS expõe procedures como REST durante a transição
- Migração do banco Oracle para PostgreSQL (quando necessário)
- Migração incremental, Form por Form, sem parar o órgão
O que torna a migração de Oracle Forms diferente de qualquer outro sistema.
O Forms parece simples de migrar. Até você encontrar o PL/SQL nas triggers.
Regras de negócio escondidas nas triggers de cada Form
Oracle Forms tem triggers em múltiplos níveis: bloco, item, formulário e nível de registro. Cada trigger é um fragmento de PL/SQL com lógica de negócio — validação, cálculo, chamada de procedure, controle de navegação. Não existe relatório automático de "todas as regras de negócio do sistema". É preciso abrir cada Form, inspecionar cada trigger e documentar o que cada uma faz. Sistemas com centenas de Forms têm milhares de triggers.
Como resolvemos: auditoria sistemática de triggers por Form, com documentação das regras como artefato do diagnóstico. Isso guia toda a migração e é entregue ao cliente independente do que decidirem fazer.APEX não migra Forms complexos automaticamente
Oracle tem uma ferramenta de migração Forms-para-APEX. Ela funciona para formulários simples. Para Forms com lógica complexa — timers, chamadas de Forms dentro de Forms (OPEN_FORM), validações em cascata de múltiplos blocos — a ferramenta gera código que não funciona corretamente. O resultado é uma aplicação APEX que parece o Forms mas se comporta diferente. A migração de Forms complexos exige redesign, não transposição automática.
Como resolvemos: usamos a ferramenta da Oracle para os Forms simples e redesenhamos manualmente os complexos. A classificação de quais são quais é parte do diagnóstico.ORDS: a ponte que viabiliza a migração gradual
Oracle REST Data Services (ORDS) permite expor procedures e packages PL/SQL como endpoints REST sem modificar o PL/SQL existente. Isso significa que durante a migração, as telas novas (em React, Angular ou APEX) podem chamar o PL/SQL legado via REST enquanto os novos serviços são construídos gradualmente. ORDS é o que torna o Strangler Fig viável em ambiente Oracle — e é subutilizado porque poucos conhecem a ferramenta.
Como resolvemos: ORDS como camada de API sobre o PL/SQL existente desde o início da migração. Novas telas já consomem via REST; quando o PL/SQL for reescrito, só muda a implementação, não a interface.Oracle Reports: a cadeia de chamadas que não está documentada
Oracle Reports frequentemente chama procedures PL/SQL que por sua vez chamam outros Reports, que chamam outras procedures. A cadeia de dependências não está visível em lugar nenhum sem análise manual. Ao migrar um relatório sem mapear a cadeia inteira, você descobre na produção que o relatório chama uma procedure que chama outro Report que ainda não foi migrado.
Como resolvemos: mapeamento completo do grafo de dependências Reports-Procedures antes de iniciar qualquer migração. Reports migramos na ordem inversa da cadeia: os folha primeiro, os raiz por último.O PL/SQL de um sistema Oracle Forms maduro é um ativo real — anos de regras de negócio, validações e integrações testadas em produção. A estratégia certa não joga fora esse PL/SQL: ela o expõe via ORDS e constrói a interface nova em cima disso.
Sem parar o órgão. Form por Form.
1. Diagnóstico
Auditamos as triggers, mapeamos os Reports e recomendamos APEX ou Java/REST — Form por Form, com custo e risco estimados.
2. ORDS como ponte
Expõe o PL/SQL existente como REST. Novas telas já consomem via API — o PL/SQL legado continua funcionando durante toda a transição.
3. Execução
Migramos Form por Form com o sistema original no ar. Cada Form migrado passa por testes antes do corte.
4. Entrega
Código, documentação das triggers e runbook de operação no seu repositório. Sem dependência de Java Applet ou IE.
Entregáveis que ficam com você.
Dúvidas comuns
Sim, via Oracle Forms WebLogic com configuração específica de browser (Chrome com política corporativa) ou via IE modo de compatibilidade. É um workaround com vida útil limitada — mas existe enquanto a migração não está pronta.
Para a maioria dos casos, sim. APEX é uma plataforma madura com suporte ativo da Oracle, muito mais produtiva para manutenção do que o Forms. Para casos muito complexos, avaliamos APEX complementado por Java para a lógica mais sofisticada.
Não é a estratégia. O PL/SQL maduro é um ativo — ele fica no banco e é exposto via ORDS como REST. A nova interface (APEX ou web) chama via API. O PL/SQL só é reescrito quando há razão técnica clara para isso.
Não, se for feita de forma incremental. Cada Form é migrado individualmente com o Forms original no ar. O novo Form só substitui o antigo após ser aprovado em testes. Usuários migram um módulo de cada vez.
Seus. Entregamos código, documentação de triggers e runbook no repositório que você indicar. Sem fidelidade mínima e sem lock-in.
Seu Oracle Forms pode sair do Applet sem perder o PL/SQL.
Comece por um diagnóstico. Sem reunião de trabalho, sem compromisso.