Migración de PrestaShop a Shopify: lo que se rompe no es el catálogo

Migrar de PrestaShop a Shopify consiste en mover un catálogo, sí. Pero también en reconstruir todo lo que colgaba de ese catálogo: las URLs que Google lleva años indexando, el histórico comercial, y los campos estructurados que hacen que un producto sea encontrable. Los productos son la parte fácil y automatizable. El resto es el proyecto de verdad.

Es la parte que ninguna página de servicio te cuenta, porque contarla complica la venta.

La pregunta que todo el mundo hace primero

"¿Se pueden pasar los productos?" Sí. Se pueden.

Títulos, descripciones, precios, variantes, imágenes, stock. Eso se exporta, se transforma y se importa. Es trabajo, pero es trabajo resuelto: hay formato, hay herramientas y hay procedimiento. Si alguien te vende la migración como si eso fuera el mérito, te está cobrando por la parte que menos riesgo tiene.

La pregunta correcta es otra: qué pasa con todo lo que no es el producto en sí.

Las URLs: donde se pierde el tráfico

PrestaShop y Shopify no comparten estructura de rutas, y no es un detalle cosmético.

Shopify impone sus prefijos: los productos viven bajo /products/, las categorías bajo /collections/, las páginas bajo /pages/. No es configurable. PrestaShop, en cambio, permite estructuras muy distintas —con identificadores numéricos, con categorías anidadas en la ruta, con extensión .html al final— y cada tienda tiene la suya según cómo se configuró en su día.

Consecuencia: no existe una regla automática que traduzca una estructura en la otra. Nadie puede escribir un patrón que convierta todas tus URLs viejas en las nuevas, porque la relación entre unas y otras no es sistemática. Es referencia por referencia.

Eso significa construir un mapa de redirecciones 301 a mano, línea a línea, para cada producto, cada categoría, cada página y cada artículo que tuviera tráfico o enlaces apuntando. Y significa decidir qué hacer con lo que no tiene destino evidente: productos descatalogados, categorías que ya no existen, filtros indexados que nunca deberían haberlo estado.

Este es el punto donde la mayoría de migraciones pierde tráfico. No porque Shopify sea peor, sino porque el mapa se hizo con prisa, se hizo parcial, o se dejó para después del lanzamiento. Cuando se detecta la caída, ya han pasado semanas y la autoridad acumulada durante años se ha ido por 404.

El histórico de pedidos no migra como imaginas

El segundo bloque que nadie audita antes de firmar.

Los pedidos históricos se pueden llevar a Shopify, pero no se comportan igual que los pedidos nativos. No es un problema técnico puntual: es que un pedido no es un registro aislado. Arrastra un cliente, unas direcciones, unos importes, unos impuestos aplicados con las reglas de entonces, unos estados que en la plataforma nueva quizá ni existan.

Por eso la decisión no es técnica, es de negocio, y hay que tomarla antes de tocar nada:

• Qué se conserva —¿todo el histórico, los dos últimos años, solo los clientes?
• Para qué se conserva —¿atención al cliente, contabilidad, segmentación comercial, obligación legal?
• Dónde vive después —¿dentro de la tienda, dentro del CRM, en un archivo frío al que se accede cuando hace falta?

Son tres preguntas y las tres tienen respuestas distintas según el negocio. Migrar el histórico "por si acaso" es la respuesta cara y normalmente la equivocada: pagas por mover datos que nadie va a consultar y ensucias la tienda nueva desde el día uno.

Los campos estructurados: aquí está la migración de verdad

Si tu catálogo vale por sus atributos y no por sus fotos, este apartado es tu migración. Todo lo anterior era el preámbulo.

En PrestaShop, los atributos que no son variantes suelen vivir como características, campos personalizados o desarrollos a medida sobre la base de datos. Cada tienda lo resolvió a su manera, y muchas lo resolvieron acumulando capas durante años.

Shopify tiene su propio modelo: metafields para atributos, metaobjects para entidades con estructura propia y relaciones entre ellas. Es un modelo bueno, pero es otro modelo.

Y aquí está el error de cálculo que hunde presupuestos: esto no es traducir, es rediseñar. No existe un mapeo campo a campo. Hay que decidir qué es un metafield y qué merece ser un metaobject, qué atributos deben ser filtrables, cuáles deben poder combinarse entre sí, y cómo se relacionan unos con otros para que el cliente encuentre lo que busca.

Un buscador que cruza varios criterios encadenados, por ejemplo, no se "migra". Se diseña desde cero sobre el modelo de datos nuevo, y luego se puebla. Si en el presupuesto ese trabajo aparece como una línea de "migración de datos", el presupuesto está mal hecho.

La dependencia que nadie audita: tu ERP

Y ahora la parte incómoda, la que hemos aprendido a mirar primero.

El bloqueo real de una migración casi nunca está en Shopify. Está aguas arriba, en el sistema que alimenta el catálogo.

Porque para poblar un modelo de datos estructurado necesitas que el origen emita datos estructurados. Y muy a menudo no lo hace: los atributos que necesitas viven en un campo de texto libre, escritos por personas distintas a lo largo de los años, con criterios distintos. O están en el nombre del producto. O en una descripción. O directamente no están en el ERP y viven en la cabeza de alguien del equipo.

Cuando eso pasa, la migración no se para por culpa de la plataforma destino. Se para porque no hay nada estructurado que migrar, y estructurarlo es un proyecto en sí mismo —de datos, no de web— que puede durar más que la propia migración.

Ninguna página de servicio de migración te va a contar esto, porque es exactamente el hallazgo que convierte un proyecto cerrado en un proyecto con dependencia externa. Nosotros preferimos decirlo antes de firmar. Si tu ERP no emite fitment, atributos o compatibilidades de forma estructurada, la migración tiene un techo y conviene saberlo el primer día, no el último. Esa desconexión entre el sistema comercial y la tienda tiene más síntomas de los que parece —los enumeramos en 12 señales de mala integración entre ecommerce B2B y CRM.

Cómo saber si merece la pena antes de mover nada

No siempre merece la pena. Lo decimos en serio.

Señales de que sí:

• Cada actualización de la plataforma te cuesta dinero, tiempo o un módulo roto.
• Dependes de un proveedor para cambios que deberían ser de un minuto.
• Tu catálogo tiene atributos claros y estructurados, o tu ERP puede emitirlos con trabajo acotado.
• El coste anual de mantener lo que tienes se acerca al coste de reconstruirlo bien.

Señales de que no, o todavía no:

• Tu ERP no emite datos estructurados y nadie ha presupuestado arreglarlo.
• Tienes desarrollos a medida críticos cuyo equivalente en Shopify nadie ha verificado que exista.
• Migras porque tu tienda "se ve antigua". Eso es un problema de tema, no de plataforma, y se arregla mucho más barato.
• Nadie ha contado cuántas URLs con tráfico hay que redirigir. Si no está contado, no está presupuestado.

El último punto es el que más veces hemos visto convertirse en factura sorpresa.

Antes de mover nada, una radiografía

La peor forma de empezar una migración es pidiendo presupuestos de migración. Todos te van a hablar del catálogo, que es la parte fácil, y ninguno va a haber mirado tu ERP.

Una auditoría de 397 € mira las cuatro cosas que deciden si esto sale bien: el mapa real de URLs con tráfico, qué hacer con el histórico, si tu catálogo es estructurable y qué emite hoy tu sistema de origen. Informe accionable en 7 días, con hallazgos concretos y prioridades. Sin llamadas comerciales.

Si después decides construir, sabes exactamente qué estás comprando y dónde están los riesgos. Y si decides no migrar todavía, también habrá servido: te habrás ahorrado un proyecto que se habría parado a mitad. Cuando toca construir, lo hacemos en Tienda en Shopify.