Servicios de actualización de versión de Magento

Depende casi por completo de las extensiones y del código a medida, no de cuántas versiones lleve de retraso. Una tienda razonablemente estándar con un puñado de extensiones bien mantenidas es cuestión de semanas, pruebas incluidas. Una tienda muy personalizada con módulos abandonados puede ser bastante más, y la auditoría es lo que distingue una cosa de la otra. Preferimos darle una cifra después de mirar, no antes.

No publicamos un precio, porque la cifra depende de cosas que solo podemos ver mirando la tienda. Lo que la mueve: cuántas versiones se salta, si PHP tiene que cambiar también, cuántas extensiones de terceros usa y cuántas siguen teniendo una versión mantenida, cuánto código a medida hay y si usa los puntos de extensión de Magento o edita el core, si tiene entorno de staging, y si el tema es Luma, Hyvä o algo a medida. Una tienda con una docena de extensiones mantenidas y código a medida limpio es un trabajo mucho más pequeño que una con cuarenta extensiones y un tema que nadie ha tocado desde 2019. La cifra sale de la auditoría.

Actualizar, casi siempre, si está en Magento 2. Una tienda Magento 2 se actualiza en el sitio: los datos, el catálogo, las URLs y el historial de pedidos se quedan. Reconstruir solo tiene sentido cuando el código a medida es tan extenso o está tan mal hecho que migrarlo cuesta más que reescribirlo, y aun así suele ser una reconstrucción parcial del tema o de un puñado de módulos, no de la tienda. Magento 1 es la excepción: pasar a Magento 2 es una reconstrucción con una migración de datos adjunta, la llame como la llame cualquiera.

Con el tiempo sí, porque los parches de seguridad dejan de publicarse para una versión cuando se cierra su ventana de soporte, y una tienda que no se puede parchear es una tienda esperando a ser noticia. Pero el momento es una decisión de negocio y suele haber más margen del que sugiere una cuenta atrás de un fabricante. Le diremos dónde está realmente.

Cada una se comprueba en busca de una versión compatible. Donde la hay, viene con nosotros. Donde el proveedor se ha quedado callado, las opciones son sustituirla por algo mantenido, reconstruir la parte que realmente usa, o asumir su mantenimiento usted mismo, y le diremos qué cuesta cada una antes de que elija.

Cada uno se comprueba contra el nuevo core: clases deprecadas, interfaces que cambiaron, plugins sobre métodos que ya no existen, y los sitios donde un módulo se copió del core y nunca se actualizó. Los módulos construidos dentro de los puntos de extensión de Magento suelen necesitar cambios pequeños o ninguno. Los módulos que sobrescriben clases del core por completo son donde se va el tiempo, y donde sugeriremos pasar a un plugin sobre un objetivo más estrecho para que la siguiente actualización sea más barata que esta.

Hay una ventana de mantenimiento para el despliegue, normalmente corta y programada cuando su tráfico es más bajo. El trabajo previo ocurre en un entorno de staging, no en su tienda en producción.

A veces, y es una pregunta que conviene hacer: si su versión de Magento soporta un PHP más nuevo del que está usando, ese es un trabajo más pequeño con un beneficio de seguridad real. Más a menudo las dos cosas van atadas, y hacerlas por separado significa hacer las pruebas dos veces.

Sí. La actualización en sí es el mismo trabajo. Lo que cambia es el despliegue (la configuración de la aplicación y de los servicios, los hooks de build y deploy, y la configuración de Fastly delante de la tienda) y que tiene que pasar por el propio pipeline de Cloud en un entorno de integración o de staging antes de llegar a producción.

No, y la distinción importa: Magento 1 a Magento 2 es una reconstrucción con una migración de datos adjunta, no una actualización de versión. Se acota y se presupuesta de otra manera. Si una reconstrucción no es el proyecto de este año, OpenMage LTS mantiene una tienda Magento 1 sobre PHP con soporte y recibiendo correcciones de seguridad mientras tanto.