Quase todo parque legado grande tem a mesma biografia: uma tela em Oracle Forms que chama uma DLL escrita em VB6, um relatório em ASP clássico que ninguém sabe quem publicou, um módulo em C# .NET Framework feito depois — e os quatro gravando no mesmo banco de dados. Ninguém projetou isso. Foi sedimentado por vinte anos de decisões que, cada uma no seu ano, estavam certas.
É esse tipo de parque que estamos convertendo hoje, num cliente de saúde de grande porte, para uma arquitetura única em Angular no front e .NET Core no back, com microsserviços onde eles se pagam. Este texto é o roteiro — o que decidimos, em que ordem e por quê. O post irmão, Quando vale reescrever um sistema legado, trata da decisão anterior a esta: se vale mexer. Aqui o assunto é como.
Legado não é uma tecnologia, é um sedimento
O primeiro erro de diagnóstico é tratar o problema como uma questão de linguagem. "Temos um problema de Oracle Forms" é uma frase confortável, porque sugere uma solução comprável. O problema real é outro: ninguém sabe onde mora a regra de negócio. Ela está espalhada entre a validação da tela do Forms, um trigger no banco, uma stored procedure de mil linhas, uma DLL COM registrada num servidor específico e um if perdido num módulo C# de 2014.
Por isso o trabalho começa mapeando fronteiras, não tecnologias: quem escreve cada entidade, quem lê, e onde a decisão de negócio é efetivamente tomada. Martin Fowler chama esse estágio de research — entender o sistema antes de propor o substituto — e é a etapa que projetos apressados cortam primeiro, sempre com o mesmo resultado.
A conta que ninguém coloca no orçamento
Manter o legado tem um custo visível, que aparece na planilha, e dois invisíveis, que não aparecem em lugar nenhum: o custo de mudar qualquer coisa e o risco de plataforma. O segundo costuma ser tratado como abstração — "um dia isso vai dar problema" —, mas em parques como esse ele tem data marcada e verificável:
- VB6: a IDE está sem suporte desde 8 de abril de 2008. O runtime continua coberto apenas para regressões graves e falhas críticas de segurança, e só enquanto a versão do Windows hospedeira estiver em suporte. Na prática: não existe caminho suportado para criar ou manter aplicação VB6.
- Oracle Forms 12c: o Premier Support do Fusion Middleware 12c encerra em dezembro de 2026, com Extended Support até dezembro de 2027. Quem fica precisa planejar o salto para 14c só para comprar tempo.
- ASP clássico e .NET Framework 4.8: são o caso mais traiçoeiro, porque não têm data própria de fim de suporte — vivem enquanto o Windows que os hospeda viver. Sem prazo no calendário, o risco nunca entra na pauta da diretoria; e o mercado de gente disposta a trabalhar nisso encolhe todo ano.
O custo de mudança é o que mais dói no dia a dia. A pergunta que usamos para medi-lo é sempre a mesma: quanto tempo passa entre alguém pedir uma alteração simples de regra e ela estar em produção? Quando a resposta é "meses, porque ninguém tem coragem de tocar ali", o legado já está cobrando um imposto sobre toda a operação — só não há linha de orçamento com esse nome.
Antes da tecnologia, a estratégia: sete opções, não duas
A discussão típica se organiza em duas caixas — "mantém" ou "reescreve" — e é aí que ela trava. O Gartner descreve sete opções de modernização, ordenadas do menor para o maior impacto: encapsular, re-hospedar, replataformar, refatorar, rearquitetar, reconstruir e substituir.
O ponto que muda o projeto é este: num parque heterogêneo, a resposta não é uma só. Cada sistema recebe uma opção diferente, e é isso que torna o programa executável em vez de eterno.
Encapsular o que é estável
A DLL VB6 que calcula uma regra fiscal há quinze anos sem um único incidente não precisa ser reescrita agora. Precisa de uma API na frente, com contrato explícito, para deixar de ser um bloqueio arquitetural. Encapsular custa semanas e devolve liberdade ao resto do programa.
Substituir o que é periférico
Relatórios em ASP clássico raramente merecem reescrita fiel. Quase sempre a resposta é substituí-los por uma solução de BI ou por telas novas, aproveitando que ninguém defende a versão antiga.
Rearquitetar o que é núcleo
Os fluxos críticos em Oracle Forms — os que sustentam a operação e concentram regra de negócio — são os que justificam rearquitetura de verdade: domínio redesenhado, serviço em .NET Core, tela em Angular. É a parte cara do programa — e a única em que esse custo se paga.
Substituição por fatia: o velho e o novo convivendo
Nenhum hospital, indústria ou distribuidora aceita uma janela de parada para virada completa — e nem deveria. O padrão que resolve isso é o Strangler Fig: uma fachada na frente do sistema recebe as chamadas e decide, por rota, se elas vão para o legado ou para o serviço novo. A cada fatia migrada, mais tráfego passa pelo lado novo; o legado vai sendo estrangulado até sobrar nada.
É um padrão documentado tanto pela Microsoft quanto pela AWS, e é o que permite o cenário que na teoria parece impossível: o usuário atravessando uma jornada em que duas telas são Angular e a terceira ainda é Forms, sem perceber a fronteira. O preço é disciplina — a fachada precisa ser a única porta de entrada, e sessão, autenticação e auditoria precisam funcionar igual nos dois lados.
Por que Angular + .NET Core (e não "porque é moderno")
A escolha do destino merece critério, não moda. No caso desse parque, quatro razões pesaram — nessa ordem:
- O time já sabia C#. Havia módulos em .NET Framework, e ir para .NET Core é curva de aprendizado, não troca de carreira. Migrar para uma plataforma sem base interna alonga o projeto em meses invisíveis de aprendizado.
- Ciclo de suporte previsível. Versões LTS com data pública de início e fim permitem planejar atualização em vez de descobrir o fim do suporte pelo susto.
- Tipagem forte nos dois lados. Domínio de saúde tem regra pesada e alto custo de erro; TypeScript no Angular e C# no back deixam o compilador trabalhar antes do usuário.
- Mercado de profissionais. Contratar alguém para Angular e .NET Core em Porto Alegre ou remoto é um problema resolvido. Contratar para Oracle Forms não é — e cada ano piora.
Detalhamos o lado do back em .NET Core em sistemas corporativos.
Microsserviços: um prêmio que só vale se você puder pagar
Aqui a maioria dos textos sobre modernização erra: trata microsserviços como o destino natural de qualquer migração. Não são. Martin Fowler chama o custo dessa arquitetura de "microservice premium" — um imposto de produtividade que só se paga acima de um certo patamar de complexidade. Abaixo dele, você trocou um monolito difícil de mudar por um sistema distribuído difícil de entender.
O caso mais citado é o da Prime Video, que reduziu cerca de 90% do custo de infraestrutura de um componente ao recompactar um desenho distribuído em um processo único — sem, é importante dizer, abandonar microsserviços no resto da plataforma. A lição não é "microsserviço é ruim"; é que o recorte precisa ter motivo.
Nossa regra é recortar serviço por fronteira de domínio combinada com cadência de deploy: se dois conjuntos de regras mudam por motivos diferentes, em ritmos diferentes e sob responsáveis diferentes, valem serviços separados. Se mudam sempre juntos, separá-los só cria uma chamada de rede onde havia uma chamada de método. E há um pré-requisito não negociável: sem CI/CD, observabilidade e rastreamento distribuído já funcionando, microsserviço adianta problema em vez de resolver.
A ordem das fatias: como escolher a primeira
Definidos o padrão e o destino, sobra a pergunta que decide o cronograma. São quatro critérios, aplicados nessa ordem:
- Dor alta, acoplamento baixo. A primeira fatia precisa doer no usuário — para gerar apoio político — e ser pouco entrelaçada com o resto, para caber num prazo curto.
- O que destrava as outras. Autenticação, perfil de acesso e cadastros mestres não geram aplauso, mas toda fatia seguinte depende deles. Migrar isso cedo evita fazer duas vezes.
- Onde o prazo aperta. Se um componente depende de plataforma com fim de suporte datado, ele sobe na fila mesmo sem ser o mais dolorido.
- Nunca começar pelo que fatura. Faturamento, fechamento e folha são as últimas fatias. Quando você chegar nelas, a fachada, o pipeline e a equipe já estarão maduros.
O que medir para saber que está funcionando
Migração longa sem indicador vira questão de fé — e, depois de alguns meses, de desconfiança. Estes são os números que acompanhamos, e vale começar a medi-los antes da primeira linha de código nova, para haver linha de base:
Do pedido de mudança até a produção
Tráfego já atendido pelo lado novo da fachada
Quantas do legado ainda restam em uso real
A contagem de telas legadas ainda em uso é o indicador mais honesto do conjunto: ele impede a situação clássica em que o sistema novo está no ar, o antigo também, e ninguém desligou nada. Sobre o painel dos primeiros meses, escrevemos em Indicadores dos primeiros 90 dias.
Quatro erros que vimos custarem caro
- Migrar tela por tela sem redesenhar o domínio. Reproduzir a tela do Forms em Angular, campo por campo, entrega um legado novinho — com a mesma regra espalhada, agora em TypeScript.
- Deixar o banco compartilhado como acoplamento eterno. Legado e serviço novo escrevendo na mesma tabela é aceitável como fase de transição, com dono definido por entidade. Como arquitetura definitiva, é o que impede o legado de ser desligado.
- Congelar o legado. "Nada muda no sistema antigo até a migração terminar" parece disciplina e é a forma mais rápida de perder o patrocínio: o negócio não para de mudar durante os dois anos do projeto.
- Ir para microsserviços antes da esteira. Sem deploy automatizado, log centralizado e rastreamento, cada serviço novo é mais um lugar onde o erro se esconde.
Modernizar não é chegar a um stack — é recuperar a capacidade de mudar. O parque em Forms, VB6, ASP e .NET Framework não é um problema de linguagem; é o resultado de vinte anos em que cada mudança foi mais barata de contornar do que de arrumar. Se essa é a sua realidade, o diagnóstico costuma ser mais rápido e mais barato do que a discussão interna sobre trocar de sistema — e é por ele que começamos.