Guía de actualización de Magento 2: planificar una actualización de versión segura

Nadie completa una actualización de Magento segura ejecutando un comando de Composer y cruzando los dedos. Este es el proceso repetible, el que funciona sea cual sea el par de versiones entre las que se mueva. Las particularidades del salto actual las cubrimos en 2.4.6 a 2.4.9 por separado; esto es la metodología que hay debajo.

Por qué actualizar

Tres razones, en orden de cuánto le costarán si las ignora:

• Ventanas de soporte de seguridad. Cada versión de Magento tiene una fecha de fin de soporte, a partir de la cual no se publican más parches. Magento 2.4.6 llega al fin de soporte el 11 de agosto de 2026: después de eso, una tienda sin parchear es un pasivo que va creciendo, no solo una tienda antigua.
• Compatibilidad de PHP. Magento 2.4.8 requiere PHP 8.3 u 8.4; 8.1 y 8.2 han desaparecido. Su versión de PHP va atada a su versión de Magento, y las ramas antiguas de PHP dejan de recibir sus propias correcciones de seguridad.
• Coste acumulado. Cuanto más espere, mayor es el salto, más se han desviado las extensiones y más se convierte la actualización de un mantenimiento rutinario en un proyecto. Quedarse atrás es la opción cara; solo que no manda la factura hasta más tarde.

Paso 1: haga inventario antes de planificar

No puede planificar una actualización que no ha medido. Anote:

• La versión y edición actuales de Magento (Open Source, Adobe Commerce, Mage-OS).
• La versión actual de PHP, y el requisito de la versión de destino.
• Cada extensión de terceros, con su versión instalada y si existe una versión compatible con el destino.
• El volumen y la forma del código a medida: módulos, sobreescrituras del tema, parches del núcleo y cualquier cosa que toque el checkout o el catálogo.

Esta lista es todo el perfil de riesgo. Una tienda con diez extensiones bien educadas y módulos a medida limpios es una actualización distinta de una con cuarenta extensiones y una década de sobreescrituras acumuladas, incluso entre las mismas dos versiones.

Paso 2: audite la compatibilidad; aquí vive el riesgo

La actualización del núcleo de Magento en sí es en gran medida mecánica. El riesgo está en todo lo que se le ha atornillado encima.

Recorra el inventario extensión por extensión:

• ¿Hay una versión compatible con la versión de Magento de destino? Si sí, anótela. Si no, tiene una decisión: esperar, sustituir, hacer un fork o eliminar la extensión.
• ¿Qué módulos a medida tocan APIs que cambiaron? Las deprecaciones y los métodos eliminados entre versiones son la rotura habitual. El análisis estático y la herramienta de compatibilidad de actualización de bin/magento ayudan, pero una lectura senior del código a medida encuentra lo que se le escapa a la herramienta.
• ¿Hay parches o ediciones del núcleo? Estas son las minas. El código que modificó el núcleo se revertirá en silencio o entrará en conflicto al actualizar. Encuéntrelas ahora, no en producción.

Si una extensión no tiene versión compatible ni mantenedor, eso no es una nota al pie: es un punto de alcance que puede dominar todo el proyecto.

Paso 3: elija el camino

No siempre hay que pasar por cada versión intermedia. Adobe soporta pasar directamente de 2.4.6 a 2.4.8 sin la versión intermedia, por ejemplo. Pero el camino correcto depende de cuánto va por detrás:

• Una o dos versiones menores: normalmente un salto directo.
• Varias versiones, o cruzando un requisito importante de PHP: considere un camino por fases, actualizando PHP y la infraestructura de búsqueda como pasos separados en lugar de todo a la vez, de modo que un fallo tenga una causa evidente.
• Cruzar la línea de Elasticsearch a OpenSearch (eliminado en 2.4.8): eso es una migración de motor de búsqueda por derecho propio, no un interruptor que se activa a mitad de actualización.

Secuencie los cambios de infraestructura —PHP, motor de búsqueda, backend de caché— para que cada uno sea verificable por su cuenta.

Paso 4: monte un entorno de staging que refleje producción

Cada problema de actualización que encuentre en staging es uno que no encontró en producción. El staging tiene que ser realista:

• Un volumen de datos similar al de producción. Una actualización que va bien contra 200 productos anonimizados puede ahogarse con un catálogo de 200.000 SKU e indexers reales.
• Las mismas versiones de PHP, búsqueda, caché y servidor web que va a usar en vivo.
• El conjunto real de extensiones, no una copia recortada.

Una copia anonimizada de la base de datos de producción —con los datos personales de los clientes limpiados— es el estándar aquí. Probar contra datos de juguete es como «funcionaba en staging» se convierte en una mentira.

Paso 5: pruebe la regresión de los caminos que generan ingresos

Pruébelo todo, pero pruebe primero y con más dureza los caminos que generan dinero:

• El checkout: cada método de pago, cada método de envío, como invitado y con sesión, carritos virtuales y descargables, casos límite de impuestos y descuentos.
• El catálogo y la búsqueda: páginas de categoría, navegación por capas, resultados de búsqueda, sobre todo después de una migración de motor de búsqueda.
• El admin: gestión de pedidos, edición de productos y cualquier herramienta de admin a medida en la que su equipo vive a diario.
• Las integraciones: conexiones con ERP, PIM, pagos e impuestos que un cambio de versión puede romper en silencio en la capa de API.

La cobertura automatizada ayuda, pero una pasada manual disciplinada por el checkout no es negociable.

Paso 6: despliegue sin tiempo de inactividad y con un rollback probado

La actualización solo es real cuando está en vivo sin haber tirado la tienda.

• Use el modo de deploy y las ventanas de mantenimiento de Magento como es debido, o un enfoque blue/green en el que la versión nueva se calienta y se conmuta, en lugar de actualizar en el sitio.
• Genere el contenido estático y caliente las cachés antes del cambio, para que el primer cliente no pague por una tienda en frío.
• Tenga un rollback que haya probado de verdad: una copia de seguridad de la base de datos y una forma de volver a la versión anterior. Un rollback sin probar es una esperanza, no un plan. El estado de los índices y de la caché tiene que formar parte de él.

Paso 7: después de la actualización

La mejor forma de que la próxima actualización sea pequeña es no volver a quedarse atrás:

• Aplique los parches de seguridad con cadencia, en lugar de guardarlos para el próximo gran salto.
• Mantenga las extensiones al día, para que la desviación de compatibilidad nunca se acumule.
• Tome la línea base de rendimiento después de la actualización: una versión nueva más una rama nueva de PHP suelen cambiarlo, y querrá saber en qué dirección. Nuestro checklist de rendimiento es la lista de ejecución para eso.

Qué haríamos

Reducido a lo esencial, una actualización segura es inventario, auditoría de compatibilidad, un staging realista, pruebas despiadadas del checkout y un rollback ensayado, en ese orden. El comando que realiza la actualización es la parte más pequeña; todo lo que hay alrededor es donde los proyectos triunfan o fracasan. Si tiene delante una fecha límite de versión y prefiere un camino probado a uno esperanzado, el soporte y las actualizaciones de Magento de forma continua existen precisamente para que la fecha límite nunca se convierta en una emergencia.

Emyrix planifica y ejecuta actualizaciones de versión de Magento y Adobe Commerce: auditorías de compatibilidad, despliegues por fases y deploys sin tiempo de inactividad. Si se le viene encima una fecha de fin de soporte, escríbanos.