Magento 2.4.6 EOL en agosto de 2026: cómo bajarse de la rueda de parches sin hacer un replatforming

El soporte regular de Magento 2.4.6 termina el 11 de agosto de 2026. Si todavía está en la versión 2.4.5, lleva fuera de la ventana de soporte desde el 12 de agosto de 2025. Hay tres opciones sobre la mesa: sprint de parches, replatforming o desacoplar el frontend, y cada una tiene su letra pequeña.

Este artículo está pensado para responsables de e-commerce, CTOs y jefes de ingeniería que gestionan una tienda Magento 2 con entre cinco y cien millones de euros de facturación online y que están calculando cuánto van a costar los próximos doce meses. Repasamos las tres vías, mostramos los números detrás de cada una y explicamos dónde una migración a composable commerce a través del frontend resulta más económica que un replatforming de golpe.

Las tres opciones comparadas

Ahora mismo todo comercio con Magento tiene tres caminos realistas:

1. Sprint de parches a 2.4.7 o 2.4.8 - El backend y el frontend se mantienen, el esfuerzo se traslada al pipeline de parches. La 2.4.7 tiene soporte regular hasta el 9 de abril de 2027; la 2.4.8, hasta el 11 de abril de 2028. Adobe pasó a ciclos de parches mensuales en enero de 2026.
2. Replatforming - Cambio completo a Shopify Plus, Shopware 6, commercetools, BigCommerce o Adobe Commerce on Cloud. Duración típica del proyecto: de 12 a 24 meses, con backend y frontend reconstruidos en paralelo.
3. Desacoplar el frontend - El backend de Magento no se toca, el frontend se conecta vía GraphQL y corre sobre una Frontend Management Platform (FMP). El ciclo de parches queda aislado en el backend, el frontend depende del contrato de la API, no del motor de temas.

Cada opción tiene su propio perfil de riesgo. La elección depende menos de la tecnología y más de lo que su roadmap necesita entregar en doce meses, y de cuánta opcionalidad quiere conservar después de eso.

Opción 1: sprint de parches a 2.4.7 o 2.4.8

El camino obvio: dejar la 2.4.6, instalar la 2.4.7 o la 2.4.8 y ampliar la ventana de soporte. Suena a trabajo de un fin de semana, pero en la práctica es un proyecto trimestral en sí mismo.

Lo que realmente aparece:

• Inventario de extensiones - Revisar cada extensión de terceros contra la versión de destino. Las tiendas del mercado medio en la región DACH suelen tener entre 40 y 120 extensiones. Regla general: entre el 20 y el 30 por ciento necesita actualización o sustitución.
• Configuración o verificación del pipeline de pruebas - Si todavía trabaja sin pruebas de regresión respaldadas por CI, ahora es el momento de construirlas. Con ciclos de parches mensuales desde enero de 2026, las pruebas de humo manuales ya no escalan.
• Reprueba del frontend en cada parche - Con un tema basado en Luma, cada parche puede provocar regresiones de CSS o de maquetación. Con Hyvä el riesgo en el frontend es menor, pero la propia migración a Hyvä sigue pendiente.
• Actualizaciones de versión de PHP, actualizaciones de Composer, migraciones de esquema - Trabajo estándar, pero un generador de costes real en módulos personalizados ya antiguos.

Rango de coste: una estrategia de parches ordenada para una tienda de entre cinco y veinte millones de euros sobre Luma se sitúa entre 4.000 y 12.000 euros por ciclo de parches, más entre 1.500 y 4.000 euros al mes de infraestructura de pruebas y despliegue. En doce meses eso suma fácilmente una cifra de seis dígitos, y cada céntimo se destina a "quedarse donde está". Nada de eso aporta a conversión, rendimiento o nuevas funcionalidades.

La letra pequeña: el EOL de la 2.4.8 es el 11 de abril de 2028. En dos años la misma pregunta vuelve a su mesa, y no la habrá respondido, solo la habrá aplazado.

Opción 2: replatforming

El replatforming conlleva riesgos reales, y eso hay que ponerlo sobre la mesa. Pasar de ocho años de Magento a Shopify Plus o Shopware 6 no es solo reescribir un frontend: hay que migrar datos de producto, cuentas de cliente, historial de pedidos, listas de precios B2B, integraciones con ERP, disparadores de marketing automation y estructuras de URL para SEO.

Duración típica del proyecto: de 12 a 24 meses. Puntos de fricción típicos:

• Riesgo de migración de datos - Mapeos de atributos personalizados, estructuras EAV, grupos de clientes B2B. Regla general: entre el 5 y el 15 por ciento de los modelos de datos requiere un tratamiento especial.
• Riesgo de pérdida de SEO - Estructuras de URL, mapeos de redirecciones, marcado schema. Unas estrategias de redirecciones 301 bien hechas suavizan la caída, pero rara vez la eliminan. Caída realista de tráfico orgánico en los primeros tres a seis meses: entre el 10 y el 30 por ciento.
• Complejidad de la fase paralela - Mientras se construye el nuevo backend, el Magento antiguo sigue necesitando parches. Dos stacks, dos equipos, dos pipelines de pruebas.
• Paridad de funcionalidades - Las funcionalidades B2B, el multi-store, el multi-marca y los flujos de trabajo personalizados construidos durante más de cinco años de personalización de Magento rara vez se corresponden uno a uno con la nueva plataforma.

Rango de coste: entre 150.000 y 800.000 euros de implementación, más entre 3 y 12 meses de coste de licencias y hosting en paralelo. A eso se suma el coste de oportunidad: de 12 a 24 meses en los que el equipo no está trabajando en conversión, surtido o nuevos mercados.

El replatforming es la respuesta correcta cuando el propio backend es el cuello de botella: mal rendimiento bajo carga, funcionalidades B2B que faltan, un hosting que no escala. Cuando el cuello de botella es el frontend (LCP en móvil, mantenimiento del tema, time-to-market para nuevos storefronts), el replatforming no ataca el problema real.

Opción 3: desacoplar el frontend

Aquí es donde entramos nosotros: mantener el backend de Magento y desacoplar el frontend del trilema Luma/Hyvä/PWA. El ciclo de parches queda aislado en el backend. El frontend depende del contrato de la API GraphQL, no del motor de temas. Cuando Adobe lance Magento 2.4.9, en el escenario ideal el frontend ni se entera: el contrato de la API se mantiene estable.

En concreto:

• Conexión de Orchestr con Magento GraphQL - Productos, categorías, clientes, carrito, checkout. Magento sigue siendo la fuente de verdad para todas las operaciones comerciales.
• Frontend Management Platform (FMP) - Studio (editor visual para equipos de marketing), biblioteca de UI (componentes prediseñados y personalizables) y motor de theming (varios storefronts sobre una única base de código).
• Más de 50 integraciones de backend a través de Orchestr - Búsqueda (Algolia, Klevu), CMS (Contentful, Storyblok), pagos, fidelización, suscripciones, como fuentes de datos paralelas junto a Magento.

Qué gana con esto:

• Opcionalidad de parches - Los parches del backend no afectan directamente al frontend. No hay que reprobar el frontend con cada actualización de Magento.
• Rendimiento sin migrar a Hyvä - Un LCP móvil por debajo de 2,5 segundos es alcanzable gracias a la arquitectura edge de la FMP sin tocar el tema del backend. Más sobre esto en Rendimiento y Core Web Vitals.
• Cumplimiento BFSG / accesibilidad - La biblioteca de UI viene conforme con WCAG 3.0 de fábrica. Luma no cumple WCAG 3.0 de forma nativa, y la ley alemana de accesibilidad BFSG está en vigor desde el 28 de junio de 2025.
• Opcionalidad de replatforming - De aquí a 18 o 24 meses puede mover el backend de Magento a commercetools, Shopware 6 o Shopify B2B sin volver a tocar el frontend. Se sustituye el adaptador de API en la capa de Orchestr, no el storefront.

Si quiere los números detallados de cuándo compensa el cambio, los desarrollamos en nuestro artículo del 3 de mayo de 2026 sobre si merece la pena el cambio a Magento Headless.

La letra pequeña aquí, dicha con honestidad: desacoplar no es la respuesta a los problemas del backend. Si el propio Magento es demasiado lento, demasiado caro o demasiado rígido, poner una FMP delante no lo soluciona. Desacoplar es la respuesta cuando el backend funciona bien y el cuello de botella es el frontend.

Qué deben sopesar ahora las tiendas del mercado medio

Cuatro caminos, cinco dimensiones, una comparación:

Dimensión · Sprint de parches 2.4.7/2.4.8 · Migración a Hyvä · Replatforming · Laioutr FMP (desacoplamiento)

Esfuerzo (semanas) · 8-14 (inicial) + continuo · 6-32 semanas · 52-104 semanas · <14 días tienda única, 6-12 semanas multi-marca

Coste de migración del frontend · 0 (se mantiene en Luma) · 30.000-150.000 € + licencia 1.000-5.000 € puntual + suscripción · incluido en el presupuesto de replatforming (150.000-800.000 €) · incluido en el modelo FMP

LCP móvil · 4-7 s (Luma típico) · 1,8-3,0 s · depende de la plataforma de destino · <2,5 s

Cumplimiento BFSG / WCAG · requiere trabajo manual en el tema · depende del tema personalizado · depende de la plataforma de destino · WCAG 3.0 de fábrica

Opcionalidad de replatforming a los 18 meses · baja, mismo problema de stack · baja, el tema de Hyvä queda acoplado al backend · ya ejecutado · alta, backend sustituible vía adaptador de Orchestr

Lo que muestra la tabla: tres de los cuatro caminos le atan a una decisión de arquitectura durante los próximos dos años. El cuarto mantiene abierta la opción de volver a decidir en dos años con datos reales, sin reconstruir el frontend.

Ruta de migración con Laioutr

Si opta por la vía de la FMP, este es el camino habitual. Las estimaciones en semanas vienen de nuestras últimas doce migraciones de Magento:

1. Discovery (semana 1) - Inventario del backend, auditoría de GraphQL, listado de extensiones, línea base de rendimiento. Se mide el LCP móvil, el INP y el CLS actuales.
2. Configuración de Orchestr (semanas 1-2) - Conexión de Magento GraphQL, capa de autenticación, flujo de carrito y checkout. Objetivo: cerrar el contrato de la API.
3. Mapeo de componentes (semanas 2-3) - Se mapean los componentes existentes de Luma/Hyvä a la biblioteca de UI de la FMP. PDP, PLP, carrito, checkout, cuenta, páginas de CMS.
4. Consolidación de extensiones (semanas 2-3, en paralelo) - Qué extensiones de Magento pueden retirarse porque la capa FMP asume su función. Búsqueda, A/B testing, personalización y la lógica del mini-carrito suelen pasar a esta capa.
5. Activación multi-marca (opcional, semanas 3-4) - Si gestiona varios storefronts, aquí se pasan a una base de código compartida.
6. Lanzamiento suave (semanas 4-6 tienda única, 6-12 semanas multi-marca) - Cambio de tráfico gradual mediante enrutamiento edge. Rollback disponible en cualquier momento.

Mediana de migración con acompañamiento del equipo fundador: menos de 14 días para una tienda única que llega con datos limpios a la fase de discovery. Eso supone una reducción del 65 por ciento frente a la mediana típica de una migración a Hyvä.

Preguntas frecuentes

¿Qué significa EOL para Magento?

El fin de vida (EOL) significa que Adobe deja de publicar parches de seguridad y correcciones de errores para la versión afectada. Para Magento Open Source y Adobe Commerce 2.4.6, el soporte regular termina el 11 de agosto de 2026. A partir de ahí, su tienda funciona sobre una versión en la que las vulnerabilidades de seguridad recién descubiertas ya no se parchearán oficialmente, algo relevante tanto para PCI-DSS como para el seguro de ciberriesgos. Fuente: Notas de versión de Adobe Magento.

¿Sigue mereciendo la pena migrar a Hyvä con el EOL encima?

Hyvä es una ingeniería sólida y un salto de rendimiento claro frente a Luma, ahí no hay discusión. La pregunta es la lógica de la inversión: una migración a Hyvä cuesta entre 30.000 y 150.000 euros de implementación más licencia, y acopla el frontend al motor de temas de Magento. Si prevé una conversación de replatforming en 18 o 24 meses, está construyendo un frontend que va a volver a tocar después. Desacoplar mediante una FMP invierte el mismo presupuesto en un frontend que mantiene abiertas ambas vías: seguir con Magento o cambiar el backend.

¿Realmente el backend no se toca durante el desacoplamiento?

En la configuración estándar, sí. Magento sigue siendo la fuente de verdad para productos, categorías, pedidos y clientes. La FMP consume únicamente la API GraphQL oficial de Magento. Lo que sí conviene hacer en el backend en cualquier caso: poner la API GraphQL al día y documentar con claridad los resolvers personalizados para casos especiales (precios B2B, atributos personalizados). Pero no hay reconstrucción del tema, ni intervención en PHP, ni revisión de las extensiones de Magento.

¿Cómo sería una migración a los 12 meses hacia Adobe Commerce u otro backend?

En el modelo de desacoplamiento se sustituye el adaptador del backend en la capa de Orchestr. El frontend, el contenido, los píxeles de tracking y el mapeo SEO se mantienen. Tenemos clientes que pasaron de Magento a commercetools de esta forma y conservaron el 100 por ciento de su frontend. Una migración de backend típica sin reconstruir el frontend dura entre 8 y 16 semanas, frente a las 52 a 104 semanas de un replatforming clásico.

Más temas de la plataforma Laioutr

• Frontend Headless para Magento 2, hub del Pilar 2
• Composable Digital Experience Platform, hub de la plataforma
• Rendimiento y Core Web Vitals
• Composable Headless Frontend, arquitectura

Siguiente paso

Si quiere leer el 11 de agosto de 2026 no como una fecha límite de parches, sino como una decisión de arquitectura: en 20 minutos le mostramos cómo sería el desacoplamiento para su stack específico de Magento. Incluye un mapa de Orchestr para sus extensiones actuales y una valoración honesta de cuándo desacoplar no es el camino adecuado para usted.

[Reserve una demo de 20 minutos sobre la arquitectura de desacoplamiento de Magento →](https://www.laioutr.com/en/contact)

La arquitectura queda en sus manos. Desacoplar en lugar de hacer replatforming, y el próximo ciclo de EOL de Magento se convierte en una cuestión de backend, no en una crisis de frontend.