Blog
Como realizar una migración exitosa de MAGENTO 1 a MAGENTO 2 parte 1
Introducción
Magento 2 ha llegado para revolucionar muchas de las características que se encontraban en su anterior versión Magento 1 así como de implementar nuevas mejoras que ya se podían lograr en la versión 1.x el problema podría estar en que debían realizarse alguna serie de pasos incluso algunos hasta complejos para lograr los resultados esperados.
Desde mi punto de vista la gente de Magento y en especial sus arquitectos de software llegaron a la conclusión de que realizar una simple actualización o cambio en la modalidad de implementación no eran suficientes para lograr con su acometido que era seguir Manteniendo a Magento en la cúspide de la mejor plataforma de ecommerce en el mercado, y si realmente querían conseguirlo debían considerar revolucionar su arquitectura interna la forma en como estaba implementado el CORE y más aún la forma y métrica que debería logar el implementador y desarrollador que expandiera su plataforma.
Magento 1.x no es que fuera tan malo el problema está en que lo malo era dejarlo como se encontraba fácil de viciar, dejar la responsabilidad del lado de los implementadores y desarrolladores es algo no muy recomendable, Magento creyó que para nosotros los desarrolladores repasar una y otra vez los pasos para conseguir para lograr terne una tienda en las mejores condiciones era siguiente sus instrucciones al pie de la letra sin importar que podríamos evitarnos pasos, dejar de hacerlo como debería ser o incluso inventar nuestras propias formas de implementación, esto al final del día terminan en un proyecto que más valía no tocar alguna otra cosa más porque se hacía un enorme caos.
Magento 2 evoluciono desde dentro
Rediseñar la arquitectura, la metodología y mejor aún las formas más sofisticada de implementación incluyendo integrar lo mejor de lo mejor dotando a Magento 2 de un FullStack de punta, se ha logrado el mejor de los resultados consiguiendo que Magento siga siendo el Rey de las plataformas de comercio electrónico y es que al día de hoy no conozco una herramienta que lo contenga todo lo que un sistema de comercio electrónico deba tener.
Iniciemos con la Migración
Vamos a ponernos ya manos a la obra y comencemos por lo primero que es lo que necesitamos saber para migrar una tienda que está creada en Magento 1 a una tienda en Magento 2, aprovecho para comentar que en algún momento realice un artículo donde comente que no existía ninguna herramienta mágica que podría lograrlo por nosotros hacer eso que en texto teórico parece tener lógica ¡Migrar un producto 1 a un producto 2 del mismo proveedor! , pero cuando entiendes que el producto 1 no es el mismo que el producto 2 aun que le han llamado de la misma formas es un producto 2 revolucionario aun que han partido de muchas de las bases de Magento 1 es por ello que podemos aligerar un poco la carga y la gente de Magento aporto su granito de arena para conseguir tal resultado y esa herramienta que nos permitirá obtener los datos más relevantes de la base de datos de una instalación de Magento 1 y poder llevarlos a una base de datos de una instalación limpia de Magento 2 ya es una ayuda significativa el resto lo realizaremos de forma manual.
Preparando la receta de migración
Vamos a empezar definiendo tres conceptos que utilizo para simplificar la migración y hacerlo más sencillo de lo que parece si conseguimos realizar estos tres pasos la migración será un éxito:
- Revisión de la tienda actual
- Realizar un plan de migración
- Utilizar la herramienta de migración de datos de MAGENTO
Claro está que cada punto lo describiré a detalle y de ser posible lo desglosare en conceptos únicos para un mayor entendimiento.
Revisión de la tienda actual
Este punto es importante ya que lo que lo primero que hay que valorar es el estado actual de una tienda productiva creada con Magento 1 y de aquí dependerán muchas cuestiones técnicas como el tiempo de migración y la complejidad.
Cabe mencionar que de este concepto voy a desglosar un punto en específico y es la Auditoria de Código.
Auditoria de Código
Este punto lo llevara a cabo el arquitecto de software, el líder técnico u aquella persona especialista en Magento tanto en 1 como en la versión 2 ya que es prácticamente el que podría saber el estado actual de una tienda antes de ser migrada.
La auditoría de código es prácticamente revisar una serie de aspectos de la tienda a migrar y saber si estas son viables o requerirán trabajo por parte del equipo de desarrolladores asignado para la tarea de migración.
La idea general es conseguir tener una actual tienda de Magento 1 que sea lo más estable posible y que soporte a sí misma una actualización a la última versión disponible, es decir si tenemos una tienda en Magento 1.8 que podamos realizar un upgrade o actualización exitosa a la versión 1.9 ya que esto nos pone en un panorama de una tienda estable.
Para que la auditoria de código sea exitosa voy a dejar una lista de acciones que realizar para conseguir este fin:
- Revisión del CORE de Magento en óptimas condiciones
- Revisión de plantillas limpias sin lógica de negocio integrada
- Revisión de extensiones de terceros
- Revisión de extensiones personalizadas
- Revisión de extensiones sin utilizar
- Revisión de todo el JavaScript personalizado
- Revisión del TEMA instalado
Revisión del CORE de Magento en óptimas condiciones
En este punto vamos a tomar en cuenta un par de cosas pero antes déjame comentarte, recuerdo cuando me ha tocado liderar proyectos en Tiendas de Magento 1 como existen aún muchas de las malas prácticas de desarrollo, como tan sencillo que los desarrolladores no logran sobrescribir, personalizar o mover alguna funcionalidad nativa de Magento y lo hacen directamente en el Core de Magento colocan código directamente en el vendor, todo programador experimentado sabe que eso es una regla infalible ¡El Core nunca se toca! , si fuera el caso y detectamos que el Core ha sido modificado el primer paso es mover todo ese código a módulos personalizados creados con las mejores prácticas y reglas de Magento para que al final el Core este total mente limpio sin cambio alguno.
Como TIP lo que normalmente aplico yo es descargarme una versión limpia de la página oficinal de Magento la coloco en un ambiente local y al mismo nivel descargo el proyecto a analizar y comparo ambas versiones de código para detectar cual modulo u archivo ha sufrido algún cambio, se pueden apoyar de la herramienta WinMerge que detectara si un archivo es distinto a otro incluso indicara las líneas exactas en donde detectara una diferencia.
Al final sin garantizamos que el CORE es estable ya está completamente limpio sin modificación alguna estaríamos listos con este punto.
Revisión de plantillas limpias sin lógica de negocio integrada
Lógica de negocio o como técnicamente se conoce a la Capa de Negocio o Capa intermedia sin meternos en tecnicismo dicho de otro modo vamos a analizar las vistas en concreto todos los archivos .PHTML personalizados o de nuestros componentes y extensiones que no contengan líneas de código que manejen lógica de negocio toda programación que debería estar en las clases de nuestros Controladores y que las hallamos incluido directamente en las vistas, tendremos que realizar un revisión a cada archivo y validar que la vista están limpias de código de negocio, recordemos que en el modelo MVC que se intenta manejar en Magento 1 la regla es que la parte que corresponde alimentar de datos de negocio son los Bloques que a su vez están en comunicación con las clases de Controlador que se encargan de la interacción entre el cliente la acción contra el modelo de datos, nuestra labor aquí es si se localiza lógica de negocio en la vistas es crear sus correspondientes bloques y clase de controlador para solo dejar las vistas con el código que le corresponde.
Revisión de extensiones de terceros
La extensiones de terceros son todas aquellas extensiones que fueron adquiridas desde Magento Connect así como las que son desarrolladas por un proveedor externo, aquí lo más recomendable es primero que nada revisar con el proveedor que ha desarrollado la extensión ya que en la gran mayoría si no es que en concreto cualquier proveedor serio ya cuenta con una versión específica para Magento 2 así que tendremos que realizar un listado de todas esas extensiones y validar cuales ya cuentan con un módulo para la versión 2, de no ser así aquellas extensiones que en definitiva no cuenten con una versión para Magento 2 estas si tendrá que desarrollarlas el equipo de desarrollo desde cero, es importante validar si la extensión ha sido modificada por el mismo propietario de la tienda y con esto me refiero a que la extensión este tal cual se descargó desde el proveedor externo ya que de ser así será importante validar con algún miembro del equipo de negocio de la tienda que pueda definir la solicitud que se le pidió modificar o de lo contrario transmitir las modificaciones para que el equipo de desarrollo intente replicarla a la nueva versión de Magento.
Al final y teniendo ya todas las extensiones listas y disponibles para Magento 2 podríamos dar este punto como válido.
Revisión de extensiones personalizadas
A diferencia del punto anterior las extensiones personalizadas claro está que no son de ningún proveedor ni fueron descargadas de algún sitio externo ya que son soluciones a medida que en su momento fueron solicitadas por el negocio de la tienda así que en este caso no existirá ninguna versión para Magento 2, para este caso debemos sacar un listado de todos estos módulos y extensiones y desarrollar desde cero su versión a Magento 2.
Pare este caso será necesario que un miembro del equipo de la tienda con un nivel de conocimiento de las funcionalidades y reglas de negocio de la actual tienda transmita el mayor detalle posible de cual eran las reglas y necesidades de cada módulo u extensión solicitadas con la finalidad de facilitar el desarrollo a la nueva versión de Magento 2.
De no ser posible que se pueda detallar a máxima expresión el equipo de desarrollo tendrá que revisar cada controlador, bloque vista y de más componentes del módulo para lograr obtener un resumen de lo que puede estar ejecutando la funcionalidad en acciones y eventos, claro está que este proceso será más tardado y más tedioso.
Revisión de extensiones sin utilizar
En este punto parecería ser muy sencilla la tarea pero sin hablamos de Magento 1 con mi amplia experiencia sé que eso no es tan sencillo revisar que extensiones no están habilitadas y simplemente hacer un listado para no tomarlas en cuenta en la migración, no es una cosa que daría resultados tan fácil, porque hay muchos proyectos en los que hay extensiones que están deshabilitadas según la plataforma pero una clase u funcionalidad aún está realizando alguna acción o está conectada deliberadamente con otra funcionalidad y eso se debe a las malas prácticas de desarrollo del programador que cuando justo eliminamos los archivos de esa extensión que en teoría no estaba activa ocurre algo extraño y la plataforma ya no funciona como debería e incluso hasta en algunos casos deja de funcionar por completo.
Para estos caso debemos de igual forma realizar un listado de todas estas extensiones detectadas y revisar cuidadosamente una por una de estas extensiones quintando cada uno de sus componentes validando que la plataforma no deje de funcionar si es el caso validar el por qué y cuál es el archivo incluso las líneas de código que causen tal problema.
Al final cuando logremos quitar físicamente cada uno de los archivos que pertenecen a un módulo u extensión y esta siga su buen funcionamiento daremos por concluido este paso.
Revisión de todo el JavaScript personalizado
Todos los script personalizado de JavaScript no se pueden migrar tal cual a Megento 2, esto es algo que en primer lugar debemos identificar y posteriormente ver en que modulo y extensión se encuentren para una vez detectados, extraerlos como bloques de código ya que cuando llegue el paso de migrar todas esa funcionalidad a Magento 2 esto se realiza mediante la nueva incrustación de código JavaScript mediante la tecnología RequireJS, lo complicado será obtener todo el JavaScript personalizado en donde y cuando se está ejecutando porque una vez tengamos todas esas definiciones será sencillo llevarlos a archivos separados con una mayor simplicidad y mayor rendimiento de integración.
Revisión del Tema instalado
El tema lo de dejado para el final porque aquí cabe aclarar un par de cosas a considerar y es porque, en primera parte si el tema ha sido comprado desde una página ya sea Magento Connect o algún sitio reconocido que se dedique a la venta de temas es probable que ya exista un aversión para Magento 2 y se tendría que adquirir claro está que por lo general si fue un tema de pago se debería pagar por la nueva versión para Magento 2.
Si el Tema fue desarrollado a medida con respecto a la necesidad del negocio aquí es donde debemos echar mano de nuestro equipo de desarrollo para que de igual forma prepare un tema para la versión de Magento 2 ya que aquí aclaremos que la parte de temas entre Magento 1 y Magento 2 es completamente distinta, pero para el equipo de desarrollo no está todo perdido ya que Magento se preocupó por estas acciones y desarrollo un tema base llamado el Tema Blank de la versión Magento 2 que se podrá utilizar para generar un tema base heredado todos los módulos y secciones que necesita Magento para personalizar una tienda de Magento 2 con look and feel personalizado a medida como lo necesite cualquier cliente.
Hasta aquí dejaremos esta primera parte posterior publicare la segunda parte para continuar con este tema de la migración, como se puede ver la información es extensa así que es mejor dividirlo en dos partes.
No olvides de subscribirte a los boletines informativos para estar enterado de cuando publicare nuevos artículos.
Seguimiento del artículo
