¿Por qué mantener su e-commerce en Magento?

Alguien le ha propuesto un cambio de plataforma. La presentación era buena. Mostraba sus páginas de producto lentas, su retraso en los parches, la actualización que ha aplazado dos veces y una alternativa moderna sin ninguno de esos problemas.

Probablemente cada una de esas observaciones es precisa. La conclusión normalmente no lo es, porque las tres describen cosas que le pasaron a su tienda Magento y no propiedades de Magento, y las recreará todas en la plataforma nueva en unos tres años salvo que cambie algo en cómo se mantiene la tienda.

A veces irse es lo correcto. Hemos escrito las guías de migración y llevamos esos proyectos. Pero antes de gastar de tres a seis meses y un presupuesto de seis cifras, conviene ser preciso sobre qué problema está resolviendo de verdad.

Las tres quejas, y lo que significan en realidad

«Es lento». Magento es rápido cuando se mantiene y lento cuando se descuida, y la distancia entre esos dos estados es enorme. La mayoría de las tiendas Magento lentas lo son por una lista corta de razones bien conocidas: una full-page cache que no funciona como todo el mundo cree, una extensión parlanchina que añade consultas a cada petición, imágenes sin optimizar, una carga JSON de producto configurable sobredimensionada, o scripts de terceros en el head. Eso es localizable y corregible en semanas, no en meses, y por una fracción de un presupuesto de migración.

Cambiar de plataforma para arreglar la velocidad es la forma más cara posible de hacer una auditoría de rendimiento, y si la causa de fondo es un stack de extensiones que nadie cuida, la plataforma nueva lo hereda.

«Es inseguro». El historial de seguridad de Magento es un historial de parcheo. Los datos de explotación no dejan lugar a dudas: cuando SessionReaper (CVE-2025-54236) se parcheó en septiembre de 2025, Sansec encontró que menos de una de cada tres tiendas había aplicado la corrección diez días después, y el 62 % seguía expuesto a las seis semanas, que es exactamente cuando empezó la explotación masiva. La vulnerabilidad estaba corregida. La corrección era gratis. Las tiendas que cayeron no la habían aplicado.

Eso no es una propiedad de la plataforma. Una tienda que no aplica parches es insegura en cualquier plataforma que publique parches, y el SaaS solo elimina el problema para el código de la propia plataforma, no para sus apps e integraciones. Si la queja es el parcheo, arregle el proceso: es más barato que una migración por dos órdenes de magnitud.

«Las actualizaciones son dolorosas». Lo son en proporción a cuánto las aplazó y a cuánta personalización sin gestionar se acumuló. Una tienda que actualiza a tiempo lo hace en un par de semanas. Una tienda cuatro años por detrás con extensiones abandonadas tiene delante un proyecto duro, pero ese proyecto es más o menos el mismo trabajo que una migración, y al final sigue teniendo sus integraciones, su modelo de datos y su posicionamiento en buscadores.

Lo que estaría tirando

Las propuestas de cambio de plataforma son buenas calculando el coste de la construcción y malas calculando el de la pérdida. Cosas que no aparecen en la diapositiva:

Años de modelado de datos del catálogo. Sus conjuntos de atributos, los ámbitos de los atributos, la estructura de categorías y las cien pequeñas decisiones codificadas en ellos. Reconstruir eso sobre un modelo de datos distinto es donde los proyectos de migración se pasan de plazo de verdad: el mapeo de variantes y atributos, no el código.

Lógica de integración. Cada peculiaridad del ERP, cada caso límite de impuestos, cada regla de transportista, cada «excepto para este grupo de clientes» que alguien resolvió hace tres años y nadie apuntó. Funciona. No está documentado. Se redescubrirá de la forma cara.

Capital SEO. Este es el que aparece en los ingresos. Un cambio de plataforma significa estructuras de URL nuevas, plantillas nuevas, marcado nuevo y un mapa de redirecciones que tiene que estar bien a la primera. Hecho bien, mantiene la posición. Hecho al final del proyecto, bajo presión de tiempo, el tráfico cae y tarda meses en recuperarse, y durante ese tiempo la migración parece un error de negocio sea cual sea la calidad de la ingeniería.

Memoria muscular operativa. Su equipo sabe dónde está todo en el admin. Los responsables de merchandising saben cómo montar la promoción. Soporte sabe cómo encontrar el pedido. Esa fluidez vale dinero real y vuelve a cero el día del lanzamiento.

Reglas de negocio a medida. La lógica de precios, las reglas de cumplimiento, el comportamiento del checkout que encaja con cómo vende de verdad. Cada una tiene que volver a especificarse, reconstruirse y volver a probarse, y la especificación normalmente solo existe como la implementación actual.

Cómo es quedarse bien

Quedarse solo es la respuesta correcta si quedarse significa algo distinto de lo que ha venido haciendo. En concreto:

Esté al día, y siga al día. Cada línea de versión recibe una ventana de soporte estándar de tres años: 2.4.8 llega hasta el 31 de mayo de 2028, 2.4.9 hasta el 31 de mayo de 2029. Planifique la actualización en el segundo año, no la semana en que llega la fecha límite. Una actualización tomada a tiempo es trabajo rutinario; una tomada tarde es una crisis con presupuesto.

Tenga un proceso de parcheo con un nombre. Alguien recibe los boletines de Adobe, hace el triaje en un día laborable y despliega. Un entorno de staging que coincida con producción, una prueba de humo de diez minutos por el checkout y un rollback ensayado. Eso es todo, y convierte el parcheo de un riesgo en una tarea. Conviene saberlo: los parches de seguridad aislados de Adobe deben aplicarse encima de la última versión solo de seguridad de su línea, así que un retraso acumulado es exactamente lo que le bloquea el día que necesita moverse rápido.

Cuide las extensiones como dependencias, no como funciones. Cada módulo es código del que usted es responsable. Audite cada año: sigue usándose, sigue mantenido, sigue valiendo lo que pesa. Elimine en lugar de desactivar: el código desactivado sigue en el disco. Un módulo sin mantener con acceso a la base de datos es una dependencia de seguridad, lo piense así o no.

Mantenga un presupuesto de rendimiento. Mida los Core Web Vitals en sus plantillas reales, no en la portada. Fije un umbral y trate una regresión como un bug y no como un debate. El rendimiento se degrada en silencio; un presupuesto hace visible la degradación mientras todavía es barata.

Sea dueño de su tema. Un tema que nadie puede cambiar con seguridad es el mayor impulsor individual de «deberíamos cambiar de plataforma». Si el suyo está en ese estado, reconstruir el frontend sobre la plataforma que ya tiene es muchísimo más barato que reconstruirlo sobre una plataforma que todavía no conoce.

Haga esas cinco cosas y la mayor parte del argumento para irse se evapora, porque el argumento nunca fue realmente sobre Magento.

Cuándo irse es correcto de verdad

Le haríamos un flaco favor fingiendo lo contrario. Váyase, y váyase de forma deliberada, si:

• Su complejidad ha bajado. Simplificó el negocio, cerró la rama B2B, recortó el catálogo. La flexibilidad de Magento es ahora coste sin retorno, y algo alojado le servirá mejor y más barato.
• No puede dotarlo de personal. Sin capacidad interna, sin una agencia en la que confíe, sin presupuesto para ninguna de las dos. Una tienda Magento sin mantener es peor que una tienda SaaS con limitaciones, y esa es la comparación honesta.
• Está reconstruyendo de todos modos. Si el tema se va a sustituir y las integraciones se van a rehacer en cualquier caso, el coste marginal de cambiar de plataforma es mucho menor: ese es el momento de evaluar como es debido.
• La plataforma de verdad no encaja. Su modelo necesita algo que Magento expresa mal: suscripciones como movimiento principal, mecánicas de marketplace, un cumplimiento de pedidos inusual. Pelearse con la plataforma en cada sprint es una señal real.

Si ninguna de esas le describe, y la propuesta se construyó sobre páginas lentas y un retraso en los parches, le están vendiendo una migración como solución a un problema de mantenimiento.

La pregunta que conviene hacer a quien propone

Una pregunta separa un buen argumento para cambiar de plataforma de una maniobra comercial:

«¿Cuáles de estos problemas seguirían existiendo si arregláramos el mantenimiento en su lugar?»

Un buen partner responderá con honestidad, y para muchas tiendas la respuesta es «la mayoría no». Eso no es un argumento para la complacencia: el mantenimiento necesita arreglarse de verdad, y hoy. Es un argumento para gastar el dinero en el problema real.

Si está sopesando esto desde la otra dirección —todavía no está en Magento y se pregunta si debería estarlo—, esa es una pregunta distinta con una respuesta distinta.

Emyrix hace las dos cosas: mantenemos y modernizamos tiendas Magento, y llevamos migraciones desde Magento cuando esa es de verdad la decisión correcta. Si quiere una lectura honesta de cuál de las dos necesita su tienda, escríbanos: le diremos si la respuesta es más barata de lo que esperaba.

Las fechas de las ventanas de soporte proceden de la política de ciclo de vida del software de Adobe; las cifras de explotación de SessionReaper son de la investigación de Sansec. Las dos merecen consultarse directamente.