Si Shopware se selecciona como plataforma de destino, la preparación debe definir cómo se relacionan los registros del origen con canales de venta, Products y variantes, propiedades, campos personalizados, Customers, Orders, Shopping Experiences, reglas, contenido multimedia, URLs, extensiones y sistemas externos. Una exportación completa no es suficiente cuando el mismo Product puede aparecer en varios canales, las variantes heredan o sobrescriben valores del Product padre, las propiedades pueden servir tanto para filtros como para generar variantes y el funcionamiento comercial depende de reglas asignadas.
Cada acción de preparación debe tener un responsable, un artefacto de evidencia y una condición clara para considerarse lista. El paquete de preparación también debe separar las evidencias del origen de la implementación en el destino. Las relaciones entre Products, el contexto histórico de Orders, las URLs existentes, los identificadores externos y los registros propiedad de extensiones pertenecen a la preparación de la migración; el funcionamiento en vivo de pagos, envíos, impuestos, flujos, tema y canales de venta sigue siendo una decisión de implementación en Shopware.
Asegurar acceso a Shopware, alojamiento, base de datos y archivos
Confirme el acceso a Shopware Administration, gestión del alojamiento o cloud, base de datos cuando esté disponible, archivos de la aplicación, almacenamiento de contenido multimedia, tareas programadas, credenciales de integración y gestión de extensiones. Registre la versión de Shopware, modelo de despliegue, entorno PHP y de base de datos en instalaciones autogestionadas, canales de venta activos, idiomas, monedas, extensiones, código personalizado y sistemas conectados.
| Acción de preparación | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Confirmar acceso administrativo | Administrador de Shopware | Cuenta funcional y resumen de permisos | Se pueden inspeccionar Products, Customers, Orders, reglas, canales de venta, extensiones y contenido. |
| Crear copias recuperables del origen | Responsable de infraestructura | Exportación de base de datos, archivo de ficheros/contenido multimedia, copia de configuración y responsable de restauración | La tienda de origen puede recuperarse independientemente del entorno en vivo. |
| Registrar el entorno técnico | Responsable técnico | Inventario de versiones de Shopware, PHP, base de datos, alojamiento, despliegue y extensiones | Quedan documentados los registros y personalizaciones dependientes de versión. |
| Capturar código personalizado y extensiones | Responsable de desarrollo | Lista de extensiones, plugins/aplicaciones personalizados, archivos modificados, entidades personalizadas y notas de despliegue | Cada registro o comportamiento no perteneciente al core tiene un responsable. |
| Mapear sistemas externos | Responsables de integraciones | Identificadores de ERP, PIM, WMS, CRM, marketplace, búsqueda, pagos y procesamiento de pedidos | Se conocen las fuentes de referencia y las claves de sincronización que continuarán activas. |
Conserve los identificadores internos de Products, variantes, Categories, propiedades, canales de venta, Customers, Orders, contenido multimedia, campos personalizados y sistemas externos. Estas claves son necesarias cuando deben conciliarse registros entre entidades de Shopware o volver a conectarse integraciones.
Preparar canales de venta, dominios, idiomas y alcance de Customers
Los canales de venta de Shopware pueden representar tiendas, contextos headless, feeds de comparación de Products, canales sociales u otros puntos de contacto orientados al cliente. Products, Categories, dominios, idiomas, monedas, métodos de pago, métodos de envío, temas y relaciones de Customer pueden depender del canal seleccionado.
| Área del canal de venta | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Inventario de canales | ID del canal, tipo, estado, dominio, idioma, moneda, alcance de Customers y responsable | Cada contexto activo orientado al cliente aparece una sola vez. |
| Disponibilidad de Products | IDs de Product/variante, nivel de visibilidad, canales asignados y canales excluidos | El alcance del Product no se deduce de su simple presencia global en el catálogo. |
| Contexto de dominio e idioma | Dominio, ruta, locale, moneda, intención hreflang y comportamiento de fallback | Los registros localizados están conectados al contexto público correcto. |
| Vinculación de Customers | Funcionamiento del registro, relación Customer-canal, casos de email duplicado y política de cuentas | Las identidades de Customer no se fusionan entre canales sin evidencia. |
| Configuración específica del canal | Responsables de pagos, envíos, impuestos, tema, analítica y contenido legal | La configuración en vivo queda separada de las evidencias de registros migrados. |
Documente si la tienda de origen tiene varias tiendas, regiones, marcas, idiomas, rutas mayoristas, marketplaces o experiencias headless. Identifique qué contextos deben permanecer separados y cuáles se consolidarán de forma intencionada. Esta decisión debe existir antes de normalizar las evidencias de catálogo y Customers.
Preparar Products, variantes, propiedades y campos personalizados
Los Products de Shopware pueden utilizar relaciones padre-variante, propiedades, fabricantes, contenido multimedia, Categories, precios avanzados, campos personalizados, plazos de entrega, cantidades de compra y visibilidad por canal de venta. Las propiedades pueden utilizarse para filtros de tienda y también proporcionar los valores con los que se generan variantes, pero las propiedades descriptivas y las que definen variantes no son automáticamente el mismo conjunto.
| Patrón de catálogo | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Product simple | ID de Product, número de Product, precio, stock, impuesto, fabricante, Category, contenido multimedia y visibilidad por canal | El Product puede interpretarse sin dependencias ocultas de extensiones. |
| Familia de variantes | ID del Product padre, IDs de variantes, combinaciones de opciones, valores heredados y sobrescritos, SKU, stock, precio, peso e imágenes | Cada variante vendible es trazable al Product padre y a los valores de opción correctos. |
| Propiedad filtrable | Grupo de propiedades, valores, asignaciones a Products, uso como filtro y traducciones | Los datos descriptivos utilizados para descubrimiento están diferenciados de la identidad de variantes comprables. |
| Campo personalizado | Conjunto de campos, nombre técnico, tipo, asignación de entidad, valores, traducciones y proceso consumidor | Quedan documentados los usos internos, de tienda, reglas e integraciones. |
| Product multicanal | IDs de Product/variante, canales asignados, niveles de visibilidad, Category principal y ruta SEO específica del canal | La disponibilidad por canal es explícita y no inferida. |
| Product con abundante contenido multimedia | Recurso principal/galería, imágenes específicas de variantes, contexto alt, orden y almacenamiento externo | Cada recurso multimedia tiene un propietario Product o variante conocido. |
Registre por separado Products inactivos, ocultos, descatalogados, bajo pedido, de liquidación, digitales, parecidos a bundles, parecidos a suscripciones o creados por extensiones. No normalice estados poco habituales dentro de un único Product activo ordinario solo para simplificar el inventario del origen.
Preparar Categories, Dynamic Product Groups y Shopping Experiences
Las Categories de Shopware pueden sostener navegación, asignación de Products, puntos de entrada de tienda y layouts de contenido. Dynamic Product Groups puede definir conjuntos de Products basados en reglas. Shopping Experiences puede aportar páginas de destino, páginas de tienda, layouts de Category, secciones, bloques, elementos, enlaces y contenido multimedia. Estas relaciones necesitan evidencias separadas aunque para el Customer formen un único recorrido.
| Estructura de tienda | Evidencia | Condición de preparación |
|---|---|---|
| Jerarquía de Categories | IDs de Category, padres, estado activo, Products asignados, canales de venta, traducciones y uso como Category principal | La jerarquía del catálogo y el alcance por canal están completos. |
| Dynamic Product Group | Condiciones, ejemplos de Products, asignación a canal de venta y propósito de negocio | El surtido basado en reglas no se trata como una exportación estática de Category. |
| Shopping Experience | ID del layout, tipo, Category o página de destino asignada, secciones, bloques, contenido multimedia y Products/Categories vinculados | La propiedad del contenido y las referencias de catálogo quedan documentadas. |
| Ruta de navegación | Canal de venta, árbol de Categories, propósito del menú, contexto de acceso y URLs prioritarias | La navegación no se deduce únicamente de los registros de Category. |
| Enlaces internos | Página de origen, ID del Product/Category/contenido enlazado, idioma e intención del destino | Los enlaces pueden reescribirse sin perder el objeto empresarial al que hacían referencia. |
Identifique layouts o elementos de contenido creados por extensiones. Separe contenido reutilizable de presentación del tema y de datos de Product. Si una Shopping Experience contiene un Product, Category, formulario o bloque de extensión enlazado, registre tanto el layout como el responsable del elemento referenciado.
Preparar reglas, precios, promociones y condiciones comerciales
Las asignaciones de Shopware Rule Builder pueden afectar a precios avanzados, promociones, costes de envío, disponibilidad de métodos de pago o envío, flujos, visibilidad de Products o Categories y acceso a contenido. La preparación debe describir la condición de negocio y cada lugar donde se asigna la regla.
| Área comercial | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Regla | ID, nombre, condiciones, prioridad, estado, Customers/grupos/canales referenciados y asignaciones | Se conoce el propósito comercial de la regla y todas las áreas afectadas. |
| Precio avanzado | Product/variante, moneda, regla, intervalo de cantidad, valores brutos/netos, precio de lista y contexto de fecha | Cada precio está vinculado a la condición comercial correcta. |
| Promoción | Código, reglas, alcance del descuento, exclusiones, límites de uso, fechas y Orders históricos relevantes | Las evidencias históricas de descuento están separadas de la futura configuración de promociones. |
| Condición de envío/pago | Regla asignada, canal de venta, contexto de Customer, región, umbral del carrito y excepción | La condición queda documentada sin tratarla como datos migrados de Order. |
| Stock y entrega | Cantidad de Product/variante, responsable externo, contexto de almacén cuando exista, plazo de entrega y estado bajo pedido | Se conocen la fuente de referencia del stock y la clave de la unidad vendible. |
Los totales históricos de Orders deben conservarse como instantáneas. No planifique recalcular precios, descuentos, impuestos o costes de envío anteriores utilizando las asignaciones actuales de Rule Builder.
Preparar Customers, direcciones, Orders y estados históricos
La preparación de Customers debe incluir identidad de cuenta, relación con canales de venta, grupos de Customers, direcciones, idioma, datos de empresa o impuestos, evidencia de consentimiento, IDs externos y dependencias de autenticación. La preparación de Orders debe conservar líneas históricas de Product, variantes seleccionadas, direcciones, totales, historial de estados, transacciones, entregas, documentos, reembolsos y referencias de integración.
| Área del registro | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Identidad de Customer | Responsable de datos de Customer | ID, email, canal de venta, grupo, idioma, estado, direcciones e ID externo | Las identidades duplicadas o vinculadas a canales se resuelven de forma deliberada. |
| Autenticación | Responsable de seguridad | Esquema de contraseña, SSO/login social, ruta de restablecimiento, MFA y comunicaciones de cuenta | El acceso a cuentas está planificado sin asumir portabilidad de credenciales. |
| Líneas de Order | Responsable de datos de Orders | IDs de Product/variante, etiquetas históricas, cantidades, precios, promociones, impuestos y cargas personalizadas | Los artículos comprados siguen siendo comprensibles aunque cambie el catálogo. |
| Estado de Order | Responsable de operaciones | Estados de Order, transacción y entrega con marcas de tiempo y significado de negocio | El historial puede interpretarse sin recrear el flujo del origen. |
| Documentos y referencias | Responsables de finanzas/integraciones | IDs de factura, nota de crédito, transacción, envío, marketplace, ERP y procesamiento de pedidos | Las claves históricas de conciliación siguen siendo trazables. |
Seleccione Orders de invitado, registrados, ligados a canales, con descuento, reembolsados, parcialmente entregados y afectados por extensiones. Estos casos revelan relaciones que los Orders completados ordinarios no muestran.
Inventariar extensiones, entidades personalizadas e integraciones
Cree un registro de responsables para cada plugin, aplicación, entidad personalizada, conjunto de campos personalizados, acción de Flow Builder, extensión de búsqueda, integración de pago o envío, conector ERP/PIM/WMS, feed de marketplace, extensión de tema y proceso programado que lea o escriba datos de negocio.
| Dependencia | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Extensión | Nombre, versión, estado, propósito, responsable de configuración, entidades, tablas, campos personalizados y registros afectados | Los datos propiedad de la extensión tienen un destino o un responsable que continúa activo. |
| Entidad o campo personalizado | Esquema, entidad asignada, relaciones, traducciones y código consumidor | Los datos personalizados pueden interpretarse independientemente de la implementación del origen. |
| Sistema externo | Endpoint, autoridad por entidad, dirección de sincronización, IDs y responsable del corte | La migración no creará sistemas de referencia en competencia. |
| Flow o webhook | Disparador, condición, acción, payload, destino y responsable de errores | La automatización operativa queda separada de los registros estáticos migrados. |
| Datos generados | Índices, caches, logs, sesiones, registros de colas y tablas abandonadas de extensiones | Los datos técnicos no autoritativos se excluyen de forma deliberada. |
Las extensiones inactivas deben permanecer en el inventario cuando sus datos históricos sigan apareciendo en Products, Customers, Orders, documentos o conciliaciones externas.
Preparar URLs prioritarias, evidencias SEO y decisiones de redirección
Registre las URLs prioritarias de Product, Category, páginas de destino, páginas de tienda y contenido por canal de venta e idioma. Incluya funcionamiento canonical para variantes, relaciones de Category principal, metadatos, enlaces internos, backlinks, rutas de campaña y cualquier plantilla de URLs SEO o extensión de redirects utilizada.
| Evidencia de URL | Responsable | Condición de preparación |
|---|---|---|
| Rutas de Product y variante | Responsable SEO/catálogo | Cada Product prioritario tiene una ruta de origen asociada a canal y un destino previsto. |
| Rutas de Category y páginas de destino | Responsable de contenido | Jerarquía de Category, Shopping Experience e intención de ruta están conectadas. |
| Rutas multilingües | Responsable de localización | Se conservan idioma y contexto de canal de venta. |
| Inventario de redirects | Responsable SEO | Cada ruta antigua de alto valor tiene una decisión de mantener, cambiar, fusionar, retirar o redirigir. |
| Enlaces internos | Responsable de contenido | Las referencias del origen pueden reescribirse hacia los objetos de destino previstos. |
No dependa únicamente del sitemap. Incluya URLs procedentes de analítica, datos de búsqueda, backlinks, campañas, comunicaciones con Customers y navegación interna de alto valor.
Seleccionar muestras representativas para las pruebas de migración
Elija muestras que representen la arquitectura real de la tienda. Registre IDs del origen, números de Product, URLs, canales de venta, valores de propiedades, reglas, relaciones de Customer, referencias de Order y el motivo por el que se seleccionó cada muestra.
| Muestra | Evidencia que debe prepararse | Propósito de la preparación |
|---|---|---|
| Familia de variantes | Product padre, variantes, opciones, herencia, stock, precios, imágenes y canales | Representa el modelo de Product y variantes de Shopware. |
| Product con muchas propiedades | Grupos de propiedades, valores de filtro, campos personalizados, Category y uso en búsqueda | Representa descubrimiento y propiedad de campos. |
| Caso dependiente de reglas | Regla, precio/promoción/envío/pago asignado y registros afectados | Representa funcionamiento comercial condicionado. |
| Customer multicanal | Customer, canal de registro, grupos, direcciones y contexto de emails duplicados | Representa identidad vinculada a canales. |
| Order complejo | Líneas de variantes, promociones, estados, transacción, entrega, documento e IDs externos | Representa evidencia histórica de comercio. |
| Shopping Experience | Layout, asignación de Category/página de destino, contenido multimedia, enlaces y bloques de extensiones | Representa relaciones entre contenido y comercio. |
| Registro propiedad de extensión | Entidad principal, esquema de la extensión, campos personalizados y claves de integración | Expone alcance no perteneciente al core antes de la ejecución. |
El paquete de muestras de Shopware está listo cuando cada registro seleccionado dispone de evidencia del origen, contexto de canal y reglas, archivos relacionados y un revisor identificado.
Completar la comprobación final de preparación para Shopware
| Área de preparación | Condición para considerarla lista |
|---|---|
| Acceso y recuperación | Administration, alojamiento, base de datos/archivos cuando aplique, contenido multimedia, credenciales, backups y responsabilidad de restauración están confirmados. |
| Canales de venta | Dominios, idiomas, monedas, alcance de Customers, visibilidad de Products y responsables están documentados. |
| Catálogo | Products, variantes, propiedades, Categories, contenido multimedia, precios, stock, campos personalizados e identificadores son trazables. |
| Historial comercial | Customers, direcciones, Orders, estados, entregas, transacciones, documentos y referencias externas disponen de evidencia del origen. |
| Contenido y URLs | Shopping Experiences, navegación, rutas prioritarias, metadatos, enlaces internos y decisiones de redirect están documentados. |
| Dependencias | Reglas, extensiones, entidades personalizadas, flows, webhooks y sistemas externos tienen responsables. |
| Muestras | Los registros representativos cubren cada patrón relevante de Product, canal, Customer, Order, contenido, regla y extensión. |
El alcance para Shopware está listo cuando cada registro relevante puede trazarse hasta su responsable de origen, registros relacionados, artefacto de evidencia y destino previsto o sistema que seguirá siendo responsable.
Conclusión
Preparar una migración hacia Shopware exige evidencias coordinadas entre canales de venta, Products y variantes, propiedades, campos personalizados, Categories, Shopping Experiences, reglas, Customers, Orders, extensiones, URLs e integraciones. La lista de preparación debe hacer explícitas estas relaciones antes de ejecutar el trabajo, en lugar de confiar en totales de registros o exportaciones genéricas.
Un paquete de preparación completo conserva evidencias recuperables del origen, define qué registros son autoritativos, separa transacciones históricas de configuración en vivo y asigna un responsable a cada dependencia importante.
Preguntas frecuentes
¿Qué debe prepararse primero para una migración hacia Shopware?
Confirme acceso a Administration e infraestructura, cree backups recuperables, registre el entorno de Shopware y sus extensiones e identifique todos los canales de venta activos. El trabajo detallado de catálogo no debe empezar hasta que el equipo pueda inspeccionar el origen y recuperarlo de forma fiable.
¿Por qué debe documentarse por separado el alcance de cada canal de venta?
Products, Customers, dominios, idiomas, monedas, visibilidad, contenido y configuración comercial pueden depender del canal de venta. La presencia global de un registro no demuestra que se haya conservado el contexto correcto para el Customer.
¿Cómo deben prepararse las propiedades y variantes de Shopware?
Documente grupos de propiedades, valores, asignaciones a Products, uso como filtros y combinaciones de opciones que generan variantes. Registre los valores heredados y sobrescritos de cada variante vendible para no confundir propiedades descriptivas con identidad de variante.
¿Qué reglas necesitan evidencias de preparación?
Incluya las reglas asignadas a precios, promociones, envíos, pagos, flows, visibilidad de Product o Category y acceso a contenido. Registre condiciones, prioridad, entidades referenciadas y cada asignación que dependa de la regla.
¿Qué Orders de Shopware deben elegirse como muestras representativas?
Incluya Customers invitados y registrados, cuentas vinculadas a canales, variantes, promociones, reembolsos, entregas parciales, varios cambios de estado, documentos, transacciones y referencias de integraciones externas.
¿Qué debe incluir el registro de extensiones de Shopware?
Registre cada extensión, entidad personalizada, conjunto de campos personalizados, flow, webhook, dependencia de tema y conector externo que cree o consuma datos de negocio. Cada elemento necesita responsable, registros afectados, evidencia del origen y una decisión sobre su destino o sistema responsable.