Migração de sistemas Visual Basic para Java

Senhores, venho aqui novamente abrir uma discussão devido a um grande problema que estou (e tenho algumas conclusões), porém acredito que a unica resposta correta é que não podemos prever o futuro, então acho que pode ser gerada muita informação interessante a respeito do assunto.

Coordeno uma equipe de sistemas (equipe pequena de 8 pessoas em uma TI que tem 16 pessoas com Adm. de rede e Suporte) em uma empresa de porte médio (250 funcionários) que trabalho atualmente. Hoje temos quase 60 sistemas em diversas tecnologias diferentes (Java/VB.NET/C#/PHP/ASP/Visual Basic/Access/FoxPro/etc)… de um tempo para cá estamos enfrentando grandes desafios na construção de novos sistemas, visando otimização de processos, sustentabilidade, plataformas mais sólidas, reaproveitamento de componentes entre plataformas, etc… e adotamos a plataforma Java.

Entretanto, reconstruir tudo em Java, mesmo já tendo diversos resultados muito satisfatórios no que já construimos neste ultimo ano, levará muito tempo (estimamos que pelo menos 5 anos para tudo estar pronto), só que neste tempo a empresa não pode parar e tem que continuar investindo nos legados principais, sua maioria escrita em Visual Basic 6.

A dificuldade aqui é, até onde vale a pena investir nesses legados, visto que por VB6 ser uma tecnologia descontinuada, tem um grande risco continuar o utilizando. Um dos principais problemas seria impedir a atualização de um sistema operacional em virtude de uma tecnologia obsoleta. Ou apareceram bugs insoluveis em um futuro. Só que estamos falando de Visual Basic que ainda é amplamente usado.

Será que nos próximos 5 anos ainda será possivel utilizar Visual Basic, mesmo que de forma meio “capenga”, ou é preciso abortar a missão já e partir para investimento de aumento de equipe de forma a reduzir o tempo de construção dos novos sistemas. Sei que isso é previsão de futuro, mas é por isso que abro a discussão.

Achei um artigo muito interessante a respeito do assunto Visual Basic, e tudo indica que o Windows 8 ainda o suportará:
http://msdn.microsoft.com/pt-br/magazine/jj133828.aspx

Mnha opnião é que no momento atual, 5 anos é um bom tempo para a evolução dos sistemas na questão de investimento necessário e vejo como um risco pequeno manter o Visual Basic, não enxergando argumentos para os investidores colocarem mais dinheiro nesse momento e desligar o Visual Basic antes deste tempo. Isso embasado em uma séria de pesquisas e na minha própria experiência.

Sei que será um tópico polêmico mas acredito que possa agregar bastante.

O que acham ?

Polêmico por que?
É notória a necessidade de substituição de sistemas em tecnologias como foxpro, PHP 3 e 4, VB e java 1.4 para versões mais novas.
A primeira coisa que deve-se ter em mente é que a maioria destes sistemas pode ser incompatível com arquiteturas 64 bits. Isso já trará grandes problemas.
As demais você já citou. Bugs insolúveis é algo complicado, começa a necessidade de pogs e uma coisa leva a outra.
Enfim, por isso a tendência em sistemas web. É mais fácil manter, atualizar e compatilizar com novas arquiteturas e outros pormenores.

[quote=drsmachado]Polêmico por que?
É notória a necessidade de substituição de sistemas em tecnologias como foxpro, PHP 3 e 4, VB e java 1.4 para versões mais novas.
A primeira coisa que deve-se ter em mente é que a maioria destes sistemas pode ser incompatível com arquiteturas 64 bits. Isso já trará grandes problemas.
As demais você já citou. Bugs insolúveis é algo complicado, começa a necessidade de pogs e uma coisa leva a outra.
Enfim, por isso a tendência em sistemas web. É mais fácil manter, atualizar e compatilizar com novas arquiteturas e outros pormenores.[/quote]

Sim drsmachado… o detalhe aqui é… com a estrutura atual, fazer isso levará 5 anos!
Para fazer em menos tempo terei que aumentar a equipe e isso implica em investimentos, logo aumento de custo…
E explicar os motivos disso para investidores, porque ele tem de investir X para ter tudo isso em 2 anos ao inves de manter o quadro atual e ter em 5 anos é o grande X da questão!
Também não estamos falando de um banco onde sistemas são tão criticos assim para o negócio. Ter algumas máquinas com Windows XP (mesmo que o 8 não suporte alguns desses legados) não será problema, pelo menos em 5 anos.

A idéia aqui é pegar opnião do pessoal! Obrigado pela sua!

Amigo, todos temos que andar pra frente com certeza teremos empregos que valham muito pra quem trabalhe com visual basic 6, assim como temos algumas ofertas boas pra cobol atualmente.

Eu forço aqui na empresa ir pro java, pq é a tecnlogia que domino, quer uma dica? use a tecnolgia que tem mais membros na equipe que manjam…
a melhor tecnologia é a que você sabe mais.

abraço

[quote=rafaelgimenes]Amigo, todos temos que andar pra frente com certeza teremos empregos que valham muito pra quem trabalhe com visual basic 6, assim como temos algumas ofertas boas pra cobol atualmente.

Eu forço aqui na empresa ir pro java, pq é a tecnlogia que domino, quer uma dica? use a tecnolgia que tem mais membros na equipe que manjam…
a melhor tecnologia é a que você sabe mais.

abraço[/quote]

Então… a questão não é ir para o Java. Já fomos para o Java e já temos sistemas migrados e funcionando muito bem!

A duvida agora é, esperamos mais 5 anos para ter TUDO em Java ou JUSTIFICAMOS O INVESTIMENTO para ter TUDO em menos de 5 anos.

Aqui é o X da questão! Eu vejo que mais 5 anos não são problema para legados em Visual Basic mas queria compartilhar da experiência de outras pessoas.

Obrigado

Se bem entendi, vc já fizeram o mais dificil que é integrar as aplicações novas java com as velhas em outras tencologias.
5 anos para migrar para java é muito bom. Pelo menos vc estimou esse tempo, coisa que normalmente o pessoal esquece.

Dado isto não sei se entendi a dúvida.

O VB 6 vai morrer ? sim, obviamente. Sendo que o VB.NET o substituio. Não hoje, não amanhã, mas um dia. Nesse dia é bom que tenha o negocio em java.
Ou dito de outra forma, a longividade do java é maior. Mesmo que o vb não morra em 5 anos, é bom matá-lo o mais depressa possivel.
Vale a pena adicionar funcionalidade nos sistemas legados ? não. obviamente. Porque significa refazer a mesma coisas depois.

Então um plano seria identificar as funcionalidades dos sistemas legados e verificar se não ha coisa repetida ou que possa ser fundida.
Dado isto, começaria a construção de sistemas em java que substituiriam estes sistemas. Começando pelos de maior risco, ie. os que estiverem mais no core do negocio.
Isto para que dê tempo em 5 anos de testar bem e ter a certeza da solidez do novo sistema. Só que isto significa prever o futuro do java em 5 anos.
Em 5 anos estaremos em java 9 ( se tudo correr bem), mas pelo menos java 8 é garantido. Could será commodity e HTML 5 será o padrão (espero).

Vamos por exemplo supor que um dos sistemas vb é o cadastro de produto (/cliente, ou qq outra entidade central do negoico). O objetivo seria então prover um cadastro de produto em plataforma java (rodando em jvm) mas não necessáriamente escrito em java (a escolha da linguagem é um outro assunto à parte). Se vc escolher uma boa arquitetura flexivel, web/cloud based usando frameworks orientados a componentes como Vaadin / Wicket ou mesmo JSF ( tudo depende os tipos de cadastro que que a aplicação necessita ) vc poderia escrever uma ui em pouco tempo (1 mes ±) . migrar os serviços em si é mais complicado e teria que ver que tipo de arquittura é melhor (se ejb ou webservices com REST).

Por outro lado, 5 anos é um tempo razoável e é uma oportunidade para melhorar o parque de sistemas, não simplesmente migrar o que tem, mas evoluir o que tem.

Para mim se resume a um bom plano, bem compatimentado no tempo e nos objetivos com uma prioridade bem definida de qual sistema deve ser migrado primeiro.
Chegar daqui a 5 anos ainda dependendo do VB não é uma opçao legitima, eu acho.

[quote=sergiotaborda][quote=jmmenezes]
Sei que será um tópico polêmico mas acredito que possa agregar bastante.

O que acham ?

[/quote]

Se bem entendi, vc já fizeram o mais dificil que é integrar as aplicações novas java com as velhas em outras tencologias.
5 anos para migrar para java é muito bom. Pelo menos vc estimou esse tempo, coisa que normalmente o pessoal esquece.

Dado isto não sei se entendi a dúvida.

O VB 6 vai morrer ? sim, obviamente. Sendo que o VB.NET o substituio. Não hoje, não amanhã, mas um dia. Nesse dia é bom que tenha o negocio em java.
Ou dito de outra forma, a longividade do java é maior. Mesmo que o vb não morra em 5 anos, é bom matá-lo o mais depressa possivel.
Vale a pena adicionar funcionalidade nos sistemas legados ? não. obviamente. Porque significa refazer a mesma coisas depois.

Então um plano seria identificar as funcionalidades dos sistemas legados e verificar se não ha coisa repetida ou que possa ser fundida.
Dado isto, começaria a construção de sistemas em java que substituiriam estes sistemas. Começando pelos de maior risco, ie. os que estiverem mais no core do negocio.
Isto para que dê tempo em 5 anos de testar bem e ter a certeza da solidez do novo sistema. Só que isto significa prever o futuro do java em 5 anos.
Em 5 anos estaremos em java 9 ( se tudo correr bem), mas pelo menos java 8 é garantido. Could será commodity e HTML 5 será o padrão (espero).

Vamos por exemplo supor que um dos sistemas vb é o cadastro de produto (/cliente, ou qq outra entidade central do negoico). O objetivo seria então prover um cadastro de produto em plataforma java (rodando em jvm) mas não necessáriamente escrito em java (a escolha da linguagem é um outro assunto à parte). Se vc escolher uma boa arquitetura flexivel, web/cloud based usando frameworks orientados a componentes como Vaadin / Wicket ou mesmo JSF ( tudo depende os tipos de cadastro que que a aplicação necessita ) vc poderia escrever uma ui em pouco tempo (1 mes ±) . migrar os serviços em si é mais complicado e teria que ver que tipo de arquittura é melhor (se ejb ou webservices com REST).

Por outro lado, 5 anos é um tempo razoável e é uma oportunidade para melhorar o parque de sistemas, não simplesmente migrar o que tem, mas evoluir o que tem.

Para mim se resume a um bom plano, bem compatimentado no tempo e nos objetivos com uma prioridade bem definida de qual sistema deve ser migrado primeiro.
Chegar daqui a 5 anos ainda dependendo do VB não é uma opçao legitima, eu acho.
[/quote]

Legal sua visão Sérgio… compartilho da mesma em muita coisa e acho que 5 anos é um bom tempo… o ideal é o quanto antes mas não consigo justificar o investimento de aumento de equipe nesse momento para reduzir esse tempo de 5 anos.

Já em relação do que usar, algumas coisas estão indo para Web, outras estão ficando em desktop, por serem meio pesadas e web não ter respondido bem (estamos usando SWT), mas acredito que no meio do caminho com HTML5 e novas consolidações algumas estratégias mudem e o que construimos no ultimo ano se torne legado (estamos no Java 6 em planos de mudar para o 7). Mas acho que isso faz parte. Acho meio impossível quando se tem muito sistema, manter tudo sempre com a tecnologia da ultima moda!

Só acho que daqui 5 anos, ai sim ter muita coisa em Visual Basic 6 se tornará uma verdadeira dor de cabeça, que hoje ainda esta começando… ou será que isso vai acontecer antes??? Essa é a verdadeira duvida…
Já ouvi também opniões que visual basic durará ainda 20 anos e isso não é um problema e valeria a pena manter os legados!

Isto é um pouco mito. Primeiro é diferente migrar o ambiente de desenvolvimento do que o de produção. Migrar para java 7 é meio pointless em dev, mas poderia aumentar a performance em prod. O problema é que o java 7 tem alguns problemas em classes publicas que foram modificadas e isso significa que migrar o prod significa migrar o dev. Então eu esperaria para o java 8 e migraria ambos.

O meu ponto era realmente sobre a estratégia , se já tem algo swt voltar para hml 5 pode não justificar o custo, mas quanto mais estiver em swt, pode diminuir o custo.

Pelo que entendi vc não tem equipe para fazer a migração e não consegue justificar o investimento, mas eu acho que isso é por falta de um plano da empresa. Pelo que entendi, neste estágio o plano é seu. Se a empresa entender que vai poupar também (porque os skills da equipe não precisam ser tão diversos o que melhora a comunicação e padronização) vc pode contrabalançar. Ou seja, precisa acompanhar o plano tecnologico com um plano financeiro migrado primeiro quem dá mais risco e mais custo de manutenção. Sobretudo entender porque o custo é tão alto. Por outro lado , ainda, parar de investir em criar funcionalidade nos legados. Isto eu acho vital para parar de aumentar o problema.

É claro que uma equipe maior/melhor faria em menos tempo, mas também se liberar a qu já tem de tarefas improdutivas pode abrir espaço para com a mesma equipe já criar modificações.

Acho que entendi. Qual o periodo de tempo minimo até que o VB seja problema/risco. Eu acho que é assim que vc precisa modificar o legado.
Sendo que já o modificou para encaixar com outros sistemas, o tempo minimo já passou. Qual o periodo para o VB deixar de ser suportado pela MS ? acho que já passou também. O VB ainda funciona mas isso não significa que ha updates e patches de problemas. O VB3 funcionada no windows 95, mas não era um bom match.
Particularmente eu acho que já entrou no periodo em que o VB é problema.
Aqui é um trade-off. Vc sabe que o barco vai afundar. não sabe quando. isso significa que deve permancer no barco ? não. Se vc sabe que vai afundar é melhor sair e migrar para outro o quanto antes. O quanto mais cedo migrar mais barato fica.
A ideia seria tentar mostrar com numeros que se migrar em 1 ano economiza X em 5 anos, se migrar em 2 anos ecnomiza Y em 5 anos ,etc… se migrar em 5 anos ecnomiza zero. Veja que o investimento para migrar em 1 ano pode ser balanceado pelo custo de manter o VB durante 5 anos e no frigir dos ovos compensar.
Mas apenas vc poderá fazer estas contas. Acho que apenas o custo não será suficiente, vc terá que entrar com o risco.

Legados são legados e legado sempre são problema, olhe-se como se olhar.
Manter é possivel, mas isso singifica não mudar nada de nada. Ou seja, tenho os exe, mas não mexo no código. A partir do momento que precisa mexer no código é hora de pensar em evoluir.

[quote=sergiotaborda][quote=jmmenezes]
Já em relação do que usar, algumas coisas estão indo para Web, outras estão ficando em desktop, por serem meio pesadas e web não ter respondido bem (estamos usando SWT), mas acredito que no meio do caminho com HTML5 e novas consolidações algumas estratégias mudem e o que construimos no ultimo ano se torne legado (estamos no Java 6 em planos de mudar para o 7). Mas acho que isso faz parte. Acho meio impossível quando se tem muito sistema, manter tudo sempre com a tecnologia da ultima moda!
[/quote]

Isto é um pouco mito. Primeiro é diferente migrar o ambiente de desenvolvimento do que o de produção. Migrar para java 7 é meio pointless em dev, mas poderia aumentar a performance em prod. O problema é que o java 7 tem alguns problemas em classes publicas que foram modificadas e isso significa que migrar o prod significa migrar o dev. Então eu esperaria para o java 8 e migraria ambos.

O meu ponto era realmente sobre a estratégia , se já tem algo swt voltar para hml 5 pode não justificar o custo, mas quanto mais estiver em swt, pode diminuir o custo.

Pelo que entendi vc não tem equipe para fazer a migração e não consegue justificar o investimento, mas eu acho que isso é por falta de um plano da empresa. Pelo que entendi, neste estágio o plano é seu. Se a empresa entender que vai poupar também (porque os skills da equipe não precisam ser tão diversos o que melhora a comunicação e padronização) vc pode contrabalançar. Ou seja, precisa acompanhar o plano tecnologico com um plano financeiro migrado primeiro quem dá mais risco e mais custo de manutenção. Sobretudo entender porque o custo é tão alto. Por outro lado , ainda, parar de investir em criar funcionalidade nos legados. Isto eu acho vital para parar de aumentar o problema.

É claro que uma equipe maior/melhor faria em menos tempo, mas também se liberar a qu já tem de tarefas improdutivas pode abrir espaço para com a mesma equipe já criar modificações.

Acho que entendi. Qual o periodo de tempo minimo até que o VB seja problema/risco. Eu acho que é assim que vc precisa modificar o legado.
Sendo que já o modificou para encaixar com outros sistemas, o tempo minimo já passou. Qual o periodo para o VB deixar de ser suportado pela MS ? acho que já passou também. O VB ainda funciona mas isso não significa que ha updates e patches de problemas. O VB3 funcionada no windows 95, mas não era um bom match.
Particularmente eu acho que já entrou no periodo em que o VB é problema.
Aqui é um trade-off. Vc sabe que o barco vai afundar. não sabe quando. isso significa que deve permancer no barco ? não. Se vc sabe que vai afundar é melhor sair e migrar para outro o quanto antes. O quanto mais cedo migrar mais barato fica.
A ideia seria tentar mostrar com numeros que se migrar em 1 ano economiza X em 5 anos, se migrar em 2 anos ecnomiza Y em 5 anos ,etc… se migrar em 5 anos ecnomiza zero. Veja que o investimento para migrar em 1 ano pode ser balanceado pelo custo de manter o VB durante 5 anos e no frigir dos ovos compensar.
Mas apenas vc poderá fazer estas contas. Acho que apenas o custo não será suficiente, vc terá que entrar com o risco.

Legados são legados e legado sempre são problema, olhe-se como se olhar.
Manter é possivel, mas isso singifica não mudar nada de nada. Ou seja, tenho os exe, mas não mexo no código. A partir do momento que precisa mexer no código é hora de pensar em evoluir.
[/quote]

Realmente VB já eras… Agora só falta o barco afundar… rs rs rs

OK… estou trabalhando neste estudo que você citou pois a equipe que tenho hoje faz em 5 anos mantendo o legado e focando pessoas em Java (atualmente tenho programadores Java e VB). Estou tentando neste estudo achar argumentos que justifiquem este investimento, realmente nessa linha que você falou de economizar desligando o VB antes. Acho que o ponto chave aqui é produtividade dos processos e equipe de manutenção do legado em VB… a tecnologia por si só já justifica, mas só olhando pela tecnologia não consigo encontrar argumentos que justifiquem investir para ter tudo em menos de 5 anos (o detalhe aqui é esta funcionando male-male que continue por mais um tempo). A questão aqui é que eu acho que o barco aguenta mais 5 anos aos trancos e barrancos… entretanto estou tentando enxergar estes beneficios de produtividade, para fazer antes.

Uma saída sem necessitar novos investimentos talvez seja treinar programadores VB em Java ou até mesmo troca-los… e chegar em um meio termo (talvez 3 anos) com um investimento menor!

Vou mudar um pouco a questão então…

Sei que isso é previsão de futuro, mas em sua opnião, quando será que o VB vai mesmo parar de funcionar… Quando acha que o barco afunda???
Acho que um misto disto, risco da tecnologia X tempo + beneficio de produtividade + custo de manter legado será um estudo suficiente para tentar um investimento para fazer este projeto em menos tempo!

Consultando sobre o assunto, a estratégia de MS é clara. 10 anos de suporte a partir de 1998. ou seja, até 2008. Mas o mesmo documento fala de uma revisão em 2004 desta politica. O texto que vc citou fala em 24 anos a conta de 1998 , portanto 2022. 2022 seria então o máximo possivel.
(faltam 10 anos). COnsiderando que não ha mais suporte ao IDE e apenas ao runtime, ou seja, o que foi feito roda, mas não ha como fazer nada novo, o barco , tecnicamente já afundou. A MS só está dando suporte a retirar os seus pertences de dentro do barco…

Por outro lado, no texto que vc citou “O Visual Basic 6 fez o que seus criadores pretendiam para seu nicho de mercado: permitir todo desenvolvimento rápido de programas limitados por programadores com menor experiência. Nunca foi pensado para codificadores robustos que desenvolvem aplicativos complexos.”

Este era o sentimento que eu tinha com o VB na epoca que mexi com ele. E veja, nessa época era um hobbie , não uma profissão. Quando eu quiz me profissionalizar em dev fui para o java, exactamente porque eu queria ter opção de criar sistemas complexos.

O custo de um programador VB tende a aumentar mais que java porque existirão menos. Por outro lado a qualificação de um programador VB é menor (porque dá para se livrar fácil fazendo gamb.) . então temos o famosos custos total de propriedade (Total Cost of Ownership) que a MS tanto gosta. Vc tem que usar windows, logo tem que pagar a licença. Não pode migrar para linux. Não tem servidor centralizado, a centralização é no servidor de SGDB.

É realmente por numeros nisto, primeiro porque para mim é obvio que VB6 já morreu ha muito tempo mas por outro lado na ponta do lapis e olhando apenas custo, ainda parece competitivo. A porta aberta é o risco. O risco é com certeza maior, mas como quantificá-lo? apenas com dados reais como o numero de horas passadas sanando problemas em VB vs java. Outra opão é o custo de oportunidade onde se compara o custo atual no cenário atual com o cenário java puro. Por exemplo, se elimar o vb significa elimar as pessoas que trabalham com vb o cenário é muito positivo para ir para o java mais rápido, mas não se tiver que ter a mesma equipe para o java (sendo cada membro mais caro que em vb). Ou o custo de operotunidade de migrar agora vs migra daqui a X anos vs o tempo para migrar. É realmente difícil por na ponta do lápis tudo o que - instintivamente -sabemos que é errado nesse cenário.
Vamos ver se mais alguem tem uma ideia.

[quote=sergiotaborda][quote=jmmenezes]
Vou mudar um pouco a questão então…

Sei que isso é previsão de futuro, mas em sua opnião, quando será que o VB vai mesmo parar de funcionar… Quando acha que o barco afunda???
Acho que um misto disto, risco da tecnologia X tempo + beneficio de produtividade + custo de manter legado será um estudo suficiente para tentar um investimento para fazer este projeto em menos tempo!
[/quote]

Consultando sobre o assunto, a estratégia de MS é clara. 10 anos de suporte a partir de 1998. ou seja, até 2008. Mas o mesmo documento fala de uma revisão em 2004 desta politica. O texto que vc citou fala em 24 anos a conta de 1998 , portanto 2022. 2022 seria então o máximo possivel.
(faltam 10 anos). COnsiderando que não ha mais suporte ao IDE e apenas ao runtime, ou seja, o que foi feito roda, mas não ha como fazer nada novo, o barco , tecnicamente já afundou. A MS só está dando suporte a retirar os seus pertences de dentro do barco…

Por outro lado, no texto que vc citou “O Visual Basic 6 fez o que seus criadores pretendiam para seu nicho de mercado: permitir todo desenvolvimento rápido de programas limitados por programadores com menor experiência. Nunca foi pensado para codificadores robustos que desenvolvem aplicativos complexos.”

Este era o sentimento que eu tinha com o VB na epoca que mexi com ele. E veja, nessa época era um hobbie , não uma profissão. Quando eu quiz me profissionalizar em dev fui para o java, exactamente porque eu queria ter opção de criar sistemas complexos.

O custo de um programador VB tende a aumentar mais que java porque existirão menos. Por outro lado a qualificação de um programador VB é menor (porque dá para se livrar fácil fazendo gamb.) . então temos o famosos custos total de propriedade (Total Cost of Ownership) que a MS tanto gosta. Vc tem que usar windows, logo tem que pagar a licença. Não pode migrar para linux. Não tem servidor centralizado, a centralização é no servidor de SGDB.

É realmente por numeros nisto, primeiro porque para mim é obvio que VB6 já morreu ha muito tempo mas por outro lado na ponta do lapis e olhando apenas custo, ainda parece competitivo. A porta aberta é o risco. O risco é com certeza maior, mas como quantificá-lo? apenas com dados reais como o numero de horas passadas sanando problemas em VB vs java. Outra opão é o custo de oportunidade onde se compara o custo atual no cenário atual com o cenário java puro. Por exemplo, se elimar o vb significa elimar as pessoas que trabalham com vb o cenário é muito positivo para ir para o java mais rápido, mas não se tiver que ter a mesma equipe para o java (sendo cada membro mais caro que em vb). Ou o custo de operotunidade de migrar agora vs migra daqui a X anos vs o tempo para migrar. É realmente difícil por na ponta do lápis tudo o que - instintivamente -sabemos que é errado nesse cenário.
Vamos ver se mais alguem tem uma ideia.

[/quote]

Muito obrigado!!!

Esses ultimos dias parece até que virei programador VB… de tanto que to fuçando nesses legados e montando um projeto para tentar mensurar tudo isso ai!!!

A questão do custo do profissional pesa muito também… e hoje profissional VB é mais barato que profissional Java!