Solución:
Es evidente que se trata de una empresa importante que implicará mucho trabajo.
Así que mi consejo sería tratarlo como un proyecto a muy largo plazo.
Tenga un objetivo claro en mente, que aborde problemas importantes como la seguridad, la resistencia, la capacidad de mantenimiento y el futuro de sus aplicaciones.
Una vez que las partes interesadas hayan acordado esto, desarrolle un sistema prototipo para probar sus suposiciones, donde puede probar C # vs VB.net o MVC vs Webforms. Asignaría a sus mejores desarrolladores para esto.
Luego, comience con uno de sus pequeños sistemas heredados y cree los componentes principales que reutilizará en otras áreas.
En esta etapa, comience con sus desarrolladores más experimentados, pero todos deben involucrarse y estar familiarizados con el nuevo marco.
Esto asegurará que todos estén capacitados al mismo tiempo y que nadie se quede atrás.
Dependiendo de la cantidad de aplicaciones que tenga, rotaré a los desarrolladores, para que todos los sistemas puedan beneficiarse.
Además, todo el trabajo nuevo debe realizarse en su idioma .net, no en VB6.
Convierta gradualmente cada una de sus aplicaciones heredadas. (Solo los convertiría si están cambiando o si hay un beneficio claro de actualizarlos).
Esto debería brindarle un marco sólido para usar en el futuro, y al mismo tiempo garantizar que la funcionalidad de los usuarios no se vea obstaculizada por su migración.
Por ejemplo:
He trabajado en una empresa que tenía aproximadamente 40 aplicaciones de VB.
Con el tiempo, hemos migrado todos estos a C # y ahora (5 años después), tenemos aproximadamente 150 aplicaciones de c # (todas en .net 2.).
Todos ellos comparten un marco común, lo que los hace fáciles de mantener y ampliar cuando sea necesario.
Intente reemplazar la funcionalidad principal con bibliotecas .NET habilitadas para COM. “Ahueque” sus aplicaciones VB6 existentes moviendo la funcionalidad a .NET poco a poco.
Tenga cuidado con las reescrituras completas. Aunque son tentadores “porque es un corte limpio”, ¡por lo general la locura está por delante! Lea “Trabajar eficazmente con el código heredado” de Michael Feathers como preparación. Aunque el libro no trata específicamente de “pasar de un idioma a otro”, sí muestra muchas de las dificultades del mundo real que encontrará.
Creo que todos los desarrolladores deberían haber definido franjas horarias en las que realizan el trabajo de migración en las aplicaciones heredadas que desarrollaron antes. Dado que ya tienen conocimiento del dominio y conocen el espacio del problema, deberían ser los más productivos.
Aquí hay una adaptación de mi respuesta a una pregunta similar.
Convertir programas grandes automáticamente es una mejor opción que reescribir. Es un error común comenzar a reescribir con optimismo una gran pieza de software, hacer un buen progreso temprano para corregir algunas de las fallas conocidas en la arquitectura anterior y luego atascarse en la funcionalidad que acaba de dar por sentada. años. En este punto, su gestión comienza a ponerse nerviosa y todo puede volverse muy incómodo.
… y aquí hay una publicación de blog de un Microsofty que está de acuerdo conmigo:
Muchas empresas con las que trabajé en los primeros días de .NET primero miraron la reescritura impulsada en parte por un fuerte deseo de mejorar la arquitectura subyacente y las estructuras de código al mismo tiempo que pasaban a .NET. Desafortunadamente, muchos de esos proyectos tuvieron dificultades y varios nunca se completaron. El problema que estaban tratando de resolver era demasiado grande.
Esta excelente página de Microsoft recomienda dos herramientas de migración de terceros como mejores que el asistente de actualización VB.NET incorporado de poca potencia: Artinsoft y CodeArchitects VBMigration. Artinsoft escribió el asistente de actualización de VB.NET integrado, esta es su versión mejorada. Y CodeArchitects fue fundado por Francesco Balena, quien escribió algunos de los libros clásicos sobre VB6 y VB.NET.
La misma página de Microsoft también dice:
Realizar una reescritura completa en .NET es mucho más costoso y difícil de hacer bien [than converting] … solo recomendaríamos este enfoque para una pequeña cantidad de situaciones.
EDITAR: Sung dice en los comentarios: “No soy un gran fanático de la generación automática de código porque es más difícil de depurar inicialmente y puede tomar el tiempo necesario para reescribirlo todo”. Tengo que estar totalmente en desacuerdo. En general, yo tampoco soy un fanático de la generación de código, pero en este caso el código resultante estará estructurado de manera idéntica a su VB6 original y debería ser casi totalmente funcional. En realidad, todavía no he probado estas herramientas, pero a partir de los testimonios de sus clientes, esta promesa se ha cumplido.
Y repito el consejo de Microsoft anterior, basado en su experiencia de ayudar a muchas migraciones: “una reescritura completa es mucho más costoso y difícil que convertir [my emphasis]”- una contradicción plana de la suposición de que podría tomar el mismo tiempo. Si desea mejorar la estructura del VB6, la migración, entonces la refactorización gradual probablemente sea mucho más rentable que una reescritura.