Hace unos días tenía que realizar una tarea de migración para una aplicación que estaba desarrollada con .net 2.0 como ya sabemos esta versión está un poco antigua por lo que se quería migrar a 6.0. aquí el primer reto que teníamos era que muchas de las cosas no fueran compatibles.
Vamos a ver que componentes teníamos en esta app
-
Identity Framework 2.0
-
Entity Framework
-
Una aplicación en MVC
-
Un Rest Service
-
Algunas librerías adicionales que fueron agregadas
-
Y la parte del frontend
Vamos a iniciar a ver cómo fue que trabajamos la migración. Para iniciar con el proceso simplemente se cambió la versión del proyecto de 2.0 a 6 esto se puede hacer en la propiedad graficas de Visual Studio o lo podemos editar en el archivo de la solución.
Con solo este cambio la aplicación inicio a dar muchos problemas teníamos errores en todos los componentes que se tenían, y se debieron de ir solucionando uno por uno.
A continuación, fue eliminar las referencias a frameworks viejos de 2.0 como los de identity y entity framework, entre otros. Después simplemente agregar las nuevas versiones de los diferentes dlls o componentes que teníamos. Esto nos ayudo a eliminar varios errores y poco a poco ir viendo mejor los proyectos.
Como hemos visto los proyectos web de 2.0 tienen dos clases que son el program.cs y el starup.cs aquí también toco ir haciendo ajustes para poder tener la compatibilidad de las nuevas referencias. Después de un rato de trabajar en estas dos clases se puede hacer que funcionen ajustando las nuevas versión o características. Sin embargo, preferí eliminar el startup.cs y además cambiar todo el program.cs para que funcionara como la nueva versión de 6.0 (usando la nueva estructura). Esto también ya que el identity framework me dio algunos problemas y fue mucho más sencillo eliminar la configuración que teníamos en 2.0 y cambiarlo a la configuración que se usa en 6.0.
La separación de funcionalidades o capas realmente es una muy buena práctica al tener separado mi lógica de negocio de la parte grafica fue mucho más sencillo ir cambiando las partes o componentes a 6.0. aquí es muy importante tener presente que la separación de componentes nos puede ayudar a migrar nuestras soluciones de manera más simple. Por ejemplo, si queremos hacer la migración un poco mas lento y seguro podemos migrar toda la parte de MVC sin tener que cambiar la lógica de negocios si existe en componentes REST.
Cuando fue a migrar el API que utiliza la solución tenía algunos problemas con el EF por lo que fue más fácil borrar todo el modelo complete y generar otro con la nueva forma de EF 6.0. En este caso las librerías que tenían la lógica de negocio no sufrieron grandes problemas con la migración al nuevo framework.
Realmente la migración fue muy fácil claro que toco hacer algunos cambios en algunos componentes y eliminar algunas referencies de nuget para agregar las nuevas, pero sin mucho contratiempo ya que al final fue muy simple y con pocos o ningún problema a la hora de cambiar las librerías.
Algunos puntos claves fue no usar un solo código o una solo solución si no separar mi solución en partes para ir migrando componente por componente sin ver grandes problemas. Incluso si todo esta separado se puede migrar una parte del sistema publicarlo, hacer pruebas y cuando estamos seguros de que funciona migrar otra parte o componente del sistema. Cada versión nueva de .netcore ofrece mejoras en rendimiento y optimización de la aplicación. Creo que es buena práctica actualizar las versiones usando la versión estable disponible y de esta manera usar las nuevas características del lenguaje.
