Substitua a dependência, não o negócio.
A alternativa certa ao WinDev não é outra ferramenta para licenciar do seu fornecedor — é um modelo operacional que seu time pode ter, contratar para e evoluir sozinho. Este guia separa o que realmente precisa ser substituído do que seu negócio nunca deveria ter colocado em risco.
O que você está realmente substituindo
- A IDE e as ferramentas. O editor, o depurador, o assistente de deploy — tudo licenciado do seu fornecedor, tudo desaparece no dia em que você para de pagar.
- O runtime. Cada tela que seus usuários abrem depende de um runtime controlado pelo seu fornecedor, com taxas anunciadas para aplicações já em produção.
- A linguagem proprietária. Código escrito em uma linguagem mantida por uma única empresa tem um único mercado de contratação, um único roadmap, um único preço.
- O modelo de deploy. Onde e como a aplicação roda, decidido pelos termos de licença do seu fornecedor — não pelas suas necessidades de infraestrutura. O que não precisa ser substituído: seus dados, suas regras de negócio e os fluxos dos quais seus usuários dependem.
Os caminhos que as pessoas chamam de "alternativas"
1 · Stack web aberta
React ou Next.js no frontend com um backend aberto — .NET, Laravel, Django, Rails. Acesso máximo a talentos, hospedagem e bibliotecas.
2 · Caminho centrado em Microsoft
ASP.NET Core com React ou Blazor. Governança mais simples se sua organização já é padronizada em identidade e nuvem Microsoft.
3 · Converter com um método
Ler todo o código primeiro, extrair cada regra com um ID, converter domínio por domínio na ordem de dependências, e publicar na stack aberta que você escolher (16 stacks). É isso que o WXCode faz.
Como comparar alternativas
- Você consegue baixar o código-fonte? Não um subconjunto, não uma exportação — o projeto completo e executável, em um repositório git normal.
- Ele continua rodando se você cancelar? Pare de pagar a plataforma de modernização amanhã. Se a aplicação convertida parar de funcionar, você não saiu de um lock-in — você o realocou.
- Você consegue contratar no mercado aberto? Uma stack com um mercado de talentos real, não uma linguagem mantida por uma única empresa.
- As regras são rastreáveis até os testes? Cada regra de negócio deve ter um ID e um teste — mais de 2.000 testes gerados em um projeto real, não apenas uma tela que parece correta.
- O antigo e o novo conseguem rodar lado a lado? Uma virada domínio por domínio exige os dois sistemas ativos ao mesmo tempo, sobre os mesmos dados.
O teste de saída que realmente importa
O teste: Se você parasse de pagar a plataforma de modernização amanhã, a aplicação convertida continuaria rodando — com o código-fonte completo já em suas mãos? Esse é o único teste de saída que vale a pena. Lock-in é sobre a licença e a tecnologia, nunca sobre onde você escolhe hospedar ou rodar o resultado.
As perguntas que os desenvolvedores fazem primeiro
Só se a nova plataforma controlar seu runtime ou seu código-fonte. A saída do WXCode é um repositório git normal na stack que você escolher — baixe a qualquer momento, hospede onde quiser.
Não. O primeiro passo útil é quantificar o sistema — elementos, dependências, regras de negócio — não escolher um framework. O alvo certo geralmente fica óbvio assim que você consegue ver todo o código.
Modernização incremental — domínio por domínio, com o antigo e o novo rodando sobre os mesmos dados — costuma ser menos arriscada que uma virada completa, e é exatamente como funciona uma conversão por marcos.
Guias relacionados
Teste no seu projeto real.
Comece pela base de conhecimento, as dependências e as regras de negócio — antes de se comprometer com uma reescrita.