Migração de sistemas VB6 para .NET, web ou aplicativo.

O VB6 hoje: roda, mas parou no tempo

O Visual Basic 6 é de 1998. O suporte da Microsoft ao ambiente de desenvolvimento (o IDE) terminou em 2008. O runtime, que é o que faz o executável rodar, continua funcionando nas versões atuais do Windows por compatibilidade, na política que a Microsoft chama de "It Just Works". Funciona, mas não evolui: não há versão nova da linguagem, não há compilação para 64 bits e as ferramentas em volta envelhecem junto.

Também não existe "VB6 mais novo". O Visual Basic .NET é outra plataforma, com outro modelo de programação, e a própria Microsoft anunciou em 2020 que não pretende evoluir o Visual Basic como linguagem. Por isso, quando se fala em migrar VB6 para .NET, o destino natural hoje é C#.

Um sistema VB6 parado não é um problema enquanto nada muda em volta. O problema aparece quando muda: um Windows novo, um antivírus que bloqueia um componente, uma integração que o cliente exige, a saída do único programador que sabia compilar o projeto. É o mesmo dilema de qualquer migração de software legado, com as particularidades do VB6.

As dependências típicas de um sistema VB6

O código VB6 raramente é o que mais dá trabalho. O que pesa é o que ele carrega:

• OCX e ActiveX. Grids, calendários, controles de abas, o MSComm da porta serial, o Winsock, componentes comprados de fornecedores que já não existem. Cada um precisa ser registrado na máquina (regsvr32), e todos são de 32 bits.
• DAO e ADO. Acesso a dados por Recordset aberto direto na tela, com o SQL montado por concatenação de texto, às vezes em dezenas de lugares diferentes.
• Crystal Reports. Relatórios em arquivos .rpt de versões antigas, com fórmulas que guardam regra de negócio que não aparece em nenhum outro lugar.
• Access e SQL Server antigo. Bases .mdb pelo motor Jet, ou um SQL Server de versão antiga sem suporte, muitas vezes com usuário administrador na string de conexão.
• Chamadas à API do Windows. Declarações Declare para funções do sistema que funcionavam no Windows XP e hoje se comportam diferente, ou exigem rodar como administrador.

Uma migração VB6 séria começa por esse inventário: o que cada dependência faz, onde é usada e o que vai substituí-la.

Os riscos: segurança e contratação

Segurança. Controles ActiveX antigos tiveram vulnerabilidades sérias corrigidas ao longo dos anos, e componentes de terceiros sem fabricante não recebem correção nenhuma. Some a isso estações que precisam rodar com permissão de administrador para o sistema funcionar, senha de banco em arquivo .ini e SQL montado por concatenação, que abre espaço para injeção. Nada disso aparece até o dia em que aparece.

Contratação. Quem aprendeu VB6 na época está em outra função ou não quer voltar a ele, e quem está chegando ao mercado não aprende. Cada ano, manter o sistema depende de menos pessoas, e cada uma delas fica mais cara e mais difícil de substituir.

Por que assistentes de upgrade e conversores não resolvem

O Visual Studio .NET (2002 a 2008) trazia um assistente de upgrade de VB6 para VB.NET, removido a partir do Visual Studio 2010. Quem usou lembra do resultado: código cheio de avisos de "revisar manualmente", dependente de bibliotecas de compatibilidade, com os mesmos OCX embrulhados por interoperabilidade. Ferramentas comerciais de conversão para C# fazem um trabalho mais completo, mas o problema de fundo é o mesmo.

O conversor traduz a estrutura, e a estrutura é justamente o que precisa mudar. A regra continua no evento do botão, o Recordset continua aberto na tela, os relatórios do Crystal continuam sem destino. O resultado é um legado novo, numa linguagem nova, que ninguém escreveu e ninguém entende.

O método: entender, documentar, só então codificar

1. Entender. Lemos os formulários (.frm), módulos (.bas), classes, relatórios e o banco. Acompanhamos quem usa o sistema para separar o que é usado do que está morto. IA ajuda a ler mais rápido, descrevendo rotinas e mapeando quem chama quem, mas a validação é humana, com quem conhece o processo.
2. Documentar. Regras de negócio, fluxos, cálculos, fórmulas dos relatórios, integrações e modelo de dados, num documento que fica com a empresa. Mostramos como em como documentar um sistema legado sem documentação.
3. Codificar. Só então escrevemos o sistema novo em C#/.NET, com a regra num serviço com API, testes automatizados sobre os cálculos e interface separada. O roteiro técnico está em como migrar um sistema VB6.

A NasteSoft e seus parceiros já migraram bancos de dados e aplicações em Delphi, VB6 e .NET. Em todas essas migrações, o tempo gasto entendendo o sistema foi o que tornou a codificação previsível.

Para onde migrar um sistema VB6

Se o sistema VB6 trabalha sobre Access ou um SQL Server antigo, os dados migram junto, com limpeza e conferência, como descrevemos em migração de banco de dados. Se a empresa também tem sistemas em Delphi, a migração Delphi segue o mesmo método.

Migração VB6 incremental, sem parar a operação

Não trocamos o sistema numa noite. O novo assume uma parte por vez, ao lado do VB6, e cada etapa pode ser revertida. O VB6 ajuda nisso: ele consegue chamar uma API HTTP ou um componente .NET exposto via COM, então uma regra reescrita em C# pode passar a ser usada pelas telas antigas antes mesmo de a tela nova existir.

Imagine, como exemplo hipotético, uma indústria com um sistema VB6 de apontamento de produção ligado a balanças pela porta serial. A primeira etapa poderia ser levar o cálculo de rendimento para uma API em C#, chamada pelo próprio VB6. Depois, os relatórios do Crystal viram consultas na versão web. Por fim, a tela de apontamento ganha uma versão nova com um componente local para a balança, e o VB6 sai de cena sem que a produção pare.

O prazo depende do número de telas, das dependências de terceiros e do estado dos dados. Um sistema pequeno cabe em semanas; um sistema central da empresa é trabalho de meses, com entregas desde o início. Os fatores estão em quanto custa e quanto tempo leva migrar um sistema legado.

O que você recebe

• Inventário de dependências: cada OCX, biblioteca e relatório, com o que o substituiu.
• Documentação do sistema: regras de negócio, fluxos, cálculos e dicionário de dados.
• Sistema novo em C#/.NET, entregue por partes e validado em produção.
• API com a regra de negócio, pronta para web, aplicativo e integrações.
• Testes automatizados sobre os cálculos críticos.
• Dados migrados e conferidos, e repasse para a sua equipe manter sem depender de nós.

Perguntas frequentes