Los problemas en una migración hacia Shopware suelen aparecer cuando los registros se transfieren sin conservar las relaciones de canales de venta, herencia, reglas, contenido y extensiones que determinan cómo funcionan esos registros. Un Product puede existir en Administration y seguir siendo invisible en un canal de venta, una variante puede heredar un precio o medios incorrectos, y una Shopping Experience puede mostrarse sin los vínculos a Products o Categories que antes presentaba.
Los patrones de fallo siguientes se centran en esas rupturas de relaciones. Cada uno define señales de alerta, un control preventivo, un ejemplo realista y una condición de aprobación que demuestra que el problema está contenido.
Problema 1: importar Products sin sus asignaciones a canales de venta
Qué ocurre
Los canales de venta de Shopware pueden representar tiendas, canales API headless, comparadores de Products y otros destinos. Products, Categories, idiomas, monedas, dominios, métodos de pago, métodos de envío, registro de Customers y temas pueden variar según el canal. Importar el Product sin su visibilidad por canal puede dejarlo presente en Administration pero no disponible para los compradores.
Señales de alerta temprana
| Señal de alerta temprana | Qué indica |
|---|---|
| El origen utiliza varios dominios, regiones, marcas o feeds de marketplaces. | Es poco probable que un único canal de venta predeterminado conserve el modelo operativo. |
| La disponibilidad de Products cambia entre tiendas o canales. | La propiedad del surtido debe representarse por canal de venta. |
| Los Customers están vinculados a determinados canales de venta. | El contexto del Customer no es intercambiable globalmente. |
| Se utilizan Categories o grupos dinámicos de Products para formar el surtido de un canal. | La visibilidad del canal depende de relaciones que van más allá del registro de Product. |
Prevención
Cree un mapa de responsabilidad por canal de venta. Conserve la asignación de Products y Categories, idioma, moneda, dominio, contexto de Customers, relaciones de pago y envío, punto de entrada de navegación y clave del canal externo. No suponga que todos los Products pertenecen a todos los canales.
Ejemplo recomendado
Utilice un Product disponible en dos tiendas, un Product restringido a un canal regional y un Product exportado a través de un canal de comparación. Represente cada asignación de canal por separado.
Condición de aprobación
Cada Product representativo aparece únicamente en los canales de venta previstos, con el idioma, moneda, ruta de Category, acceso de Customers y relación de URL o feed específica del canal correctos.
Problema 2: aplanar variantes, propiedades y herencia de Products
Qué ocurre
Las propiedades de Shopware pueden describir Products, permitir filtros y generar variantes. Las variantes pueden heredar precio, stock, medios, dimensiones, texto y otros valores del Product principal hasta que se desactive la herencia. Aplanar la familia puede duplicar contenido del Product principal, perder números de Product de las variantes o sobrescribir valores específicos de cada variante.
Señales de alerta temprana
| Señal de alerta temprana | Qué indica |
|---|---|
| Las combinaciones de variantes se generan a partir de opciones de propiedades, pero faltan IDs de los Products hijos. | La familia de variantes carece de una identidad estable para cada unidad vendible. |
| El Product principal y las variantes comparten valores en algunos campos pero difieren en otros. | Los límites entre herencia y sobrescritura no están documentados. |
| Los datos de origen no identifican qué valores son heredados y cuáles se sobrescriben. | El destino puede duplicar valores o borrar diferencias intencionadas. |
| Las propiedades utilizadas para filtrar se mezclan con las que generan variantes. | Se están confundiendo atributos de descubrimiento con combinaciones vendibles. |
Prevención
Conserve el Product principal, las propiedades que generan variantes, las combinaciones de opciones, los números de Product de los hijos, el estado de herencia, las exclusiones, los precios, el stock, los medios y el estado activo. Mantenga separadas las propiedades descriptivas para filtros de aquellas que definen variantes vendibles.
Ejemplo recomendado
Utilice una camiseta cuyas variantes hereden la descripción pero sobrescriban el número de Product, precio, stock e imagen. Incluya una combinación color-talla excluida.
Condición de aprobación
La familia representativa contiene las variantes y exclusiones correctas, los campos heredados siguen heredándose, los campos sobrescritos conservan los valores del Product hijo y las propiedades de filtro no crean variantes no deseadas.
Problema 3: recrear precios sin sus condiciones de Rule Builder
Qué ocurre
Las condiciones de Rule Builder de Shopware pueden influir en precios, promociones, envíos, pagos, contenido y otros comportamientos comerciales. Copiar únicamente el precio o descuento resultante elimina el grupo de Customers, canal de venta, moneda, cantidad, periodo, carrito o condición de Order que explica cuándo se aplica ese valor.
Señales de alerta temprana
| Señal de alerta temprana | Qué indica |
|---|---|
| Existen varios precios para el mismo Product sin una audiencia claramente definida. | Faltan las condiciones que seleccionan cada precio. |
| Las promociones se describen por nombre, pero no por condiciones y prioridades. | La lógica de Rule Builder no puede reconstruirse a partir de las etiquetas. |
| La disponibilidad de envío o pago depende de propiedades del Customer o del carrito. | Los métodos operativos están gobernados por reglas, no únicamente por registros migrados. |
| Las reglas hacen referencia a grupos de Customers, tags, canales de venta o campos personalizados. | Los datos de los que depende la regla deben seguir conectados. |
Prevención
Modele la regla por separado de su resultado. Conserve el nombre de la regla, prioridad, condiciones, operadores, entidades referenciadas y el módulo que consume la regla. Reasigne los Customers, grupos o canales de venta referenciados cuando los IDs del origen no puedan mantenerse.
Ejemplo recomendado
Utilice un precio por cantidad para un grupo mayorista de Customers y una regla de envío limitada a un canal de venta regional y a un valor del carrito. Conserve las condiciones y referencias, no únicamente los valores finales.
Condición de aprobación
Cada regla representativa se aplica solo en el contexto previsto, permanece inactiva fuera de ese contexto y hace referencia a Customers, grupos, Products, canales, monedas y campos personalizados válidos en el destino.
Problema 4: tratar los árboles de Categories y los grupos dinámicos de Products como si fueran lo mismo
Qué ocurre
Las Categories de Shopware pueden organizar navegación y contenido, mientras que los grupos dinámicos de Products seleccionan Products según reglas. Una colección o agrupación comercial del origen puede confundirse con una Category permanente, o una Category puede reconstruirse como una regla que ya no proporciona jerarquía, contenido ni rutas.
Señales de alerta temprana
- Las colecciones del origen combinan pertenencia manual y basada en reglas.
- Una Category existe principalmente para mostrar Products de una campaña.
- Los Products aparecen en la búsqueda pero no en la rama de navegación prevista.
- Los grupos dinámicos dependen de propiedades o campos personalizados que no se han normalizado.
Prevención
Clasifique cada agrupación por su responsabilidad: jerarquía y ruta, pertenencia manual de Products, regla de selección dinámica, Shopping Experience o surtido del canal. Conserve los campos utilizados por los grupos dinámicos y las relaciones de Categories utilizadas por la navegación.
Ejemplo recomendado
Represente una Category permanente “Shoes”, un grupo dinámico “Low stock” y una Category de destino estacional basada en un grupo dinámico como tres estructuras conectadas pero distintas.
Condición de aprobación
Las Categories permanentes conservan jerarquía y rutas, los grupos dinámicos devuelven los Products previstos a partir de condiciones válidas y los diseños de campaña hacen referencia a la agrupación correcta sin duplicar la responsabilidad sobre Products.
Problema 5: copiar Shopping Experiences sin su contexto de asignación
Qué ocurre
Shopping Experiences puede crear páginas de destino, páginas de tienda, diseños de Categories y diseños de páginas de Product. Sus secciones, bloques, elementos, medios, enlaces y asignaciones de datos dependen del tipo de página y del canal de venta. Copiar el contenido del diseño sin la Category, Product o canal asignados puede dejar una página atractiva pero inaccesible o engañosa.
Señales de alerta temprana
| Señal de alerta temprana | Qué indica |
|---|---|
| Los diseños contienen enlaces a Products o Categories que apuntan a IDs del origen. | El contenido de Shopping Experience contiene relaciones internas rotas. |
| Las páginas de Category utilizan diseños distintos según el canal de venta. | La asignación del diseño es específica del canal. |
| Los elementos de página de Product contienen sobrescrituras específicas de registros. | Una plantilla genérica no puede reproducir todo el funcionamiento de la tienda. |
| Existen páginas de destino sin navegación ni documentación de rutas directas. | El contenido puede migrarse sin una vía utilizable para descubrirlo. |
Prevención
Conserve el tipo de diseño, secciones, bloques, elementos, medios, contenido traducido, enlaces, Categories o Products asignados, compatibilidad con canales de venta y sobrescrituras por registro. Sustituya los IDs del origen por referencias a entidades del destino.
Ejemplo recomendado
Utilice un diseño de Category, una página de destino independiente y un diseño de página de Product con una sobrescritura de texto específica para un Product. Siga cada Product, Category, medio y ruta enlazados.
Condición de aprobación
Cada Shopping Experience representativa es accesible mediante la ruta prevista, se muestra en el canal de venta e idioma correctos y presenta Products, Categories, medios y sobrescrituras específicas de registros válidos en el destino.
Problema 6: perder definiciones de campos personalizados o la herencia entre idiomas
Qué ocurre
Los campos personalizados de Shopware pueden ampliar Products, Categories, Customers, Orders y otras entidades. El valor depende de un conjunto de campos, tipo de datos, asignación, traducción y plantilla o regla que lo utilice. Copiar los valores sin sus definiciones crea datos invisibles o inutilizables. Introducir únicamente un valor traducido también puede romper la herencia desde el idioma predeterminado.
Señales de alerta temprana
- Existen valores de campos personalizados, pero el conjunto de campos no está documentado.
- Varios idiomas contienen valores diferentes o ausentes.
- Reglas o plantillas hacen referencia a nombres técnicos de campos personalizados.
- Los campos creados por aplicaciones se mezclan con los creados por el comerciante.
Prevención
Conserve la identidad del conjunto de campos, nombre técnico, etiqueta, tipo, valores permitidos, asignación de entidad, valor del idioma predeterminado, sobrescrituras traducidas y cada referencia de Rule Builder, plantilla o integración. Mantenga los datos personalizados propiedad de una aplicación bajo su responsable real.
Ejemplo recomendado
Utilice un campo de cumplimiento de Product heredado entre idiomas y una etiqueta comercial localizada que sobrescriba intencionadamente el valor predeterminado.
Condición de aprobación
Los campos aparecen en las entidades correctas, conservan definiciones y valores permitidos utilizables, heredan del idioma predeterminado cuando corresponde y siguen disponibles para cada regla, plantilla o integración que los consume.
Problema 7: conservar cabeceras de Orders pero perder el contexto de estados, transacciones y entregas
Qué ocurre
Los Orders de Shopware pueden incluir líneas de Order, Customers, direcciones, monedas, impuestos, descuentos, transacciones, entregas, documentos, estados y referencias externas. Importar únicamente la cabecera y el total del Order elimina las transiciones de estado y los registros operativos que explican el pago y el procesamiento de pedidos.
Señales de alerta temprana
- Los estados de pago y entrega se comprimen en un único estado genérico de Order.
- Los envíos, seguimientos, reembolsos o documentos se almacenan por separado.
- Faltan números de Product de variantes hijas en las líneas de Order.
- Las referencias externas de ERP o pagos solo existen en datos de extensiones.
Prevención
Conserve la instantánea del Order, líneas, identidad de variantes, direcciones, totales, impuestos, promociones, estado de transacción, estado de entrega, seguimiento, documentos, comentarios e IDs externos. Mantenga el estado histórico separado de las reglas y métodos operativos actuales.
Ejemplo recomendado
Utilice un Order pagado y enviado, un Order parcialmente procesado y un Order reembolsado que contenga una variante y una promoción.
Condición de aprobación
Cada Order representativo sigue siendo comprensible para atención al cliente, finanzas y procesamiento de pedidos, con relaciones válidas entre líneas, transacciones, entregas, documentos, estados y referencias externas.
Problema 8: reconstruir URLs SEO sin el contexto de canal de venta y canonical
Qué ocurre
Las plantillas de URLs SEO y las rutas generadas de Shopware pueden variar por canal de venta. Los Products con variantes también pueden utilizar una URL canonical compartida o rutas específicas por variante. Recrear slugs sin la plantilla, Category principal, ruta histórica y contexto de canal puede producir páginas duplicadas o redirigir visitantes a la tienda equivocada.
Señales de alerta temprana
- El mismo Product tiene rutas diferentes según el canal de venta o idioma.
- Las URLs del origen dependen de rutas de Categories o de la asignación de una Category principal.
- Las páginas de variantes utilizan un comportamiento canonical mixto.
- Las URLs antiguas no están vinculadas con rutas del destino.
Prevención
Conserve rutas de origen, Product o Category de destino, canal de venta, idioma, Category principal, configuración canonical y relación de redirección. Reconstruya los índices SEO después de modificar plantillas para que las rutas generadas reflejen las reglas previstas.
Ejemplo recomendado
Utilice un Product asignado a dos Categories en dos canales de venta, además de una familia de variantes que utilice una única URL canonical de Product. Registre cada ruta de origen importante y su destino previsto.
Condición de aprobación
Las rutas representativas se resuelven en el canal de venta e idioma correctos, el comportamiento canonical es coherente entre variantes y las rutas antiguas redirigen al Product o Category actuales previstos.
Problema 9: copiar datos de extensiones sin conservar su entidad y ciclo de vida
Qué ocurre
Las extensiones y aplicaciones de Shopware pueden añadir entidades personalizadas, campos, reglas, registros API, procesos programados, componentes de tienda, datos de pago o envío, suscripciones, vínculos con marketplaces y estado de integraciones. Copiar campos a entidades estándar no conserva el ciclo de vida de la extensión ni sus referencias.
Señales de alerta temprana
- Los campos técnicos utilizan un prefijo de aplicación o plugin.
- Las entidades personalizadas hacen referencia a Products, Customers u Orders mediante IDs internos.
- El personal depende de datos que no tienen un módulo estándar en Administration.
- Un sistema externo actualiza el valor mediante API o webhook.
Prevención
Cree un mapa de responsabilidad para cada extensión. Identifique sus entidades, referencias principales, campos técnicos, configuración, IDs externos, dirección de actualización y destino operativo futuro. Separe la evidencia histórica del estado operativo en vivo.
Ejemplo recomendado
Siga un registro de suscripción, un anuncio de marketplace y un identificador ERP de Product desde la entidad de extensión hasta el registro principal de Shopware y el sistema externo responsable.
Condición de aprobación
Cada registro de extensión que se conserve tiene una entidad de destino definida, referencias principales válidas, identificadores externos estables y una aplicación o integración activa capaz de interpretarlo y mantenerlo.
Problema 10: asumir que datos correctos de Products producen automáticamente resultados correctos de búsqueda
Qué ocurre
La búsqueda y la indexación de Shopware pueden depender de campos de Products configurados como buscables, números de Product, palabras clave, propiedades, fabricantes, Categories, sinónimos, acciones y configuración de índices específica de extensiones. Los Products importados pueden existir y estar activos y, aun así, no aparecer en la búsqueda o situarse de forma deficiente porque falten campos indexados, alias o procesamiento mediante colas de mensajes.
Señales de alerta temprana
| Señal de alerta temprana | Qué indica |
|---|---|
| Los Products son visibles mediante URL directa, pero no aparecen en la búsqueda. | El registro existe, pero la indexación o configuración de búsqueda está incompleta. |
| Los números de Product, EANs o valores personalizados no pueden buscarse. | Los campos de búsqueda necesarios no están incluidos en la configuración activa. |
| No se inventariaron sinónimos de búsqueda ni acciones de redirección. | El funcionamiento comercial de la búsqueda no seguirá la intención del origen. |
| La creación del índice termina, pero faltan alias o procesamiento pendiente en cola. | El índice generado todavía no es el que atiende las solicitudes de la tienda. |
Prevención
Conserve palabras clave de búsqueda, visibilidad de Products, campos buscables, propiedades, datos de fabricantes, sinónimos, acciones y cualquier configuración de Advanced Search. Incluya la creación de índices, procesamiento de colas de mensajes, creación de alias y responsabilidad sobre la indexación continua en el plan operativo de migración.
Ejemplo recomendado
Utilice un Product encontrado por nombre, otro por número de Product, otro que dependa de un sinónimo y otro dirigido por una acción de búsqueda. Siga cada caso a través de los campos e índices configurados.
Condición de aprobación
Los Products representativos aparecen mediante los nombres, números, propiedades, fabricantes y sinónimos previstos; las acciones de búsqueda conducen a destinos válidos y los índices y alias necesarios se mantienen actualizados.
Prioridades transversales para prevenir problemas
La prevención de problemas en Shopware depende de mantener los datos de Products conectados con canales de venta, variantes heredadas, condiciones de Rule Builder, Shopping Experiences, campos personalizados sensibles al idioma, estados históricos de Orders, rutas, búsqueda y responsabilidad de extensiones. Un registro correcto de Product no puede compensar la ausencia de una relación con un canal, regla, diseño o índice.
| Capa de prevención | Control necesario |
|---|---|
| Responsabilidad por canal de venta | Conectar Products, Customers, Categories, dominios, idiomas y visibilidad con el canal correcto. |
| Control de herencia | Distinguir valores heredados del Product principal de sobrescrituras a nivel de variante. |
| Dependencias de reglas | Conservar los datos que utilizan las condiciones de Rule Builder para precios, promociones, pagos y envíos. |
| Asignación de experiencia | Mantener Shopping Experiences conectadas con el tipo de página, entidad, ruta y canal de venta correctos. |
| Entrega de búsqueda | Alinear campos buscables, sinónimos, indexación, alias y procesamiento en cola. |
Conclusión
Las migraciones hacia Shopware fallan cuando estructuras interconectadas de la plataforma se reducen a registros aislados. Los canales de venta definen disponibilidad, las propiedades generan variantes, las reglas controlan el funcionamiento comercial, Shopping Experiences aporta contexto y las extensiones pueden ser responsables de dominios completos del negocio.
La migración más segura conserva cada relación y la demuestra mediante una condición de aprobación específica de la plataforma. Cuando Products, canales, reglas, contenido, Orders, URLs, búsqueda y extensiones son coherentes entre sí, la tienda migrada funciona como un entorno Shopware integrado, no como una colección de entidades importadas.
Preguntas frecuentes
¿Por qué un Product puede existir en Shopware y seguir sin estar disponible para los compradores?
El Product puede estar inactivo, oculto, excluido del canal de venta relevante, ausente del surtido de Categories del canal o carecer del contexto de idioma, moneda, dominio o visibilidad que necesita esa tienda.
¿Las propiedades de Shopware son siempre variantes de Product?
No. Las propiedades pueden describir y filtrar Products sin generar variantes. Solo las opciones de propiedades seleccionadas por el generador de variantes definen combinaciones vendibles.
¿Por qué las condiciones de Rule Builder deben migrarse por separado de los precios o descuentos resultantes?
El resultado solo es válido bajo determinadas condiciones de Customer, canal, moneda, cantidad, carrito, periodo u Order. Copiar el valor sin la regla hace que se aplique demasiado ampliamente o que no se aplique.
¿Shopping Experiences puede migrarse como CMS Pages ordinarias?
No de forma fiable. El tipo de página, secciones, bloques, elementos, asignaciones, contexto de canal de venta, enlaces y sobrescrituras específicas de Products o Categories determinan dónde y cómo funciona el diseño.
¿Cómo deben gestionarse los campos personalizados de Shopware entre idiomas?
Conserve primero la definición del campo y el valor del idioma predeterminado y, después, mantenga las sobrescrituras traducidas intencionadas. Esto conserva una herencia utilizable por plantillas, reglas e integraciones.
¿Por qué Products correctos en Shopware pueden seguir sin aparecer en la búsqueda?
Los resultados de búsqueda dependen de la visibilidad, campos buscables, palabras clave, propiedades, sinónimos, acciones, creación de índices, procesamiento de colas, alias y configuración de extensiones. Disponer de registros de Products correctos no garantiza por sí solo que puedan encontrarse mediante el índice.