Migrar de Magento 2.3/2.4 legacy a una versión soportada
La tienda "funciona", entonces nadie la toca. Hasta que sale un parche de seguridad que ya no puedes aplicar, el hosting deja de soportar tu PHP, o una extensión truena. Quedarte en una versión sin soporte no es ahorrar: es acumular una deuda que se cobra sola, casi siempre en el peor momento.
// assets/blog/migrar-legacy-cover.jpg
Casi todas las semanas nos llega el mismo mensaje, con distinta cara: "tengo una tienda en Magento que lleva años corriendo sin problemas, pero me dijeron que ya está vieja, ¿de verdad tengo que moverle?". Y la respuesta, casi siempre, es sí. Pero no por moda ni por "estar al día": por riesgo real.
Hablamos de tiendas en Magento Open Source 2.2, 2.3 o algún 2.4.x que ya quedó fuera de soporte. Versiones que un día fueron lo último y hoy están congeladas. La tienda sigue vendiendo, el equipo se acostumbró a que nadie la toque, y esa quietud se confunde con estabilidad. No es lo mismo. Una versión sin soporte no está estable: está abandonada, y tú todavía no te enteras.
Te explico por qué eso importa, sin asustarte de más pero sin endulzarlo.
La trampa: "funciona" no quiere decir "está bien"
El problema de una versión EOL —end of life, fin de soporte— es que deja de recibir parches de seguridad. Y aquí está lo incómodo: Magento publica los detalles de cada vulnerabilidad cuando saca el parche. O sea que el día que se anuncia un fix, todo el mundo —incluida la gente que no deberías querer cerca— sabe exactamente qué agujero tiene tu versión y cómo entrar. Si no puedes aplicar ese parche, tu tienda queda con un mapa público de sus propias puertas abiertas.
Y no es solo Magento. Tu versión vieja está atada a un PHP viejo, y PHP también tiene fechas de fin de soporte. Cuando tu hosting actualiza su infraestructura o tú cambias de proveedor, ese PHP antiguo simplemente deja de estar disponible. La tienda que "nunca da problemas" un día no levanta, y no por un bug tuyo, sino porque el piso sobre el que estaba parada desapareció.
Una tienda sin parches no es una tienda segura que todavía no la atacan. Es una tienda insegura que todavía no se entera.
Para cualquiera que procese tarjetas, esto se vuelve además un tema de cumplimiento. PCI DSS te exige mantener el software con sus parches al día. Correr una versión EOL te pone fuera de norma, y eso —en caso de una brecha— deja de ser un problema técnico para volverse un problema legal y de dinero.
Cómo saber si tu versión ya es un problema
No necesitas ser desarrollador para hacer el primer diagnóstico. Tres preguntas te dicen casi todo:
¿Tu versión sigue recibiendo parches? Si estás en 2.2 o 2.3, la respuesta es no, llevan tiempo fuera de soporte. Si estás en algún 2.4.x, depende del número exacto; las versiones tienen ventana de soporte y la tuya pudo haber vencido. Revisar esto toma cinco minutos y es lo primero que debes saber.
¿Sobre qué PHP corre? Si tu tienda vive en PHP 7.x, ya estás corriendo sobre algo sin soporte. Las versiones modernas piden PHP 8.3 o superior, y vale la pena apuntar a 8.4/8.5, que además te dan mejor rendimiento.
¿Cuándo fue el último parche de seguridad que aplicaste? Si la respuesta es "no sé" o "hace años", ahí tienes tu señal. Cada mes sin parchar es deuda que se acumula en silencio.
La ruta de actualización, paso a paso
Subir de una versión legacy a una soportada no es apretar un botón. Es un proyecto, y como todo proyecto serio, empieza por entender de dónde partes antes de decidir a dónde vas.
1. Auditoría del punto de partida. Lo primero es medir la deuda técnica real: qué versión exacta tienes, sobre qué PHP, cuántas extensiones de terceros, cuánto código a la medida, y qué tan lejos quedaron esos módulos de lo que la versión nueva espera. Una tienda con código limpio se mueve rápido. Una con diez años de parches encima, módulos abandonados y customizaciones que nadie documentó es otra historia. Por eso el cronograma se cierra después de auditar, nunca antes.
2. Definir el destino. Aquí elegimos la versión soportada objetivo. Nuestra recomendación de fondo es Mage-OS 3.x sobre Magento Open Source 2.4.9, corriendo en PHP 8.4/8.5. Más abajo te cuento por qué Mage-OS y no simplemente "el Magento de siempre".
3. Todo se construye primero en staging. Nada se toca en producción. Levantamos un ambiente de staging que es copia fiel de tu tienda viva, y ahí hacemos la actualización completa: el core nuevo vía Composer, la migración de módulos compatibles, el reemplazo de los que ya no sirven, los datos completos. Staging es donde te puedes equivocar gratis. Es el lujo de romper algo un martes a las 3 de la tarde en lugar de un sábado a las 11 de la noche con clientes reales del otro lado.
4. El SEO es ingeniería, no un parche del final. En una actualización de versión el catálogo viaja bien —el modelo de datos es el mismo núcleo— pero las URLs son la parte delicada. Tienes años de tráfico orgánico en rutas que Google ya indexó y aprendió a confiar. Si la migración cambia esas URLs sin avisar, Google lo lee como una tienda nueva y te castiga. Por eso sacamos el inventario completo de URLs vivas, lo mapeamos contra el destino, y cualquier ruta que cambie se redirige con un 301 permanente. Sin excepciones.
5. QA y cutover. Sobre staging corremos QA de verdad: funcional, de regresión, checkout con pagos en sandbox, las integraciones con ERP y facturación. Cuando todo eso pasa tres veces, el día del cambio es pura coreografía: ventana acordada, sync final de los datos que cambiaron, cambio de DNS y verificación contra una checklist que ya conocemos de memoria. El cutover bien hecho es aburrido, en el buen sentido.
# actualización del core al destino soportado $ composer require magento/product-community-edition 2.4.9 --no-update $ composer update $ bin/magento setup:upgrade $ bin/magento setup:di:compile $ bin/magento setup:static-content:deploy es_MX $ bin/magento cache:flush $ # smoke test: home, PDP, carrito, checkout, login
Los primeros días post-launch no nos vamos. Monitoreamos logs, tiempos de respuesta, que Google empiece a recorrer las rutas y que los pedidos fluyan. Es la parte menos vistosa del proyecto y la que más tranquilidad da.
¿Por qué Mage-OS y no quedarte donde estás?
Si vas a invertir en una actualización, vale la pena que el destino sea el correcto. Mage-OS es la distribución comunitaria, abierta y soportada de Magento: 100% compatible, sin licencia que pagar, con releases al día y un equipo activo detrás. Para una tienda que viene saliendo de una versión congelada, es exactamente lo que necesitas: una base moderna, mantenida y que no te vuelve a dejar varado en unos años.
Una aclaración por si aplica a tu caso: este artículo es para quien está en Magento Open Source (la versión gratuita) y necesita subir a una versión soportada. Si lo tuyo es Adobe Commerce y lo que te duele es la factura de la licencia, ese es otro camino —relacionado pero distinto— y lo cubrimos aparte en De Adobe Commerce a Mage-OS: la ruta sin downtime.
Lo que sí te garantizamos
No te vamos a dar un número antes de auditar, porque sería adivinar, y adivinar con tu tienda en juego no es nuestro estilo. Lo que sí te garantizamos es el método: nada sale a producción sin haber vivido primero en staging, y ninguna URL con tráfico se queda sin a dónde aterrizar. El resto es ejecución disciplinada.
Si no sabes en qué versión estás parado o cuándo aplicaste el último parche, ese desconocimiento ya es el riesgo. La auditoría inicial es sin costo: te decimos exactamente dónde estás, qué tan expuesto estás y qué tomaría llevarte a terreno seguro. Hablemos.