Migrar de Magento 1 a Adobe Commerce 2: guía técnica completa

Esta guía se escribió cuando el final de Magento 1 todavía era noticia reciente. Seis años después del cierre del soporte, el problema no ha desaparecido: siguen existiendo decenas de miles de tiendas en producción sobre Magento 1. Si la tuya es una de ellas, o si estás valorando el salto a Magento 2 / Adobe Commerce, esto es lo que hay que saber en 2026.

Actualizado en septiembre de 2026: versiones y requisitos vigentes de Magento 2.4.9, estado real de la herramienta oficial de migración de datos y fechas de fin de soporte de las ramas activas.

Magento 1 está muerto: la migración ya no es opcional

Magento 1 dejó de recibir parches de seguridad en junio de 2020. Si aún tienes una tienda en Magento 1, estás operando con vulnerabilidades conocidas sin parchear y un ecosistema de extensiones que ya no se mantiene. La migración a Magento 2 (Adobe Commerce) o a otra plataforma no es un proyecto más: es una necesidad urgente.

Conviene ser preciso sobre en qué consiste ese riesgo, porque «vulnerabilidades sin parchear» suena abstracto. En la práctica significa tres cosas concretas. La primera: cualquier fallo descubierto desde 2020 en el core sigue abierto, y como el código es público, las pruebas de concepto circulan libremente. La segunda: la versión de PHP sobre la que corre Magento 1 también está fuera de soporte, así que el riesgo no está solo en la aplicación sino en toda la pila. La tercera, y la que más daño hace en tiendas reales: el skimming de tarjetas. Los ataques de este tipo insertan JavaScript en la página de pago para copiar los datos de la tarjeta mientras el cliente los teclea; la tienda sigue funcionando con normalidad y el robo puede durar meses sin que nadie lo note.

Añade a eso la parte regulatoria. Una brecha de datos personales obliga a notificar a la Agencia Española de Protección de Datos en 72 horas, y las normas de la industria de medios de pago exigen que el software que procesa tarjetas esté soportado. Operar sobre una plataforma sin mantenimiento es difícil de defender ante una auditoría o ante una reclamación.

No es una actualización, es una reconstrucción

Lo primero que hay que entender es que migrar de Magento 1 a Magento 2 no es una actualización. La arquitectura es completamente diferente: nuevo framework, nuevo sistema de temas, nuevo ORM, nuevas APIs. Los módulos de Magento 1 no funcionan en Magento 2. Es, en la práctica, montar una tienda nueva y migrar los datos.

Esa diferencia tiene consecuencias de calendario y de presupuesto que conviene asumir desde el principio. El proyecto no se mide en semanas de «actualización» sino en meses de construcción, con las mismas fases que un desarrollo nuevo: análisis, diseño, implementación, pruebas y despliegue. Y como la tienda antigua sigue vendiendo mientras tanto, hay que mantener dos entornos vivos y sincronizar los datos al final.

Qué se puede migrar automáticamente

Magento ofrece una herramienta oficial de migración de datos que transfiere: catálogo de productos (con atributos, categorías e imágenes), clientes y direcciones, pedidos históricos, configuraciones de impuestos y reglas de precios. La migración de datos suele funcionar bien, aunque requiere revisión y limpieza posterior.

Matiz importante en 2026: esa herramienta —el Data Migration Tool— sigue existiendo y sigue cubriendo las versiones de origen habituales (Magento Open Source 1.6 a 1.9 y Magento Commerce 1.11 a 1.14), pero su mantenimiento recae hoy en la comunidad y sus versiones publicadas van por detrás del core. Traducido a la práctica: no des por hecho que funcionará sin fricción contra la última rama de Magento 2, presupuesta tiempo de ajuste y prueba la migración completa en un entorno de trabajo antes de comprometer una fecha. Para catálogos grandes o estructuras de datos muy personalizadas, muchos equipos acaban combinando la herramienta con scripts propios de extracción y carga.

Un consejo que ahorra semanas: aprovecha para limpiar antes de migrar, no después. Productos descatalogados hace años, atributos que nadie usa, cuentas de cliente sin un solo pedido, pedidos de prueba. Todo lo que arrastres multiplica el tiempo de cada pasada de migración y la superficie de revisión posterior. Una auditoría previa del catálogo suele reducir el volumen real a migrar de forma notable.

Qué NO se puede migrar

Los themes no son compatibles en absoluto. Necesitarás un tema nuevo basado en la arquitectura de Magento 2. Las extensiones tampoco: cada módulo de terceros necesita ser reemplazado por su equivalente en Magento 2 o desarrollado a medida. Las personalizaciones del core necesitan reimplementarse usando los mecanismos de Magento 2 (plugins, observers, preferences).

A esa lista hay que sumarle dos puntos que se olvidan sistemáticamente y que tienen impacto directo en la facturación:

• El SEO acumulado. Las URLs de Magento 2 no coinciden con las de Magento 1. Si no preparas un mapa completo de redirecciones 301 —producto a producto, categoría a categoría— pierdes el posicionamiento que has tardado años en construir. Es el error más caro de toda la migración y el más fácil de evitar: se resuelve con una exportación de las URLs actuales y una tabla de equivalencias antes del cambio, no después.
• Las integraciones. Conectores con el ERP, con el TPV físico, con la plataforma logística o con el marketplace: todos hablan con las APIs de Magento 1 y ninguno funciona contra las de Magento 2. Hay que rehacerlos. Si tu tienda vive de esa sincronización, ese trabajo es el camino crítico del proyecto, no un detalle final. Lo desarrollamos en la guía sobre integraciones API entre ecommerce, ERP, logística y pagos.

También cambia el checkout, que en Magento 2 es una aplicación JavaScript distinta. Cualquier personalización del proceso de compra —pasos añadidos, campos extra, lógica de portes— se reconstruye con otro modelo de programación. Si el checkout actual está muy tocado, merece la pena aprovechar para simplificarlo; tenemos un artículo dedicado a cómo optimizar el checkout de un ecommerce.

El estado de Magento en 2026: versiones, PHP y fechas

Antes de planificar nada conviene saber contra qué versión vas a construir, porque los requisitos han cambiado bastante y marcan la infraestructura que necesitas:

• Magento 2.4.9 es la rama actual: alcanzó disponibilidad general el 12 de mayo de 2026, tanto en Magento Open Source como en Adobe Commerce.
• Exige PHP 8.4 u 8.5. PHP 8.2 ya no está soportado y PHP 8.3 solo se admite como paso intermedio durante la actualización, no como destino.
• La ventana de soporte de 2.4.9 es de tres años desde su publicación, es decir parches de seguridad hasta aproximadamente mayo de 2029.
• La rama 2.4.7 deja de tener soporte el 9 de abril de 2027. Si migras a esa versión porque «es la que conoce el equipo», estás comprando poco más de un año de tranquilidad.

La lectura práctica es sencilla: si vas a hacer el esfuerzo de migrar, hazlo contra la rama más reciente. El sobrecoste de construir sobre 2.4.9 en lugar de sobre una versión anterior es marginal comparado con el de repetir la actualización dos años después. Y verifica el requisito de PHP con tu proveedor de hosting antes de firmar nada: un servidor que hoy no puede darte PHP 8.4 es un bloqueo al principio del proyecto, no un detalle de última hora.

Ese salto de versión también condiciona las extensiones que elijas: un módulo que no declare compatibilidad con 2.4.9 y PHP 8.4 es un riesgo asumido, no una opción. La disciplina de revisar y actualizar ese inventario no acaba con la migración; es una rutina permanente, como explicamos en el artículo sobre por qué el mantenimiento de módulos ecommerce es crítico.

Estrategia de migración recomendada

Recomendamos un enfoque en fases: primero, auditar la tienda actual (extensiones, personalizaciones, integraciones). Segundo, diseñar la arquitectura de la nueva tienda identificando qué funcionalidades se mantienen, cuáles se eliminan y cuáles se mejoran. Tercero, desarrollar la nueva tienda en paralelo mientras la antigua sigue operativa. Cuarto, migrar datos y hacer un cutover planificado.

Fase 1: auditar de verdad

La auditoría no es «hacer una lista de módulos». Es responder, extensión por extensión, a tres preguntas: ¿alguien la usa?, ¿existe equivalente en Magento 2?, ¿cuánto cuesta el equivalente o su desarrollo a medida? El resultado es un inventario con coste asociado, que es lo que convierte la migración en un presupuesto defendible en lugar de una estimación a ojo. Si no tienes ese inventario, una auditoría de código previa es la inversión que más dinero ahorra en todo el proyecto.

En esta fase aparecen casi siempre dos sorpresas: funcionalidades críticas que dependen de un módulo abandonado sin sustituto directo, y personalizaciones del core que nadie documentó y que solo se descubren leyendo el código.

Fase 2: diseñar, que también es decidir qué se tira

Migrar una tienda es la única ocasión razonable para eliminar funcionalidad. Lo que se mantiene «por si acaso» se paga en desarrollo, en pruebas y en mantenimiento durante los próximos años. Sé explícito: una lista de lo que se mantiene, otra de lo que desaparece y otra de lo que se rehace mejor. Y que esas listas las firme quien tiene autoridad sobre el negocio, no solo el equipo técnico.

Fase 3: desarrollar en paralelo

La tienda antigua sigue vendiendo, así que el desarrollo ocurre en un entorno separado. Dos cosas que conviene dejar montadas desde el primer día: control de versiones con despliegues automatizados, y un juego de pruebas del recorrido de compra completo. En Magento 2 el checkout tiene suficientes piezas móviles como para que probar a mano cada cambio deje de ser viable enseguida.

Fase 4: migrar datos con ensayos

La migración de datos no se hace una vez. Se hace muchas: una primera pasada completa, y después deltas incrementales que traen los pedidos y clientes nuevos generados mientras el proyecto avanza. Cada ensayo debe cronometrarse, porque la duración de la pasada final determina cuánto tiempo estará la tienda en modo mantenimiento durante el cambio.

Fase 5: cutover sin sorpresas

El día del cambio se decide por anticipado, con una lista escrita: congelar pedidos, última pasada de datos, verificación del catálogo y los precios, activación de las redirecciones 301, cambio de DNS, prueba de un pedido real con pago, y vigilancia de errores y de la tasa de conversión durante las primeras 48 horas. Igual de importante: tener definido el criterio de vuelta atrás y a quién corresponde tomar esa decisión. Elige una ventana de bajo tráfico y evita las semanas de campaña.

Cuánto cuesta y cuánto dura (rangos realistas)

No hay una cifra única, pero sí tres variables que explican casi toda la diferencia entre un proyecto de tres meses y uno de un año:

• Número de extensiones con lógica de negocio. Veinte módulos estéticos pesan mucho menos que cinco que tocan precios, portes o facturación.
• Grado de personalización del core. Cuanto más se haya tocado Magento 1 por dentro, más análisis hace falta para reproducir el comportamiento con los mecanismos correctos de Magento 2.
• Número y criticidad de las integraciones. Un ERP sincronizando stock y pedidos en tiempo real es, por sí solo, un subproyecto.

A ese cálculo hay que añadirle el coste recurrente: hosting adecuado para PHP 8.4 con Elasticsearch/OpenSearch y caché, licencias de extensiones, y un contrato de mantenimiento. Magento 2 no es caro de construir y barato de tener; es exigente en ambos lados. Si ese modelo de coste no encaja con el tamaño del negocio, la conclusión honesta puede ser que la plataforma no es la adecuada, y eso nos lleva al siguiente punto.

Alternativas a considerar

Antes de asumir que Magento 2 es el destino, evalúa si tu negocio realmente necesita Magento. Si tu catálogo tiene menos de 10.000 productos y no necesitas lógica B2B compleja, WooCommerce o Shopify pueden ser opciones más eficientes y económicas de mantener. La migración es un buen momento para replantear la plataforma.

Esa comparación merece hacerse con criterios, no por intuición. Magento 2 sigue siendo la opción fuerte cuando hay catálogos muy grandes, múltiples tiendas o idiomas bajo una misma instalación, precios por cliente o por grupo, y reglas de negocio que ninguna plataforma cerrada permite expresar. Fuera de esos casos, el coste de propiedad juega en contra.

• Shopify elimina el mantenimiento de infraestructura y de core, a cambio de un modelo de comisiones y de menos libertad en el checkout. Si te planteas esta ruta, la guía técnica de migración de Magento a Shopify detalla el proceso y sus límites.
• PrestaShop 9 es un punto intermedio razonable para catálogos medianos que quieren seguir en código abierto sin la exigencia operativa de Magento; lo cubrimos en la guía de migración de Magento a PrestaShop 9.
• WooCommerce encaja bien cuando el contenido y el SEO pesan tanto como la venta, y el equipo ya conoce WordPress.

Si la duda es más de fondo —si conviene una plataforma o un desarrollo propio—, hemos tratado ese dilema en desarrollo a medida frente a plataforma ecommerce y en la guía para elegir plataforma de ecommerce en 2026. Y si lo que quieres es una valoración específica de si Magento sigue mereciendo la pena hoy, está en Magento y Adobe Commerce en 2026: ¿vale la pena?.

Errores que vemos repetirse en estas migraciones

• Dejar el SEO para el final. El mapa de redirecciones se prepara durante el proyecto, no la noche del cambio.
• Migrar la basura. Arrastrar catálogo muerto y clientes fantasma alarga cada pasada y contamina la tienda nueva desde el día uno.
• Replicar el diseño antiguo tal cual. Se pierde la oportunidad de mejorar y se paga por reproducir soluciones pensadas para otra arquitectura.
• Un solo ensayo de migración de datos. Sin repeticiones cronometradas no se puede prometer una ventana de corte.
• Olvidar la formación del equipo. El panel de Magento 2 no se parece al de Magento 1; sin formación, la tienda nueva se usa peor que la vieja durante meses.
• No auditar la seguridad del resultado. Salir de una plataforma insegura no garantiza llegar a una segura: conviene una auditoría de seguridad orientada a ecommerce antes de abrir al público.

Conclusión

Migrar de Magento 1 a Magento 2 no es un proyecto técnico que se pueda aplazar indefinidamente: cada mes sobre una plataforma sin parches aumenta la probabilidad de un incidente que costará mucho más que la migración. Pero tampoco es un salto que se improvise: exige auditoría previa, decisiones de negocio sobre qué se conserva, un plan de redirecciones y ensayos de datos cronometrados.

Y sobre todo exige una decisión honesta al principio: si tu tienda encaja en Magento, hazlo bien y contra la rama actual; si no encaja, este es el momento de cambiar de plataforma y no dentro de tres años.