Las migraciones hacia PrestaShop fallan con mayor frecuencia cuando los registros están presentes, pero ha cambiado el significado de sus relaciones de tienda, idioma, combinación, módulo o lógica comercial. La prevención debe seguir la relación operativa que hay detrás de cada registro, no limitarse a comparar recuentos. Los diez problemas siguientes se centran en patrones recurrentes capaces de dejar un catálogo aparentemente completo mientras se debilitan la compra, el descubrimiento, el servicio o las integraciones.
Problema 1: convertir combinaciones en campos ordinarios de Product
Qué sale mal
Un Product de origen puede llegar con su registro base intacto y, aun así, perder su estructura de variaciones vendibles. En PrestaShop, las combinaciones contienen las diferencias de compra entre una opción vendible y otra; las características describen Products y los campos de personalización recogen valores introducidos por el comprador. Tratar estas tres capas como equivalentes puede crear Products duplicados, precios de variante ausentes, propiedad de stock incorrecta o una tienda que muestra información sin conservar la elección de compra prevista.
Señales tempranas
La señal no es un recuento bajo de Products, sino una diferencia entre lo que el comprador puede seleccionar y lo que el equipo puede gestionar. El mayor riesgo está en Products cuyas opciones cambian SKU, precio, peso, imagen, disponibilidad o stock.
| Señal | Significado probable | Preocupación inmediata |
|---|---|---|
| Toda opción se convirtió en característica | Se mezclaron estructuras descriptivas y vendibles | El Product puede mostrar elecciones que no controlan el artículo comprado |
| Cada combinación se convirtió en Product independiente | Se aplanó la relación padre-combinación | Categories, SEO y merchandising pueden fragmentarse |
| El stock existe solo en el Product base | No se conservó el inventario por combinación | Las opciones vendibles pueden sobre-venderse o parecer no disponibles |
Prevención
Clasifique cada opción de origen por función comercial antes de mapearla. Una elección que cambia el SKU comprado pertenece a combinaciones; un valor usado para comparación pertenece a características; el texto o archivo introducido por el comprador pertenece a personalización. Incluya Products representativos con varias dimensiones de opción, impacto en precio, imágenes y stock. Conserve identificadores externos estables cuando ERP o almacén reconozcan la combinación y no solo el Product padre.
Ejemplo recomendado
Para una chaqueta vendida por talla y color, mantenga un Product con combinaciones para las elecciones vendibles. Conserve SKU, impacto de precio, relación de imagen y stock de cada combinación. Mantenga "impermeabilidad" como característica y un mensaje de bordado opcional como personalización.
Condición de aprobación
El comprador puede seleccionar todas las opciones necesarias, se añade al carrito el SKU y precio correctos, el stock por combinación cambia de forma independiente cuando corresponde y el personal puede vincular cada elección vendible con el identificador operativo usado por sistemas conectados.
Problema 2: perder la propiedad multitienda aunque se conserven los registros
Qué sale mal
PrestaShop multitienda puede hacer que un mismo registro sea visible, tenga precio, traducción o configuración diferentes según tienda o grupo. Conservar Product, Category, Customer o CMS pero perder su contexto puede exponer el catálogo equivocado, mezclar contenido regional o asignar registros compartidos a una tienda donde nunca debieron aparecer.
Señales tempranas
El riesgo aumenta cuando se habla de "la tienda PrestaShop" como si fuera un único escaparate. Diferencias de dominio, idioma, moneda, catálogo, tema, precio o propiedad operativa indican que el contexto de tienda forma parte del significado.
| Área | Pregunta multitienda | Fallo si se ignora |
|---|---|---|
| Products y Categories | ¿Compartidos globalmente o asignados selectivamente? | Una tienda incorrecta puede publicar u ocultar el registro |
| Precios y promociones | ¿Compartidos o específicos de tienda? | Puede colapsar la lógica comercial regional |
| CMS y traducciones | ¿Contenido común o localizado por tienda? | Un mercado puede sobrescribir a otro |
Prevención
Cree una matriz de propiedad por tienda para cada familia de registros. Distinga los datos verdaderamente compartidos de los valores que cambian por tienda, idioma o región. Utilice identificadores explícitos de tienda en lugar de deducir propiedad por dominio o idioma. Si la plataforma de destino representa las tiendas de otra forma, defina la relación de destino de cada valor específico.
Ejemplo recomendado
Un comerciante opera tiendas francesa y belga con catálogo compartido, pero distintas descripciones, presentación fiscal y promociones. Conserve la identidad común del Product y asigne contenido y valores comerciales a las tiendas correctas.
Condición de aprobación
Cada tienda de destino expone únicamente Products, Categories, contenido, idioma y contexto comercial previstos; los registros compartidos siguen compartidos cuando corresponde y ningún valor específico se convierte silenciosamente en valor global.
Problema 3: migrar grupos de Customers sin su significado comercial
Qué sale mal
Los grupos de Customers pueden afectar visibilidad, precios, descuentos, presentación de impuestos o expectativas de acceso. Copiar nombres sin conservar las relaciones que controlan produce cuentas que parecen clasificadas en back office pero reciben un tratamiento ordinario en la tienda.
Señales tempranas
Las etiquetas pueden existir mientras desaparecen sus resultados comerciales. El riesgo aumenta cuando los grupos representan B2B, mayoristas, empleados, fidelización, impuestos o regiones.
| Señal | Qué sugiere | Efecto empresarial |
|---|---|---|
| Existen grupos pero todos ven un único precio | No se representó la relación de precios | Fallan expectativas mayoristas o negociadas |
| Products restringidos son visibles para todos | Se perdió la propiedad de visibilidad | Desaparecen controles de catálogo privado |
| La presentación fiscal es idéntica entre grupos | Se aplanó el contexto fiscal | Totales mostrados y cobrados pueden diferir de la política |
Prevención
Documente el resultado controlado por cada grupo, no solo su nombre. Mapee la relación Customer-grupo separadamente de la configuración de destino que le da significado. Consolide grupos duplicados u obsoletos de forma deliberada.
Ejemplo recomendado
Para un grupo mayorista, conserve la pertenencia del Customer y defina quién controla precios mayoristas, Products restringidos y presentación fiscal. No apruebe el grupo solo porque aparece la palabra "Wholesale" en el registro.
Condición de aprobación
Customers representativos entran en el contexto de cuenta correcto y reciben la visibilidad, precio, descuento y presentación fiscal previstos para su grupo.
Problema 4: romper el descubrimiento aunque se conserve el árbol de Categories
Qué sale mal
Una importación puede reproducir nombres y relaciones padre-hijo y, aun así, debilitar cómo los compradores encuentran Products. Navegación, filtrado por capas, características, merchandising y tema pueden depender de algo más que el árbol. Categories vacías, Products con Category predeterminada equivocada o características incompletas pueden volver difícil de explorar un catálogo aparentemente completo.
Señales tempranas
Los recuentos suelen parecer correctos. Las señales aparecen en rutas públicas, ubicación de Products, filtros y comportamiento de la Category predeterminada.
| Comprobación | Patrón de fallo | Por qué importa |
|---|---|---|
| Category predeterminada | El Product tiene varias asignaciones pero contexto principal incorrecto | Breadcrumbs y comportamiento canónico pueden cambiar |
| Cobertura de características | Los valores existen solo en parte de una familia | La navegación por filtros se vuelve incoherente |
| Profundidad | Se colapsaron o duplicaron ramas profundas | El comprador pierde rutas esperadas |
Prevención
Defina resultados de descubrimiento para familias representativas. Conserve todas las asignaciones necesarias e identifique la Category predeterminada cuando PrestaShop dependa de ella. Normalice nombres y valores de características antes de usarlos para filtrar. Retire Categories obsoletas solo con un destino de redirección o merchandising explícito.
Ejemplo recomendado
Para calzado, compruebe que un zapato sigue en Hombre, Running y Oferta conservando la Category predeterminada prevista. Confirme que talla, superficie e impermeabilidad tienen cobertura suficiente para el filtrado objetivo.
Condición de aprobación
Las familias prioritarias son accesibles por las rutas esperadas, breadcrumbs y contexto principal son coherentes, los filtros usan valores completos y normalizados y las ramas retiradas conducen a destinos útiles.
Problema 5: asumir que las URL amigables conservan automáticamente su identidad
Qué sale mal
Claves de URL, rutas reescritas, prefijos de idioma y rutas CMS no reproducen automáticamente la misma dirección pública en un nuevo entorno PrestaShop. Un registro puede existir mientras una ruta de alto valor cambia, colisiona o resuelve a la tienda o idioma equivocados.
Señales tempranas
Valores reescritos duplicados, sufijos de idioma inexplicables, ausencia de contexto de tienda o páginas prioritarias sin destino declarado.
| Tipo de ruta | Brecha habitual | Decisión necesaria |
|---|---|---|
| Product o Category | La ruta antigua no coincide con la estructura objetivo | Elegir destino canónico y redirigir la ruta de origen |
| Ruta multilingüe | Los slugs por idioma colapsan a un valor | Conservar destinos específicos por locale |
| CMS o campaña | La página existe bajo otra ruta | Actualizar enlaces internos y redirigir la ruta histórica |
Prevención
Construya un registro de rutas para Products, Categories, páginas CMS y campañas prioritarias. Incluya URL de origen, idioma, tienda, destino previsto y responsable de redirección. Compruebe unicidad. Conserve slugs significativos cuando sea viable, pero priorice un destino canónico coherente.
Ejemplo recomendado
Una ruta francesa y otra belga comparten nombre traducido, pero pertenecen a tiendas diferentes. Asigne cada una al destino correcto de tienda e idioma y redirija ambos históricos.
Condición de aprobación
Cada ruta histórica prioritaria llega directa o mediante una única redirección útil al Product, Category o CMS correcto, en la tienda e idioma previstos, sin bucles ni colisiones.
Problema 6: tratar módulos, overrides y lógica de tema como datos migrados
Qué sale mal
Los módulos y overrides pueden crear campos, alterar proceso de compra, añadir transportistas o pagos, cambiar presentación o guardar identificadores de integración. Los temas pueden determinar cómo se muestran estructuras. Copiar registros estándar no reproduce ese comportamiento, y copiar tablas de módulos sin entender quién las consume puede producir datos inútiles o inseguros.
Señales tempranas
Resultados empresariales críticos descritos solo por nombres de módulos, tablas personalizadas sin responsable o un tema de destino que espera campos y hooks diferentes.
| Dependencia | Pregunta | Responsable probable |
|---|---|---|
| Campo creado por módulo | ¿Qué proceso actual lo lee? | Módulo, integración o campo reestructurado |
| Override o código personalizado | ¿Qué comportamiento predeterminado modifica? | Implementación del destino, no migración de registros |
| Contenido de tema | ¿Es dato o configuración de presentación? | Configuración de tema/contenido del destino |
Prevención
Inventaríe módulos, overrides, tablas personalizadas, hooks y dependencias de tema por resultado empresarial. Conserve un valor solo cuando exista un consumidor de destino. Separe migración de registros de reinstalar, configurar, sustituir o reconstruir comportamiento. No arrastre datos de módulos inactivos solo porque existan en la base.
Ejemplo recomendado
Si un módulo guarda una referencia de proveedor usada por una exportación ERP, conserve esa referencia en un campo o registro de integración que el ERP de destino pueda consultar. No copie la tabla del módulo si este no existirá en el destino.
Condición de aprobación
Cada módulo u override crítico tiene responsable de destino, sus datos necesarios son legibles por ese responsable y ningún proceso se considera conservado solo porque se migraron registros estándar.
Problema 7: aplanar la propiedad de stock entre combinaciones y ubicaciones
Qué sale mal
El inventario puede parecer correcto a nivel de Product mientras las combinaciones vendibles tienen cantidad o disponibilidad incorrectas. Sistemas externos, historiales avanzados, feeds de almacén o inventario específico por tienda añaden capas de propiedad. Aplanarlas puede producir sobreventa, falsos agotados o una cantidad que el sistema conectado sobrescribe inmediatamente.
Señales tempranas
Una sola cantidad por Product, identificadores de combinación ausentes, stock negativo sin explicación o desacuerdo entre la tienda y un sistema externo indican un problema de propiedad.
| Señal de inventario | Causa probable | Control |
|---|---|---|
| El total del padre iguala la suma de variantes | Se ignoró propiedad por variante | Conservar cantidad o clave externa a nivel de combinación |
| La cantidad cambia después de sincronizar | El sistema externo sigue siendo autoridad | Definir saldo inicial y responsable posterior |
| Una tienda muestra stock de otra | Se aplanó contexto de tienda | Conservar relación tienda/ubicación |
Prevención
Declare el responsable autorizado del inventario para cada familia y ubicación. Conserve SKU de combinaciones e identificadores externos. Defina si la migración aporta saldo inicial, referencia histórica o valor continuo. Excluya tablas antiguas que ya no gobiernan disponibilidad.
Ejemplo recomendado
Para un Product con tallas gestionadas por almacén, migre la cantidad inicial por combinación y conserve el SKU de almacén. Después del corte, haga que la conexión del almacén vuelva a ser la autoridad.
Condición de aprobación
La combinación correcta está disponible en la tienda o ubicación correcta, los cambios de stock provienen del responsable previsto y toda cantidad puede reconciliarse con un identificador estable.
Problema 8: conservar Orders históricos sin su contexto explicativo
Qué sale mal
El total y estado de un Order no bastan para explicar qué ocurrió. Los Orders históricos pueden depender de combinaciones, grupos de Customers, impuestos, transportistas, descuentos, reembolsos, mensajes e historial de estados. Aplanar esas relaciones deja una transacción visible pero difícil de explicar.
Señales tempranas
Los Orders parecen completos en lista, pero son ambiguos al abrirlos: falta detalle de opción por línea, los estados son genéricos, faltan descuentos o el Customer está desconectado.
| Contexto de Order | Fallo si falta | Consecuencia |
|---|---|---|
| Combinación o personalización | No puede identificarse el artículo comprado | Devoluciones y soporte se vuelven poco fiables |
| Historial de estados y mensajes | Se pierde la secuencia operativa | No se puede explicar preparación de pedidos o cancelación |
| Líneas de descuento, impuestos y envío | No puede reconciliarse el total | Finanzas y soporte pierden confianza |
Prevención
Conserve identidad de Product a nivel de línea y contexto descriptivo de compra aunque el destino no pueda recrear cada estado heredado. Mapee estados por significado y no por parecido del nombre. Mantenga diferenciadas las líneas financieras y conserve números de Order e identificadores externos cuando otros sistemas los utilicen.
Ejemplo recomendado
Para un Order reembolsado con combinación de talla/color y un cupón, conserve descripción de la combinación, importes originales, línea de descuento, contexto de reembolso, asociación al Customer y referencia de origen.
Condición de aprobación
El personal puede identificar qué compró el Customer, cómo se formó el total, qué secuencia de estados ocurrió y qué contexto de reembolso o preparación de pedidos sigue siendo relevante sin consultar la tienda retirada.
Problema 9: trasladar una localización incoherente a un catálogo compartido
Qué sale mal
El contenido multilingüe suele contener traducciones parciales, slugs duplicados, texto fallback, diferencias HTML y campos de módulos traducidos de forma irregular. Copiar todos los valores exactamente como están puede mostrar contenido del idioma equivocado o dejar secciones vacías.
Señales tempranas
Products con nombre traducido pero descripción sin traducir, colisiones de slugs entre locales o contenido copiado entre tiendas que debería seguir separado.
| Problema | Resultado visible | Control |
|---|---|---|
| Falta valor de locale | Contenido vacío o fallback | Definir regla de fallback o finalización |
| Mismo slug en contextos incompatibles | Colisión de ruta o destino incorrecto | Asignar rutas por locale/tienda |
| Enlaces al dominio de origen | El cliente vuelve a la tienda antigua | Reescribir enlaces al destino |
Prevención
Audite la completitud por familia de registro y locale. Normalice codificación y HTML. Decida dónde se admite fallback y dónde el contenido incompleto debe permanecer sin publicar. Trate enlaces, referencias de medios y campos SEO como relaciones localizadas.
Ejemplo recomendado
Si un Product tiene contenido francés completo y solo nombre en inglés, publique francés normalmente, aplique la política de fallback aprobada y evite que una descripción inglesa incompleta herede un enlace francés al dominio de origen.
Condición de aprobación
Cada locale publicado muestra el idioma previsto, las rutas y medios funcionan en el contexto de tienda correcto y las traducciones ausentes siguen una regla deliberada.
Problema 10: conservar identificadores externos sin conservar quién los utiliza
Qué sale mal
Las bases de origen suelen contener IDs de ERP, claves de proveedor, IDs de marketplace, referencias heredadas y valores de módulos. Copiarlos a un campo de notas arbitrario conserva caracteres pero no función. Omitirlos puede romper conciliaciones y duplicarlos puede hacer que sistemas conectados actualicen el registro equivocado.
Señales tempranas
Los equipos pueden enumerar IDs pero no explicar qué sistema los posee, si deben ser únicos o cómo se consultarán tras la migración.
| Identificador | Pregunta sobre el consumidor | Requisito de destino |
|---|---|---|
| ID ERP de Product o combinación | ¿Qué sincronización lo usa? | Campo estable y único accesible por la integración |
| ID de listing de marketplace | ¿Sigue activo el listing? | Relación de canal continua o retirada deliberada |
| Referencia heredada de Order | ¿Quién la busca? | Referencia histórica visible y consultable |
Prevención
Cree un contrato de identificadores con campo de origen, propietario del registro, ubicación de destino, regla de unicidad, formato y sistema consumidor. Conserve solo identificadores activos o necesarios como evidencia. Mantenga separadas claves de Product padre y combinación. Pruebe búsqueda y actualización con la integración o proceso que continuará.
Ejemplo recomendado
Si un ERP actualiza stock por referencia de combinación, coloque esa referencia en la combinación vendible o registro de integración de destino. No la guarde solo en el Product padre ni en una nota que la sincronización no pueda consultar.
Condición de aprobación
Cada identificador requerido es único cuando corresponde, recuperable por su consumidor, está asociado al nivel de registro correcto y demuestra que soporta conciliación o integración.
Prioridades comunes de prevención
Los riesgos recurrentes pueden controlarse mediante tres líneas conectadas.
| Prioridad | Qué protege | Evidencia antes de aprobar |
|---|---|---|
| Conservar significado de combinaciones y stock | Combinaciones, atributos, ubicaciones e inventario vendible | Products representativos conservan elecciones, identificadores, propiedad de stock y disponibilidad correctos. |
| Conservar contexto multitienda y comercial | Propiedad por tienda, grupos de Customers, localización, Categories y precios | Los registros aparecen en tienda, idioma, moneda, grupo y contexto de navegación correctos. |
| Separar módulos e integraciones de los registros migrados | Overrides, temas, identificadores externos y consumidores operativos | Cada dependencia no central tiene responsable de destino, decisión de implementación y método de validación. |
Conclusión
Un resultado fiable en PrestaShop se construye mediante relaciones explícitas: Products con combinaciones, Categories con descubrimiento, Customers con grupos, registros con tiendas e idiomas y valores personalizados con módulos o integraciones que continuarán. Cuando estas relaciones se definen y prueban mediante escenarios empresariales representativos, la migración puede conservar cómo funciona la tienda y no únicamente lo que contiene la base de datos.
Preguntas frecuentes
¿Por qué las combinaciones de PrestaShop representan un riesgo importante?
Pueden contener diferencias de SKU, precio, imagen, peso y stock. Aplanarlas como características o Products separados cambia la estructura vendible y puede afectar carrito e inventario.
¿Multitienda exige copias separadas de todos los registros?
No necesariamente. Algunos datos pueden compartirse y otros ser específicos. La migración debe conservar la propiedad prevista en lugar de duplicarlo todo o tratar una tienda como universal.
¿Debe migrarse cada tabla de módulo?
No. Un registro de módulo debe conservarse solo cuando un componente de destino o proceso operativo que continuará lo necesite. No debe copiarse información inactiva u huérfana solo por completitud.
¿Cómo deben evaluarse los grupos de Customers?
Evalúe el resultado comercial asociado, como precio, visibilidad, presentación fiscal o acceso, no solo si existe el nombre del grupo.
¿Cuál es la forma más segura de conservar URL de PrestaShop?
Utilice un registro de rutas que incluya ruta de origen, tienda, idioma, destino y responsable de redirección para Products, Categories, CMS Pages y campañas prioritarias.
¿Qué demuestra que los identificadores externos se conservaron correctamente?
Que el ERP, almacén, marketplace o proceso de soporte que continuará puede localizar y actualizar el registro previsto usando el identificador conservado en el nivel correcto de Product, combinación, Customer u Order.