Toda empresa que roda Progress OpenEdge há mais de quinze anos chega ao mesmo impasse: o sistema funciona, sustenta o faturamento diário e ninguém quer encostar nele. Ao mesmo tempo, a base de desenvolvedores que domina a plataforma encolhe a cada ano, e cada nova integração custa mais caro que a anterior.
A resposta reflexa do mercado é a reescrita completa. É também a que mais fracassa.
Por que a reescrita completa quase sempre falha
Um ERP maduro em Progress carrega duas décadas de regras de negócio que nunca foram documentadas em lugar nenhum além do próprio código. Não é raro encontrar um procedimento de cálculo fiscal com dezenas de condicionais, cada uma correspondendo a uma exceção real que apareceu em produção e foi corrigida às pressas.
Uma reescrita do zero assume que essas regras podem ser levantadas antes de começar. Na prática, elas só aparecem quando o sistema novo erra o número e alguém do financeiro reclama. O projeto entra num ciclo em que a equipe passa mais tempo fazendo arqueologia do sistema antigo do que construindo o novo, e o prazo dobra antes da primeira entrega real.
O problema não é técnico, é de sequenciamento: você precisa que o sistema antigo continue rodando enquanto descobre o que ele realmente faz.
Estrangulamento incremental
A alternativa é o padrão que Martin Fowler batizou de strangler fig: em vez de substituir o sistema de uma vez, você intercepta funcionalidades específicas e as reimplementa fora, uma a uma, até que o núcleo antigo fique vazio.
Em Progress OpenEdge isso é viável porque a plataforma expõe pontos de integração maduros. O caminho que costuma funcionar:
- Exponha o que já existe. Publique procedimentos ABL existentes como serviços REST via PASOE. O código de negócio não muda; ganha apenas uma porta de entrada moderna.
- Mova a leitura antes da escrita. Relatórios e dashboards são o alvo natural da primeira fase — consultas não têm efeito colateral, então um erro não corrompe dado.
- Só então mova a escrita. Com leitura estável e a regra de negócio já compreendida, migrar operações transacionais deixa de ser um salto no escuro.
- Mantenha os dois caminhos vivos. Durante a transição, o sistema antigo continua sendo a fonte da verdade. O novo roda em paralelo e é comparado contra ele.
O passo 4 é o que separa uma migração controlada de uma aposta. Rodar os dois em paralelo e comparar resultados é o que revela as regras não documentadas — sem precisar de um levantamento prévio que nunca seria completo.
O papel dos dados
Sistemas Progress guardam décadas de histórico transacional, e esse acervo costuma ser o ativo mais subutilizado da empresa. A base OpenEdge é excelente para o transacional que foi projetada para atender, mas consultas analíticas pesadas competem por recurso com a operação — e é por isso que tantos relatórios só rodam de madrugada.
Replicar o histórico para uma camada analítica separada resolve os dois lados: a operação para de ser penalizada por consulta pesada, e a análise deixa de ser limitada pelo que o banco transacional aguenta responder em horário comercial. Na prática, esse costuma ser o primeiro entregável que a diretoria enxerga como valor, o que ajuda a sustentar o orçamento das fases seguintes.
O erro de tratar legado como passivo
A leitura corrente é que sistema legado é dívida técnica a ser quitada. É uma leitura incompleta.
Um sistema que processa pedidos há vinte anos sem perder transação incorpora um conhecimento operacional que nenhuma especificação nova reproduz. O risco real não é manter o legado — é substituí-lo por algo que ainda não provou nada, movido pela pressa de usar uma stack mais nova.
Modernizar bem significa preservar esse conhecimento e mudar o que de fato limita o negócio: a dificuldade de integrar, a lentidão para entregar mudança, a dependência de um número pequeno de pessoas. Nada disso exige jogar o núcleo fora.
Por onde começar
Antes de escolher tecnologia, vale responder três perguntas:
- O que trava o negócio hoje? Se a queixa é "demora para entregar mudança", o gargalo pode ser processo, não linguagem.
- Quais regras existem só no código? Mapear isso cedo define o tamanho real do projeto.
- Qual o custo de errar? Sistemas que movem dinheiro exigem execução paralela e comparação antes de qualquer corte.
A resposta a essas perguntas costuma mudar o escopo do projeto mais do que qualquer decisão de stack.
Se você mantém sistemas críticos em Progress, Delphi, Java ou PHP e está avaliando o caminho de modernização, fale com nosso time. Trabalhamos exatamente nessa fronteira entre estabilidade consolidada e tecnologia atual.