Seu sistema em PowerBuilder processa mais do que qualquer planilha consegue — mas quem vai manter?
Sustentamos sistemas PowerBuilder em produção e migramos para Java ou .NET — mantendo o que o DataWindow faz, sem perder as regras de negócio acumuladas em décadas.
Manter ou migrar, você decide. Comece por um diagnóstico.
O sistema funciona perfeitamente. O ecossistema em volta, não.
Quem tem PowerBuilder em produção e por que não sai fácil.
PowerBuilder dominou o desenvolvimento de sistemas de gestão financeira e ERP nos anos 90 e 2000. A razão de permanecer é o DataWindow — não há equivalente que faça o mesmo de forma tão produtiva.
Há mais de um caminho — e Appeon não é o único.
Sustentamos, modernizamos via Appeon ou reescrevemos — dependendo do que o negócio precisa.
Mantenha o PB no ar
- Manutenção corretiva e evolutiva em PowerScript
- Conversão para web via Appeon (sem reescrever)
- Integração com APIs REST e serviços modernos
- Atualização de versão do PB e do banco de dados
- Documentação das regras dos DataWindows
Reescreva quando fizer sentido
- PowerScript → Java Spring Boot ou C# .NET
- DataWindow → grid moderno + lógica de negócio explícita
- Sybase ASE → PostgreSQL ou SQL Server
- Migração incremental: tela por tela, com PB no ar
- Equivalência funcional comprovada antes de cada corte
O que torna PowerBuilder diferente de qualquer outra migração.
O problema não é a linguagem — é o DataWindow. E isso muda tudo na hora de migrar.
DataWindow: não existe equivalente direto em nenhuma outra plataforma
O DataWindow é um componente que gera SQL dinamicamente, renderiza grids editáveis e lida com atualizações de banco em bloco — tudo em um. Validação de campo, formatação condicional, cálculo de coluna, filtro, relatório: tudo configura no DataWindow. Ao migrar para Java ou .NET, cada DataWindow vira um contrato implícito que precisa ser reescrito explicitamente em código. Sem esse mapeamento, a migração perde comportamentos silenciosamente.
Como resolvemos: auditoria de cada DataWindow antes de iniciar a migração, documentando SQL, cálculos, validações e comportamentos de edição. Esses documentos guiam a reescrita.PowerScript parece C# — mas a semântica é diferente em pontos críticos
A sintaxe do PowerScript é visualmente similar ao C# e ao Java. Isso leva desenvolvedores a assumirem que a tradução é direta. Não é. Passagem de objeto por referência vs. por valor se comporta diferente. O modelo de eventos (Open, Activated, CloseQuery, Close) é diferente do ciclo de vida de um formulário .NET ou de um componente React. Código traduzido literalmente compila mas não se comporta igual.
Como resolvemos: rede de testes capturando o comportamento real antes da migração. Cada tela migrada passa pela rede antes de ir para produção.PFC (PowerBuilder Foundation Classes): a herança invisível que governa tudo
Muitos sistemas PB foram construídos sobre o PFC — um framework da Sybase com herança profunda de janelas, DataStores e objetos de serviço. Quem não conhece o PFC não consegue entender por que o sistema se comporta de determinada forma: o comportamento está na classe ancestral do PFC, não no código que você vê. Ignorar o PFC na migração é perder metade das regras.
Como resolvemos: mapeamento da herança PFC antes de qualquer intervenção. Identificamos quais comportamentos vêm do PFC e quais foram sobrescritos localmente.Appeon: para quando você precisa de tempo, não de reescrita imediata
O Appeon converte aplicações PB para web sem reescrever o código. É uma solução legítima para ganhar tempo — o cliente passa a acessar via browser sem VPN, sem instalar cliente. Mas tem limitações reais: DataWindows muito complexos com comportamento dinâmico podem não converter corretamente, chamadas de API Windows diretas não funcionam na versão web, e a licença do Appeon tem custo contínuo. É um meio-caminho, não um destino.
Como resolvemos: avaliamos as telas candidatas ao Appeon antes de decidir. Para as que não convertem bem, propomos reescrita específica. Appeon e reescrita podem coexistir no mesmo sistema.PowerBuilder tem uma das maiores demandas de migração entre as tecnologias legadas — especialmente no setor financeiro. O gargalo não é vontade de sair: é encontrar quem conheça o DataWindow profundamente o suficiente para migrar sem perder regras de negócio.
Sem parar a operação. DataWindow por DataWindow.
1. Diagnóstico
Auditamos o PFC, mapeamos cada DataWindow e avaliamos Appeon vs reescrita — módulo por módulo, com custo e risco estimados.
2. Rede de testes
Capturamos o comportamento de cada DataWindow com dados reais. Essa rede protege contra perda de regra de negócio na migração.
3. Execução
Migramos tela por tela com o PB original no ar. Cada tela migrada passa pela rede de testes antes do corte.
4. Entrega
Código no repositório, documentação dos DataWindows, runbook de deploy e plano de rollback. Sem lock-in.
Entregáveis que ficam com você.
Dúvidas comuns
Depende do objetivo. Se o problema é acesso web sem VPN, o Appeon resolve bem. Se o objetivo é modernizar a stack e sair da dependência do PB/SAP, o Appeon é um paliativo. Avaliamos caso a caso e recomendamos o caminho honesto.
Não, se a migração for feita corretamente. O DataWindow encapsula SQL, regras de edição, validação e formatação. Tudo isso precisa ser documentado e reescrito explicitamente na nova plataforma. É trabalho, mas é feito de forma sistemática.
Complica se não for mapeado antes. O PFC tem herança profunda que define comportamentos que não estão no código de negócio. Quem não conhece o PFC perde regras na migração. Fazemos o mapeamento da herança como parte do diagnóstico.
Sim. A migração do banco (Sybase ASE ou SQL Anywhere) é parte do processo. Mapeamos procedures, functions e triggers do Sybase que precisam ser convertidas para o dialeto do banco destino.
Seu, integralmente. Entregamos no repositório que você indicar, com documentação completa. Sem fidelidade mínima e sem lock-in — qualquer time Java ou .NET pode continuar o trabalho.
O DataWindow não precisa morrer para o sistema evoluir.
Comece por um diagnóstico. Sem reunião de trabalho, sem compromisso.