Licenças OutSystems e Oracle APEX: o custo de não ser dono do software

As plataformas low-code resolveram um problema real: entregar aplicações internas depressa, sem uma equipa de engenharia completa. Dez anos depois, muitas empresas portuguesas têm dezenas de aplicações críticas a correr em OutSystems ou em Oracle APEX, e descobrem que a conta não é só a da licença.

Este artigo explica onde está o custo escondido, o que é possível manter, e como se sai de uma plataforma destas sem parar a operação.

O que se paga, para além da licença

Por utilizador, todos os anos. O modelo comercial destas plataformas cresce com o número de pessoas que usam as aplicações. Uma aplicação de sucesso, que toda a empresa adota, é a que mais custa. O incentivo está invertido: quanto mais útil o software, mais cara a fatura.

O runtime é deles. A lógica de negócio que a sua equipa escreveu só corre dentro da plataforma. Não há um executável, um repositório ou um contentor que possa levar para outro lado. Se a licença termina, as aplicações param. Isto chama-se dependência do fornecedor, e é o que torna cada renovação uma negociação em que só um dos lados pode dizer não.

A base de dados fica presa ao motor. No caso do Oracle APEX, a aplicação vive dentro da base de dados Oracle, com a sua própria licença. No caso do OutSystems, o modelo de dados é gerido pela plataforma. Em ambos, extrair a lógica e os dados para outro sistema é trabalho de engenharia, não uma exportação.

As pessoas. As competências de OutSystems e de APEX são específicas da plataforma. Contratar é mais caro, e quem sai leva conhecimento que não se transfere para outras ferramentas. Competências em SQL, .NET e React existem em qualquer mercado.

O que se mantém quando se sai

A parte valiosa de uma aplicação interna raramente é o código. É o conhecimento do domínio: os campos que importam, as validações que evitam erros, os fluxos de aprovação, os relatórios que a direção abre à segunda-feira de manhã. Tudo isso foi definido pelas pessoas que fazem a operação, e tudo isso transita.

A abordagem da QuickBytes, com a metodologia IdeaBuild, parte desse conhecimento. As pessoas que gerem a operação já sabem o que a aplicação tem de fazer. Com inteligência artificial generativa dentro de controlos definidos, esse conhecimento transforma-se em software a funcionar em semanas, não em meses.

O que resulta é software que é seu:

• Código em .NET e React, num repositório que controla, pronto a correr na sua infraestrutura ou na cloud que escolher.
• Dados em PostgreSQL, em tabelas normais, consultáveis por qualquer ferramenta de BI ou de reporting.
• Autenticação e permissões em Keycloak, com perfis e regras de acesso aplicadas no servidor.
• Zero licenças por utilizador. O custo não cresce com a adoção. Toda a base é open source.

Como se migra sem parar a operação

Migrar tudo de uma vez é o erro mais comum e o mais caro. A metodologia que seguimos é por fases, com a aplicação antiga e a nova a correr em paralelo até cada módulo estar validado.

1. 1. Briefing e inventário. Listamos as aplicações, os módulos, os utilizadores e as integrações. Dizemos-lhe o que migra diretamente e o que pede decisão.
2. 2. Diagnóstico. Para cada aplicação, medimos o custo atual, o risco de a deixar como está e o esforço de a migrar. Decide com números.
3. 3. Construir ou migrar, módulo a módulo. Cada módulo passa para a nova base com escrita dupla durante a transição. Se algo falha, volta-se atrás sem impacto nos utilizadores.
4. 4. Entrada em produção por módulo. A plataforma antiga desliga-se quando o último módulo está validado, não antes.

Há pontos de saída entre cada passo. Pode parar depois do diagnóstico com um documento que vale por si, sem compromisso com a migração.

Quando faz sentido ficar

Nem toda a aplicação low-code deve sair. Se é pequena, tem poucos utilizadores, muda pouco e a licença é uma linha irrelevante no orçamento, o custo de migrar pode não compensar. O diagnóstico serve precisamente para separar essas aplicações das outras: as que crescem em utilizadores, as que mudam todos os meses e as que estão no caminho crítico da operação.

Para estas últimas, cada ano de adiamento é mais um ano de licença e mais lógica de negócio presa a um runtime que não controla.

Leitura adicional

A IdeaBuild publicou em inglês um guia detalhado sobre como extrair lógica de negócio de runtimes proprietários e migrar para .NET, React e PostgreSQL: Escape the low-code trap: Oracle APEX, OutSystems. A metodologia de migração por fases, com os pontos de decisão e de retrocesso, está em Zero-downtime legacy migration methodology.

Se a sua empresa tem aplicações em OutSystems ou em Oracle APEX e quer números antes de decidir, agende uma apresentação de 30 minutos. Mostramos software a funcionar e um plano de ação com fases e pontos de saída.