Migrar de Magento a PrestaShop 9: reduce costes sin perder funcionalidad

Migrar de Magento (Adobe Commerce) a PrestaShop 9 es una tendencia creciente entre empresas medianas que encuentran que Magento se ha vuelto demasiado costoso de mantener. Con las licencias de Adobe Commerce, la complejidad del stack técnico (Elasticsearch, Varnish, Redis, RabbitMQ) y la necesidad de desarrolladores especializados, PrestaShop 9 se presenta como una alternativa moderna, más ligera y con un coste de propiedad significativamente menor.

El argumento se ha reforzado en 2026. PrestaShop 9.1 ya está disponible con Symfony 6.4 LTS, soporte de PHP desde la 8.1 hasta la 8.5, el tema Hummingbird 2.0 y una Admin API construida sobre API Platform; el soporte de seguridad de la rama alcanza como mínimo 2027. En paralelo, Magento Open Source publicó la 2.4.9 en mayo de 2026 —un salto grande de infraestructura, con PHP 8.5 y la sustitución de Laminas MVC, TinyMCE y Zend Cache— que vuelve a recordar lo que cuesta mantenerse al día en esa plataforma.

Esta guía recorre el proceso completo de migración y añade lo que hace falta para decidir con criterio: qué se gana de verdad, qué se pierde, cuánto cuesta, qué errores se repiten y cuándo la respuesta correcta es quedarse donde estás.

Magento y PrestaShop 9 en 2026: qué ha cambiado

La comparación ya no es la de hace tres años. PrestaShop dio un salto generacional con la rama 9: adopción completa de Symfony 6.4 LTS, mejoras de rendimiento y consumo de memoria, y un tema base —Hummingbird 2.0— que supera el 95 % de cumplimiento de los requisitos de la European Accessibility Act de serie. Para una tienda europea eso deja de ser un detalle estético y pasa a ser una obligación legal resuelta sin desarrollo adicional; lo detallamos en accesibilidad en ecommerce con PrestaShop 9, WCAG y Hummingbird.

La 9.1 suma además dos funcionalidades experimentales relevantes —gestión multi-transportista y un nuevo gestor de descuentos— y varios hooks nuevos para desarrolladores de módulos. Las repasamos en las novedades de PrestaShop 9.1.

Del lado de Magento, lo que ha cambiado es sobre todo el mapa de producto: Adobe convive hoy con tres modelos de despliegue (Cloud Service en SaaS, Cloud Infrastructure en PaaS y Commerce Optimizer), mientras Magento Open Source sigue con releases activas. Si tu duda de fondo es si merece la pena seguir ahí, lo analizamos en Magento y Adobe Commerce en 2026: ¿vale la pena? y en Adobe Commerce cloud vs on-premise.

¿Por qué migrar de Magento a PrestaShop 9?

• Coste de infraestructura: Magento requiere servidores potentes y stack complejo. PrestaShop funciona en hosting estándar LAMP.
• Coste de desarrollo: Desarrolladores Magento son escasos y caros. El ecosistema PrestaShop/Symfony es más accesible.
• Mantenimiento simplificado: Actualizaciones de Magento son complejas y arriesgadas. PrestaShop 9 con Symfony moderniza este proceso.
• Rendimiento: PrestaShop es más ligero y rápido out-of-the-box para la mayoría de catálogos.
• Admin API moderna: PrestaShop 9 introduce API Platform, comparable a la REST/GraphQL API de Magento pero más sencilla de implementar.

Dónde se nota el ahorro

El punto que más pesa no suele ser la licencia, sino lo que desaparece alrededor. Una instalación Magento en producción arrastra servicios que hay que dimensionar, monitorizar y parchear por separado: buscador, caché de página, caché de objetos y cola de mensajes. PrestaShop no exige ninguno de ellos para funcionar. Eso significa menos superficie de infraestructura, menos piezas que pueden fallar de madrugada y un perfil de hosting radicalmente más barato.

Partida	Magento / Adobe Commerce	PrestaShop 9
Licencia	Open Source gratuito · Adobe Commerce con presupuesto anual según GMV	Gratuito (open source)
Infraestructura	Servidor dedicado o cloud gestionado con servicios auxiliares	Hosting LAMP estándar o VPS modesto
Perfil del equipo	Desarrollador Magento especializado	Desarrollador PHP/Symfony
Actualizaciones	Saltos mayores planificados como proyecto	Ciclo más corto y previsible dentro de la rama 9
Módulos	Extensiones de precio alto y mantenimiento por versión	Catálogo amplio y más económico

La contrapartida honesta: PrestaShop tiene un ecosistema de módulos de calidad muy desigual y menos capacidad nativa para escenarios enterprise. El ahorro es real, pero se paga en criterio a la hora de elegir qué instalas. En mantenimiento de módulos en PrestaShop 9 explicamos por qué los overrides y los hooks mal usados son la principal fuente de problemas al actualizar.

¿Cuándo NO migrar?

• Catálogos de +100.000 SKUs: Magento gestiona catálogos masivos con flat tables e indexación avanzada. PrestaShop puede requerir optimización.
• Multi-website complejo: Magento permite tiendas con catálogos, precios y dominios completamente independientes.
• B2B enterprise: Adobe Commerce B2B tiene funcionalidades de cotización, approval workflows y shared catalogs muy avanzadas.

A esa lista añadimos un cuarto caso que vemos a menudo: haber invertido mucho en desarrollo a medida sobre Magento. Si tu ventaja competitiva vive en módulos propios —una lógica de precios particular, un configurador de producto, una integración profunda con producción— migrar no es mover datos, es reescribir software. Ese coste se subestima sistemáticamente en la fase de decisión.

Sobre el primer punto conviene matizar: el problema no es el número de SKUs en abstracto, sino la combinatoria. Un catálogo de 120.000 referencias planas funciona bien en PrestaShop 9 con una configuración cuidada; 20.000 productos con muchas combinaciones y decenas de características filtrables dan más guerra. Merece la pena medirlo antes, con datos reales, en lugar de decidir por una cifra redonda. Y si lo que ocurre es que tu Magento va lento, revisa primero la optimización de rendimiento de Magento 2 en catálogos grandes: puede que el problema sea la implementación y no la plataforma.

La opción de quedarse y ordenar

Antes de dar la migración por decidida, pon sobre la mesa la alternativa barata: mantener Magento y arreglar lo que duele. Un plan serio de hardening y parcheo, una limpieza de módulos que ya nadie usa y una auditoría técnica que separe lo que es plataforma de lo que es implementación cuestan una fracción de lo que cuesta migrar. Si después de eso el coste sigue siendo insostenible, migrar deja de ser una huida hacia adelante y pasa a ser una decisión con números detrás.

Proceso de migración

1. Auditoría Magento

• Documentar custom modules, themes y overrides.
• Exportar catálogo completo con atributos, configurable products, bundles y grouped products.
• Mapear attribute sets a la estructura de atributos de PrestaShop.
• Listar integraciones activas (ERP, PIM, logística).

A esa auditoría le añadimos siempre dos cosas. La primera, una decisión explícita por cada desarrollo a medida: se replica como módulo PrestaShop, se sustituye por un módulo del marketplace, se rehace de otra forma o se abandona. Dejar esa clasificación para «más adelante» es la causa número uno de migraciones que se alargan. La segunda, un censo de URLs con tráfico real sacado de Search Console, no solo del sitemap: el mapa de redirecciones se construye sobre lo que Google conoce, y ahí siempre aparecen URLs antiguas que nadie tenía inventariadas.

2. Mapeo de datos

Magento	PrestaShop 9	Notas
Configurable Product	Producto con Combinaciones	Mapear attribute options a combinaciones PS
Simple Product	Producto Simple	Mapeo directo
Category (multinivel)	Categoría (multinivel)	Ambos soportan jerarquía
Attribute Set	No tiene equivalente directo	Usar características y atributos por producto
CMS Block/Page	CMS Page	Adaptar widgets a módulos PS
Customer Group	Grupo de clientes	Mapeo directo con precios por grupo
Catalog Price Rule	Regla de precio específica	Funcionalidad similar
Cart Price Rule	Regla de carrito	Funcionalidad similar

Dos matices que ahorran disgustos. El primero es la distinción de PrestaShop entre atributos (generan combinación y afectan a stock y precio) y características (son informativas y no generan combinación). En Magento esa frontera no existe igual, así que un atributo de Magento puede acabar en un sitio o en otro según cómo se use. Decidirlo producto a producto antes de importar evita tener que rehacer el catálogo después.

El segundo es la ausencia de attribute sets. Magento agrupa qué atributos aplican a qué familia de producto; PrestaShop no tiene ese concepto y lo resuelve de forma más manual. En catálogos grandes conviene reconstruir esa agrupación con una convención de características y, si hace falta, apoyarse en el PIM que ya tengas en lugar de replicar la lógica dentro de la tienda.

Y una nota sobre la jerarquía de categorías: que ambas plataformas la soporten no significa que se traslade sola. Hay que decidir qué hacer con las categorías ancla de Magento, con los filtros por capas y con las reglas de visibilidad, porque de eso dependen las páginas que más tráfico orgánico reciben.

3. Exportación y transformación

• Magento CLI: bin/magento export para productos y clientes.
• SQL directo: Para exportaciones complejas de la estructura EAV.
• Herramientas: Cart2Cart o LitExtension para migración automatizada Magento→PrestaShop.

En catálogos medianos o grandes la exportación acaba casi siempre en SQL. La estructura EAV reparte los valores de un mismo producto entre varias tablas según el tipo de dato, así que reconstruir la ficha completa exige unir catalog_product_entity con las tablas _varchar, _int, _decimal y _text pasando por eav_attribute. Merece la pena escribir esa consulta una vez, dejarla versionada y poder relanzarla: durante una migración el catálogo se exporta muchas más veces de las previstas.

Sobre las herramientas automatizadas, un consejo de campo: sirven muy bien para el grueso del catálogo y para clientes, y bastante mal para todo lo que sea particular de tu tienda. Lo razonable es usarlas para el 80 % repetitivo y tratar a mano el 20 % que tiene lógica propia, en lugar de esperar que resuelvan el proyecto entero.

Y exporta también lo que no es catálogo: suscriptores, cupones activos, reseñas, direcciones de cliente y el histórico de pedidos. Verifica los totales tras cada extracción —número de filas, suma de importes, productos sin imagen, referencias duplicadas— antes de dar el fichero por bueno.

4. Importación en PrestaShop 9

• Importar categorías primero (mantener jerarquía).
• Importar productos con sus combinaciones y características.
• Importar clientes y direcciones.
• Importar pedidos históricos.
• Configurar reglas de precios y descuentos.

El orden de esa lista no es decorativo: importar productos antes que categorías, o combinaciones antes que atributos, obliga a repetir el proceso. Conviene además hacer una pasada de prueba completa sobre una copia antes de la definitiva, y comparar recuentos entre origen y destino en cada paso.

Dos avisos prácticos. Las imágenes son la parte más lenta de cualquier importación: mantén el servidor Magento accesible hasta que estén todas verificadas y haz un recuento final de productos sin imagen. Y en pedidos históricos, decide pronto hasta dónde llegas: dos años suelen cubrir devoluciones, garantías y analítica de recurrencia, mientras que importar todo el histórico multiplica el tiempo de proceso sin aportar mucho más.

5. Integraciones

Reconectar las integraciones críticas usando la nueva Admin API de PrestaShop 9 (basada en API Platform):

• ERP: Adaptar conectores de Magento REST API a PS Admin API.
• PIM: Si usas Akeneo u otro PIM, reconfigurar el conector.
• Logística: Adaptar módulos de transportistas.
• Pagos: Instalar módulos de pasarelas equivalentes.

La Admin API es probablemente la mejor noticia técnica de la rama 9 para quien viene de Magento: está construida sobre API Platform, habla el mismo lenguaje que cualquier integración REST moderna y evita tener que pelearse con el viejo webservice de PrestaShop. La cubrimos en la Admin API de PrestaShop 9 para desarrolladores, y el panorama general de conexiones entre tienda, ERP y logística en integraciones API entre ecommerce, ERP, logística y pagos.

El punto que más se subestima al presupuestar: los conectores no se migran, se rehacen. La lógica de sincronización que tu equipo escribió dentro de Magento —qué se sincroniza, cada cuánto, qué pasa ante un conflicto de stock— no viaja con los datos. Hay que reconstruirla y volver a probarla con casos reales.

6. SEO y lanzamiento

• Redirecciones 301 masivas (estructura de URLs muy diferente).
• Migrar meta titles, descriptions y URL keys.
• Verificar structured data (schema.org).
• Monitorizar indexación post-migración.

Las dos estructuras de URL no se parecen: Magento sirve rutas del tipo /catalog/product/view/id/123 o categorías terminadas en .html, mientras PrestaShop construye las suyas a partir del id y el link_rewrite según el formato configurado. El orden de trabajo que menos disgustos da es exportar los url_rewrite de Magento, cruzarlos con las URLs que Search Console reporta con impresiones, generar el mapa 301 completo y cargarlo antes de tocar los DNS. Después, revisar a diario los 404 durante las dos primeras semanas.

Presta atención especial a las paginadas, a las URLs con parámetros de filtro y a las variantes de idioma, que son las que más se olvidan. Y aprovecha el cambio para revisar el SEO técnico de la tienda en lugar de arrastrar tal cual lo que había.

7. Los primeros 30 días

Una migración no termina cuando cambian los DNS. El primer mes es el que decide cómo se recuerda el proyecto:

• Días 1-3: vigilar 404 en logs y en Search Console, comprobar que el sitemap nuevo está enviado y que no ha quedado ningún noindex ni robots de preproducción.
• Semana 1: comparar conversión y ticket medio con la línea base previa; revisar el embudo de compra paso a paso y confirmar que los emails transaccionales salen correctamente.
• Semanas 2-3: seguimiento de posiciones por grupo de URLs (producto, categoría, contenido) en lugar de mirar el orgánico agregado. Una oscilación es normal; una caída sostenida en un grupo concreto no lo es.
• Semana 4: revisión de Core Web Vitals con INP sobre datos de campo, ya con tráfico suficiente, y desinstalación de los módulos que se probaron durante el proyecto y no se usan.

Coste y plazos orientativos

Los rangos dependen del tamaño y la complejidad del catálogo, del número de integraciones vivas y de cuánto desarrollo a medida haya que rehacer:

Perfil de tienda	Alcance típico	Plazo
Catálogo simple, pocas integraciones	Migración de datos, Hummingbird adaptado, redirecciones	4-8 semanas
Catálogo medio con combinaciones y ERP	Lo anterior + mapeo de atributos y características, integración ERP y logística	2-4 meses
Catálogo grande con desarrollo propio	Lo anterior + módulos a medida, multi-idioma y multi-tienda	4-8 meses

Frente a Shopify u otras opciones SaaS, aquí el coste recurrente es mucho menor —hosting y mantenimiento, sin comisión por transacción ni suscripciones de app— pero la responsabilidad operativa vuelve a ser tuya. Es exactamente el intercambio contrario al de una migración de Magento a Shopify, y por eso conviene tener claro qué modelo encaja con tu equipo antes de elegir destino. Si aún estás en esa fase, la guía para elegir plataforma ecommerce en 2026 y la comparativa entre Shopify, WooCommerce y PrestaShop ponen el marco. Un ejemplo real de cómo se ordena un proyecto así está en esta migración de un fabricante del Maresme.

Rendimiento, seguridad y cumplimiento después de migrar

En rendimiento, PrestaShop 9 parte con ventaja por ser más ligero, pero el techo lo marcan el hosting, el tema y los módulos instalados. Una tienda con veinte módulos que inyectan CSS y JavaScript en el front puede rendir peor que un Magento bien afinado. Mide INP y LCP con datos de campo una vez estabilizado el tráfico, no con una prueba de laboratorio el día del lanzamiento.

En seguridad, al seguir siendo autogestionado el modelo de responsabilidad no cambia: actualizaciones de core y módulos, permisos, copias de seguridad y monitorización siguen siendo tuyos. Es el precio del control. Conviene planificar el mantenimiento de módulos desde el primer día y considerar una auditoría de seguridad del ecommerce una vez la tienda esté en producción. Si tu empresa trabaja con requisitos formales de seguridad, el enfoque de desarrollo seguro alineado con ISO 27001 y ENS aplica igual aquí.

Y en cumplimiento, el argumento de accesibilidad juega a favor: llegar a Hummingbird 2.0 con la mayor parte del trabajo EAA resuelto de serie ahorra un proyecto entero que en Magento habría que abordar desde cero.

Ocho errores frecuentes en migraciones Magento → PrestaShop

1. Migrar el catálogo tal cual. Es la mejor oportunidad para eliminar referencias muertas, duplicados y atributos que nadie usa. Arrastrarlo todo hereda el desorden y multiplica el trabajo.
2. Confundir atributos con características. Si un atributo que debía generar combinación acaba como característica informativa, el stock y los precios dejan de cuadrar.
3. Construir el mapa de redirecciones solo con el sitemap. Sin cruzarlo con Search Console, se pierden las URLs antiguas que aún reciben tráfico y enlaces.
4. Dar por hecho que un módulo equivale a una extensión. Nombres parecidos, comportamientos distintos. Hay que probar cada módulo con datos reales antes de comprometerse.
5. Resolver a base de overrides. Es la vía rápida y la que hace imposible actualizar después. Siempre que se pueda, hooks y módulos limpios.
6. Importar en el orden equivocado. Categorías, atributos, productos, combinaciones, clientes, pedidos. Saltarse el orden obliga a repetir.
7. No congelar el catálogo durante el corte. Si se siguen editando productos y precios en Magento mientras se importa, el delta final es inasumible.
8. Apagar Magento demasiado pronto. Mantén el origen accesible varias semanas: imágenes, datos que falten y comprobaciones de verificación dependen de él.

Preguntas frecuentes

¿Se pierde posicionamiento al migrar de Magento a PrestaShop 9?

Hay casi siempre una oscilación de algunas semanas mientras Google reprocesa las URLs nuevas. Que se convierta o no en una pérdida real depende de tres cosas: el mapa de redirecciones 301, la conservación de títulos, meta descripciones y contenido de las páginas de categoría, y el rendimiento del tema nuevo. Con eso bien hecho, lo normal es recuperar la línea base en uno o dos meses.

¿Puedo conservar el histórico de pedidos?

Sí. Se importa vía CSV o a través de la Admin API, y es muy recomendable: sin él pierdes devoluciones, garantías, atención al cliente y toda la analítica de recurrencia. Dos años suelen ser suficientes para la mayoría de tiendas.

¿Qué pasa con mis módulos de pago y transporte?

Se sustituyen por los módulos equivalentes de PrestaShop. Las pasarelas habituales tienen módulo oficial; los transportistas dependen del mercado, y la gestión multi-transportista experimental de la 9.1 abre opciones que antes exigían desarrollo. Conviene verificar la disponibilidad antes de cerrar el alcance del proyecto.

¿PrestaShop 9 aguanta un catálogo grande?

Sí, con una configuración cuidada. Lo que marca la diferencia no es el número de referencias sino la combinatoria y los filtros: muchas combinaciones y muchas características filtrables piden más trabajo de optimización. Mídelo con tus datos reales antes de decidir.

¿Cuánto tiempo hay que mantener Magento encendido?

Como mínimo hasta que la importación esté verificada y las imágenes servidas desde el destino; en la práctica, entre cuatro y ocho semanas después del cambio de DNS. Es un coste pequeño comparado con necesitar un dato y no tenerlo.

¿Y si ya estoy en PrestaShop 1.7?

Entonces no tienes una migración de plataforma sino una actualización de rama, que es un proyecto distinto y bastante más acotado. Lo cubrimos en la guía para migrar de PrestaShop 1.7 a PrestaShop 9.

¿Necesitas ayuda?

En Keliam realizamos migraciones de Magento a PrestaShop 9 completas. Contacta con nosotros para evaluar tu proyecto.