La compleja toma de decisiones sobre la migración desde Visual Basic 6.0 a .NET (I)
Continuando con las entradas que le estoy dedicando al camino de migración y paso de Visual Basic 6.0 a .NET, ahora le toca el turno a la toma de decisiones y los costes derivados relacionados con la migración.
Si digo de la migración desde Visual Basic 6.0 a .NET que es la gran mentira, seguro que a más de uno casi se le saldrán los ojos de sus órbitas o al menos dará un pequeño sobresalto sobre su silla, y casi con total probabilidad, necesitará leer esta frase más de dos veces para ver que he escrito lo que de un primer plumazo ha entendido perfectamente. Una afirmación un poco dura, sí, lo sé, pero no por ello exenta de sinceridad… aunque a veces la realidad puede dejar en mal lugar mi afirmación, pero solo… a veces.
Así que me atrevo a preguntar, ¿alguien conoce una migración perfecta de una versión de un producto a otro?. Y digo perfecta cuando lo que pretendo es que el sistema haga todo el proceso de migración por mí, y una vez finalice yo no tenga que hacer ninguna acción más. Obviando las migraciones sencillas, seguramente no conozca ninguna o casi ninguna. ¿Y si la migración obedece a pasar el programa de una versión a otra teniendo en cuenta que la nueva versión posee cambios mayores?. Probablemente prácticamente ninguna.
Ese es justamente el caso de Visual Basic para .NET, un producto que sigue teniendo el mismo nombre que su antecesor, es decir, Visual Basic, y que ha sido reconstruido desde cero. Sin embargo, Visual Basic para .NET tiene muchísimas similitudes con Visual Basic 6.0, al menos en cuanto a nomenclatura y formas de trabajar, ¿porqué?, pues simplemente para hacer que los desarrolladores de Visual Basic 6.0 puedan dar el paso a .NET de una forma menos traumática y directa. Aún y así, algunos cambios y modificaciones de Visual Basic para .NET son destacables de cara al desarrollador de Visual Basic 6.0, y muchos de éstos hacen que aún haya desarrolladores de Visual Basic 6.0 que tengan temores a la hora de dar el paso definitivo, algo que me parece lógico por el desconocimiento existente.
Pero que nadie se asuste más de la cuenta. La migración de aplicaciones de Visual Basic 6.0 a .NET es una tarea más engorrosa que práctica. Así de claro. El único problema es reconocer cual es nuestro punto de partida, y sobre todo, saber que hacer.
Por lo tanto, la primera pregunta que se hace cualquier empresa o desarrollador al trabajar con Visual Basic 6.0 y querer pasar a .NET su programa, es: “¿Es posible migrar una aplicación de Visual Basic 6.0 a .NET?”. La respuesta ante esta pregunta es: “Sí, pero con peros”. Entonces, si antes decía de la migración que era la gran mentira y ahora digo que sí pero con peros,… ¿en qué quedamos, es mentira o no lo es?. ¿Es realmente posible migrar una aplicación de Visual Basic 6.0 a .NET o ni siquiera debemos intentarlo?.
Es posible que nuestro cambio hacia .NET esté motivado por diferentes factores entre los que podemos enumerar la moda, la necesidad o la imagen de la compañía.
El hecho de migrar una aplicación de Visual Basic 6.0 a .NET repercute en unos gastos directos e indirectos que debemos conocer. Cada aplicación de Visual Basic 6.0 es diferente. La amortización de la aplicación también. Y el propósito con el cual fue concebida una determinada aplicación también difiere desde el momento en el que se tomó la decisión de hacerla hasta el momento en el que decidimos valorar estos hechos de acuerdo a la posible migración.
En muchos más casos de los que mucha gente cree, el coste de una migración será más elevado que el hecho de rehacer la aplicación partiendo de cero.
Una migración no es nada más que el proceso de convertir la aplicación de una versión anterior a otra versión más actual. Esa conversión la podemos hacer manualmente o automáticamente, aunque el proceso automático no implica que haga los cambios como deseamos ni que realice todos los cambios de forma directa. Una conversión manual tiene la ventaja de que somos nosotros los que decidimos qué queremos hacer y cómo queremos hacer las cosas, pero el trabajo puede ser largo y duro. Un proceso automático o semiautomático, nos ahorra tiempo a costa de realizar una migración que no vemos hasta llegar al resultado final, por lo que en ese mecanismo de migración, podríamos obtener resultados no esperados inicialmente, bien porque no nos gusta como ha migrado el sistema alguna parte o por la razón que sea.
Pero si la decisión de migrar es únicamente pasar la aplicación de Visual Basic 6.0 a .NET, entonces podremos decir a un 99% (no digo 100% para no parecer presuntuoso) que no merece la pena llevar a cabo dicha migración. “¿Para qué tocar algo que ya funciona?. La regla de oro es, déjalo como está que así funciona”.
Si la decisión de migrar es pasar la aplicación de Visual Basic 6.0 a .NET y dotar a la nueva aplicación de nuevas características, entonces deberemos valorar si existen mecanismos o funcionalidades que nos faciliten el desarrollo de esas nuevas características con Visual Basic 6.0, ya que podemos enfrentarnos a grandes costes sin necesidad. Así, por ejemplo, Microsoft ha agregado algunos componentes gratuitos para incrustar en una aplicación de Visual Basic 6.0, un formulario con una funcionalidad desarrollada en Visual Basic para .NET. Pero si por otro lado, los nuevos cambios están justificados de manera tal que no hay más remedio que pasar a .NET toda la funcionalidad, entonces nos encontramos en la tesitura de si migrar toda la aplicación o desarrollar la aplicación partiendo de cero.
7 Responsesso far
De acuerdo en todo. En mi compañía tenemos 2 millones de líneas de código fuente en VB6. De momento elegimos la alternativa que explicas en tu último parrafo «Interops». Con ella hemos dotado a las aplicaciones de una imagen nueva, «con aires de .NET» que de cara al usuario parece la presentación en sociedad de una joven y bella dama, pero que no es ni más ni menos que una señora que ha pasado por un buen cirujano plástico. De momento paramos el golpe, y nos planteamos ir migrando poco a poco con híbridos, como se hizo con windows 11 a windows 95, es que no queda más remedio!!!!!!!
de nuevo otro AMEN!!!
pero creo que muchas veces los que pecamos aqui somos los evangelistas de tecnologias .net ( y no me refiero a los empleados MS corp), ya que muchas veces presionamos de forma indirecta o directa a la gente a «migrar», ya sea de SO, lenguaje, versiones, etc; todo esto sin pensar si vale la pena el costo/beneficio, por mas que sea de vb 2005 a vb 2008, o de vb 5 a vb 2008, hay que ver si realmente se necesita el cambio.
es muy facil decir » migra, actualizate», me a tocado algunas migraciones, muy tediosas, por el puro capicho de tenerlo » en .net», cuando las aplicaciones funcionaban perfectamente.
Salu2
Ddaz
Hola Jorge,
me parece interesante tu apreciación, pero estoy seguro de hay casos en los que. mas que moda, existe una presión por realizar tal migración.
Sobretodo cuando la premisa principal es «que haga lo mismo, pero en .net», alli si que comenzamos con el problema de la migración.
El cual queda resuelto en parte (a mi parecer) por el cambio de fachada (inicialmente) y luego la evaluacion de la continuidad de tal migración. Aqui ya saltan muchos factores, que van de la mano con la criticidad de la aplicación afectada.
En ese punto si que hay un (gran) problema, pues muchos caen en la cuenta de que migrar es copiar, pegar y acomodar orientando a objetos, cuando lo mas importante es, o conocer el proceso/funcionalidad a migrar, o tener a la mano la documentación que permita menos riesgos al momento de hacer los cambios.
Es por ello que muchas veces sale tan costoso como hacer la construcción desde cero.
Por mi parte no me gusta la herramienta de migración, quizá estoy siendo algo mezquino al respecto (lo sé), pero hice varias pruebas hace un tiempo y lo que preferí en ese momento fue descomponer hasta lo mas que pude y desde allí plantear la migración.
De por si, es interesante este tema, no?
Un Saludo.
Toy deacuerdo…. todo a su tiempo esperemos que todos los componentes queden funcionando con las evoluciones de los Sistemas operativos (ese es un Gran problema)
[Ref.: La compleja toma de decisiones sobre la migración desde Visual Basic 6.0 a .NET (I) ] Quiero ante
A nosotros nos ocurrió algo parecido, pero optamos al final por otra solución. Teníamos un desarrollo de más de 1 millón de líneas, fue un desastre la migración y el tiempo que perdimos en adaptar el código, tras casi 3 meses de continuas reuniones, discusiones , puestas a punto, búsqueda de soluciones y adaptabilidad se optó por un desarrollo híbrido, en el cual convivieran las 2 versiones, mientras en paralelo se desarrollaba el nuevo entorno. Tardamos algo más de 7 meses las personas que formábamos el departamento.
Buenas, a todos; aunque el comentario esta de acuerdo a lo expresado por la opiniones expresadas, casi todos estan de acuerdo en lo argumentado por Jorge. En mi particular punto de vista creo que Microsoft se equivoco, primero en el nombre Visual basic, no importa la justificación que se busco, el nombre del lenguaje y plataforma debería haber sido otro. He conversado con muchos programdores de VB 6.0 y el comentario es el mismo, hay que partir de cero, muchos estabamos a costumbrado a abrir una base de datos a lo mas con 3 lineas, resulta que ahora ademas de las que se necesitan aparecen otras que el mismo Net agrega por lo de la POO. Nos acostumbraron a no ver tanto codigo y el que se veia era el que nosotros escribiamos, llamenlo como quieran, comodidad, flojera, etc. Segundo la inseguridad de ver cosas que uno no entiende y cuando se desea aprender la informacion no es suficiente, estuve en la pagina de http://www.desarrollaconmsdn.com/msdn/ en la cual se explica como crear una Tienda de Video, muy buen tutorial, pero en algunas partes el desarrollador lo esta programando en C#, señores nos contrataron por Visual basic, entonces tenemos que aprender C# y .Net. Lo que quiero decir es que deberían haber mantenido la programación mejorada eso si en Visual Basic y la POO dejarla altenativa, aunque en VB6 no tenia POO, digamos las cosas como son, pero los objetos que teniamos eran mas que suficiente para desarrollar excelentes aplicaciones y para algunos que no saben hay tambien aplicaciones Cliente/servidor. A VB6.0 le hacia falta talvez mas objetos, mas comunicación con internet, etc. En resumen para los programadores de VB 6.0 ha sido dificil sobre todo los que deasrrollamos para empresas Pymes, las grandes tienen recursos. de un 100% de desarrolladores dejaron fuera al 80%. Tenemos 2 caminos comprar el nuevo y estudiar todo de cero y emprezar a comprar libros, ver tutoriales, etc. O mantenernos y con las herramientas que tenemos en VB 6.0 demostrarles a Microsoft que se equivocaron, yo llevo 1 año intentando hacer una simple aplicacion y tengo Visual Basic 2005 standart ya salio en Vb 2008. Ojalá se acuerden de nosotros, por lo menos que la ayuda sea mas clara, entre tambien a http://msdn.microsoft.com/es-es/vbasic/bb466226(en-us).aspx How Do I, excelente, al ver esto cualquiera quiere aprender VB .net. pero se topa con cosas nuevas, y no hay documentacion clara…es mi opinion personal y de una gran cantidad de desarrolladores de mi ciudad.