Si CS-Cart se selecciona como plataforma de destino, la preparación debe comenzar por identificar si el modelo operativo previsto es un entorno Store Builder gestionado por un comerciante o un marketplace Multi-Vendor. Ambos utilizan estructuras de catálogo relacionadas, pero la preparación de un marketplace añade propiedad de proveedores, administradores de proveedores, Products y Orders específicos de cada vendedor, comisiones, registros contables, retiros, permisos de escaparates y flujos monetarios dependientes de extensiones.
El objetivo es preparar la evidencia de la tienda de origen antes de cerrar la configuración de la migración. Cada área importante debe identificar la acción, el responsable, la evidencia y la condición de preparación. Las opciones de Product, las Features y las variaciones deben seguir siendo conceptos distintos; el alcance de cada escaparate debe quedar explícito; los registros de proveedores no deben reducirse a cuentas Customer; y los Orders históricos deben conservar el contexto del vendedor y el contexto financiero.
Confirmar la edición, la versión, los escaparates y el acceso de CS-Cart
Registre la edición exacta de CS-Cart o Multi-Vendor, la versión, la ruta de instalación, la base de datos, los escaparates activos, las empresas o proveedores, los idiomas, las monedas, los temas, las extensiones de plataforma y las sincronizaciones externas. Las instalaciones con una larga trayectoria pueden contener estructuras de variaciones de Product actualizadas, extensiones retiradas, plantillas personalizadas o modificaciones de base de datos que cambien los registros disponibles en el origen.
Prepare el acceso al origen requerido para la ruta de migración seleccionada. El responsable técnico debe confirmar la base de datos correcta, el árbol de archivos, el entorno de administración y cualquier restricción de acceso. Para Multi-Vendor, identifique también al administrador del marketplace y a las personas que conocen las relaciones con los proveedores y los registros contables.
| Acción | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Confirmar edición y versión | Responsable técnico | Evidencia de versión y licencia/edición | No se mezclan supuestos de Store Builder y Multi-Vendor. |
| Registrar el alcance de los escaparates | Responsable de comercio electrónico | Lista de escaparates, dominios, idiomas, monedas y asignaciones de empresas | Cada escaparate activo tiene un propósito comercial documentado. |
| Confirmar el acceso al origen | Responsable de hosting o base de datos | Estado de conexión, prefijo de base de datos y nota sobre la raíz de archivos | Los registros y archivos de origen necesarios son accesibles. |
| Inventariar temas y extensiones | Desarrollador o agencia | Tema activo, lista de extensiones y registro de tablas personalizadas y archivos modificados | Se pueden separar los registros principales del funcionamiento propiedad de extensiones. |
| Identificar sistemas externos | Responsable de integraciones | Lista de ERP/PIM/WMS/marketplace/contabilidad y claves estables | Los valores mantenidos fuera de CS-Cart tienen una fuente de autoridad identificada. |
Cree un registro de cambios a partir del momento de corte de la evidencia. Las nuevas extensiones, los cambios en variaciones de Product, las fusiones de proveedores, los cambios de escaparates o la reestructuración de Categories deben quedar registrados mientras la preparación siga activa.
Preparar Products, opciones, Features, variaciones y Categories
CS-Cart separa las propiedades de Product, las opciones seleccionables, las Features de Product, las variaciones, las Categories, los descuentos por cantidad, los archivos descargables, las imágenes, los valores SEO y las asignaciones a escaparates. Las opciones pueden recoger elecciones o datos introducidos por el comprador. Las Features describen características estructuradas y pueden servir para filtrar o comparar. Las variaciones agrupan Products similares según valores de Features y pueden conservar una identidad de Product independiente.
Prepare un inventario de Products que identifique qué estructura es propietaria de cada valor comercial o descriptivo.
| Patrón en el origen | Acción de preparación | Evidencia | Condición de preparación |
|---|---|---|---|
| Opción seleccionable | Registrar tipo de opción, variantes, obligatoriedad, reglas de combinación y efectos sobre precio/peso | Exportación de asignaciones de Product y opciones | El funcionamiento de la elección del comprador queda explícito. |
| Variación de Product | Registrar grupo de variación, valores de Features, IDs de Product, SKU, precio, stock, imágenes y estado | Manifiesto de grupos de variaciones | Cada Product administrado de forma independiente sigue siendo identificable. |
| Feature de Product | Registrar grupo de Features, tipo, valores, alcance por Category/escaparate y uso en filtros | Inventario de Features | Los valores descriptivos y de descubrimiento se mantienen separados de las opciones. |
| Product en varias Categories | Registrar todas las asignaciones, el contexto principal de merchandising y el alcance por escaparate | Exportación de Product a Category | La ubicación compartida queda visible sin asumir Products duplicados. |
| Product descargable | Registrar archivos, condiciones de activación, relación con el Product y ruta original | Manifiesto de Product/archivo | Los archivos y las relaciones con Products están disponibles. |
| Precio por cantidad o mayorista | Registrar Product, umbral, grupo de usuarios o contexto de Customer, moneda e importe | Inventario de precios | Los valores comerciales condicionales no se reducen al precio base. |
Registre las combinaciones de opciones permitidas o prohibidas, archivos adjuntos, Products requeridos, bundles, relaciones de recompensas y campos de Product propiedad de extensiones cuando estén activos. No combine etiquetas de opciones y Features similares sin confirmar si una representa una elección del comprador y la otra una especificación.
Documentar el alcance de escaparates, empresas y catálogo
CS-Cart puede utilizar varios escaparates, y Multi-Vendor puede incorporar proveedores cuyos Products, administradores, páginas, métodos de envío y Orders pertenecen a participantes distintos del marketplace. Prepare una matriz de alcance que muestre qué registros pertenecen al catálogo común, a un escaparate específico, a un proveedor o a un canal externo.
| Área de alcance | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Dominios e idiomas de escaparates | Administrador de la plataforma | Configuración de escaparates y lista de dominios | Se identifica cada contexto público de tienda. |
| Disponibilidad de Products y Categories | Responsable del catálogo | Exportación de asignaciones de escaparate/empresa | Los registros de catálogo compartidos y restringidos pueden distinguirse. |
| Features y filtros | Responsable de merchandising | Mapa de Feature a Category y escaparate | Los vocabularios de descubrimiento tienen un alcance explícito. |
| CMS Pages y layouts | Responsable de contenidos | Inventario de páginas, bloques, layouts, menús y escaparates | El contenido y la presentación están vinculados al escaparate correcto. |
| Propiedad de empresa o proveedor | Responsable del marketplace | Asociaciones de Product, Order, administrador y página | Los registros propiedad del vendedor no se tratan como propiedad del marketplace por defecto. |
Preparar proveedores, administradores, planes y relaciones financieras
Esta sección se aplica cuando el modelo operativo del origen o del destino incluye Multi-Vendor. Un proveedor es una empresa vendedora independiente con administradores, Products, Orders, contexto de envío, estado y relaciones contables asociados. Los planes de proveedores, las comisiones por transacción, las comisiones, los pagos a vendedores, los retiros y las extensiones de pago del marketplace pueden añadir registros adicionales.
Prepare un registro maestro de proveedores que distinga proveedores activos, pendientes, deshabilitados, fusionados, históricos y duplicados. Registre los administradores asignados a cada proveedor, la propiedad de Products, la propiedad de Orders, el contexto de planes o comisiones, la evidencia de saldo de cuenta, los registros de pagos y retiros y los identificadores externos de vendedores.
| Registro del marketplace | Acción de preparación | Evidencia | Condición de preparación |
|---|---|---|---|
| Identidad del proveedor | Registrar ID de empresa, estado, datos legales/de contacto, página del escaparate y clave externa | Inventario de proveedores | Cada vendedor conservado tiene una única identidad prevista. |
| Administradores de proveedores | Registrar cuenta de usuario, relación con el proveedor, estado y contexto de permisos | Mapa de administrador a proveedor | Las relaciones de acceso del vendedor están documentadas. |
| Products propiedad del proveedor | Registrar propiedad de Product y Category, estado de aprobación y alcance por escaparate | Exportación de Product a proveedor | La propiedad del catálogo queda explícita. |
| Planes o comisiones de proveedores | Registrar plan, tarifa, comisión, fechas de vigencia y extensión propietaria | Inventario de planes/comisiones | Las reglas financieras están separadas de los campos ordinarios del perfil del proveedor. |
| Contabilidad, pagos y retiros | Registrar tipo de transacción, proveedor, importe, estado, fecha y Order relacionado | Muestras del historial financiero | El contexto financiero del marketplace puede rastrearse. |
| Orders divididos o por proveedor | Registrar relaciones entre Order principal y Orders específicos de vendedores, y el proveedor responsable | Grupos de Orders representativos | La responsabilidad histórica del vendedor puede interpretarse. |
No asuma que todo Customer con un nombre de empresa es un proveedor ni que una cuenta de administrador de proveedor contiene el registro completo del vendedor.
Preparar Customers, grupos de usuarios, direcciones y campos de cuenta
Los registros Customer de CS-Cart pueden incluir direcciones, grupos de usuarios, estado de aprobación, campos de perfil, newsletters, recompensas, reseñas e identificadores externos. Multi-Vendor también incluye administradores de proveedores, cuya propiedad debe mantenerse separada de la de los Customers ordinarios.
| Área de registro | Acción de preparación | Evidencia | Condición de preparación |
|---|---|---|---|
| Identidad Customer | Identificar duplicados, correos compartidos, invitados, aprobaciones y claves externas | Lista de excepciones de Customers | Las excepciones de identidad tienen responsable y resolución prevista. |
| Grupos de usuarios | Registrar pertenencia y cada efecto sobre precios, impuestos, acceso o contenido | Matriz de grupo a regla | El significado del grupo está documentado más allá de su etiqueta. |
| Campos de perfil | Registrar propietario del campo, tipo, obligatoriedad y uso | Inventario de campos de perfil | Los valores personalizados activos tienen una decisión de destino. |
| Direcciones | Separar perfiles reutilizables de capturas realizadas en el momento del Order | Ejemplos de Customer y Order | Los registros de cuenta y de transacción siguen siendo distintos. |
| Administradores de proveedores | Mantener la identidad del administrador del vendedor vinculada al registro del proveedor | Mapa de administradores | El acceso al marketplace no se aplana como segmentación de Customers. |
| IDs de cuentas externas | Registrar claves de CRM, ERP, fidelización o B2B | Mapa de identificadores | Los sistemas que continúan pueden localizar la misma cuenta. |
Preparar Orders, propiedad del vendedor, totales y estado histórico
La preparación de Orders debe conservar qué se compró, quién lo compró, a qué vendedor, a qué precio y bajo qué contexto histórico de pago, envío, impuestos, descuentos y estados. Los Orders de Multi-Vendor pueden dividirse para que cada proveedor gestione una parte relacionada de la compra original.
| Evidencia del Order | Acción de preparación | Condición de preparación |
|---|---|---|
| Líneas de Product y variación | Registrar ID de Product, variación/Features/opciones, vendedor, cantidad, precio y texto capturado | Los artículos comprados y la propiedad del vendedor siguen siendo interpretables. |
| Order principal y Orders por proveedor | Registrar el Order original y los Orders relacionados específicos de vendedores | El historial Multi-Vendor no se aplana como transacciones inconexas. |
| Direcciones de facturación y envío | Conservar las capturas del Order separadas de los perfiles Customer | La evidencia histórica de direcciones está completa. |
| Impuestos, envío, descuentos, tarifas y recompensas | Inventariar cada total material y la extensión propietaria | Los totales finales pueden explicarse. |
| Referencias de pago y procesamiento de pedidos | Registrar etiquetas, IDs de transacción, métodos de envío, seguimiento y proveedor responsable | El contexto histórico de procesamiento puede rastrearse. |
| Estados, reembolsos y comentarios | Registrar secuencia, visibilidad, vendedor afectado y registros relacionados | El equipo puede interpretar el ciclo de vida histórico. |
| Referencias contables | Vincular Orders con registros de comisión, pago, retiro o saldo cuando corresponda | El historial financiero del marketplace permanece conectado. |
Los Orders históricos no deben recalcularse a partir de la configuración actual de Products, planes de proveedores, comisiones, envíos o pagos.
Inventariar extensiones de plataforma, temas, campos personalizados e integraciones
Las extensiones de CS-Cart pueden ser propietarias de variaciones de Product, nombres SEO, planes de proveedores, pagos del marketplace, recompensas, reseñas, layouts, campos personalizados, totales de Order, informes o conexiones externas. Utilice “extensión de plataforma” o el nombre exacto del componente para que la funcionalidad de la plataforma no se confunda con mejoras del servicio de migración.
| Efecto de la dependencia | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Extensión de Product o catálogo | Campos/tablas, IDs de Product, configuración y registros representativos | Los valores de catálogo activos tienen un propietario definido. |
| Extensión de proveedor o contabilidad | Registros de proveedor, plan, comisión, pago o retiro | Los datos financieros del marketplace se clasifican por separado. |
| Extensión de pago o envío | Referencias históricas y resumen de configuración | La evidencia de transacciones se separa de la configuración actual de la tienda. |
| Extensión SEO o de rutas | Nombres SEO, configuración de reescrituras y tablas de redirecciones | Las rutas de origen importantes pueden reconstruirse. |
| Personalización de tema o layout | Archivos del tema, asignaciones de layouts/bloques y capturas de pantalla | El contenido empresarial se separa de la presentación. |
| Integración ERP/PIM/WMS/marketplace | Autoridad, dirección de sincronización e IDs estables | Los sistemas que continúan pueden reconectarse con las entidades de destino. |
| Tabla o campo personalizado | Esquema, claves padre, consumidor y propósito comercial | Cada valor personalizado activo tiene una resolución prevista. |
Preparar CMS Pages, nombres SEO, medios y evidencia de rutas
Prepare CMS Pages, Blog Posts cuando existan, descripciones de Product y Category, páginas de proveedores, menús, layouts, bloques, banners, archivos adjuntos y medios según su propietario y escaparate. Registre idioma, estado, ruta, escaparate, relación con el proveedor, enlaces integrados y resolución prevista.
Para rutas prioritarias de Product, Category, Feature, CMS, proveedor y Blog, registre el objeto de origen, escaparate, idioma, nombre SEO, ruta actual, importancia comercial y decisión de redirección o exclusión. Blog Posts, páginas de escaparates de proveedores y bloques CMS pueden compartir etiquetas aunque pertenezcan a propietarios diferentes, por lo que sus IDs, alcance por escaparate, relación con autor o proveedor, medios y ubicación en menús deben registrarse por separado. Conserve las imágenes originales, los archivos descargables, los adjuntos y los recursos del tema fuera de la copia de seguridad de la base de datos.
Crear el paquete de copia de seguridad y preparación de entradas
| Componente del paquete | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Copia de seguridad de la base de datos | Administrador de base de datos | Volcado con fecha/hora y nota sobre el prefijo de la base de datos | Se incluyen todas las tablas principales, de extensiones y de proveedores de la tienda prevista. |
| Archivos y medios | Responsable técnico o de hosting | Archivo de archivos o árbol de origen accesible | Imágenes, descargas, adjuntos, temas y extensiones están disponibles. |
| Registro de edición y alcance | Responsable de la plataforma | Versión, edición, escaparates, empresas/proveedores, idiomas y monedas | Las relaciones de Store Builder y Multi-Vendor son explícitas. |
| Registro de acceso | Responsable del proyecto | Responsable del acceso y estado de conexión | El acceso necesario está disponible sin exponer credenciales. |
| Registro de cambios | Administrador de la tienda | Cambios estructurales posteriores al momento de corte de la evidencia | Los cambios tardíos pueden incorporarse deliberadamente. |
Seleccionar muestras representativas para las pruebas de migración
Prepare un manifiesto de muestras con IDs de origen, motivo comercial, escaparate o proveedor propietario, archivos relacionados y relaciones de origen esperadas. El manifiesto de muestras de CS-Cart está listo cuando cada expectativa del origen, propietario de escaparate o proveedor, archivo vinculado e identificador está completa y asignada a un revisor.
Incluya como mínimo:
- Products simples y Products con opciones, Features, variaciones, varias Categories, archivos o precios especiales;
- registros con alcance en diferentes escaparates;
- Customers ordinarios, Customers de grupos de usuarios, administradores de proveedores y campos de perfil personalizados;
- Orders estándar y Orders con variaciones, totales poco habituales, reembolsos, seguimiento e IDs externos;
- para Multi-Vendor, Products propiedad de proveedores, Orders principales/secundarios, planes, comisiones, pagos o retiros;
- rutas prioritarias de CMS, Blog, Product, Category, proveedores y SEO;
- un registro activo de una extensión de plataforma y una relación con un sistema externo.
Aplicar la verificación final de preparación para CS-Cart
| Pregunta de preparación | Resultado requerido |
|---|---|
| ¿Se conocen la edición y el alcance de los escaparates? | Están registrados la versión, el modelo Store Builder o Multi-Vendor, los escaparates, los idiomas y las empresas/proveedores. |
| ¿Está completa la evidencia del catálogo? | Están representados Products, opciones, Features, variaciones, Categories, precios, medios y alcance. |
| ¿Están preparadas las relaciones del marketplace? | Proveedores, administradores, Products propiedad de vendedores, Orders, planes y registros contables tienen responsables. |
| ¿Se pueden interpretar Customers y Orders? | Grupos, perfiles, direcciones, estados, totales, contexto del vendedor e IDs externos están documentados. |
| ¿Están clasificadas las extensiones y los datos personalizados? | Cada dependencia activa tiene un propósito comercial y una decisión de destino. |
| ¿Están inventariados el contenido y las rutas? | Están documentadas las relaciones de escaparates, proveedores, CMS, Blog, medios y SEO. |
| ¿Están preparadas la copia de seguridad, el acceso y las muestras? | El paquete de origen puede restaurarse y los IDs representativos están listados. |
La preparación sigue abierta cuando todavía no se ha documentado la edición, la propiedad de proveedores, las variaciones de Product, la división de Orders, el historial contable, el alcance de escaparates o algún registro activo de extensión.
Conclusión
La preparación para CS-Cart debe reflejar el modelo operativo real. Products, opciones, Features, variaciones, escaparates, Customers, Orders, contenido y extensiones forman una capa de preparación; Multi-Vendor añade vendedores, administradores, registros de catálogo propiedad del vendedor, Orders divididos, planes, comisiones, pagos y retiros.
Un paquete de origen controlado hace explícitas esas relaciones y aporta registros representativos para configurar la migración.
Preguntas frecuentes
¿Por qué deben distinguirse CS-Cart Store Builder y Multi-Vendor antes de la migración?
Multi-Vendor incorpora proveedores, administradores de proveedores, Products propiedad del vendedor, Orders divididos, planes, comisiones, contabilidad, pagos y retiros. Esas relaciones no forman parte de un modelo de datos ordinario de Store Builder.
¿Cuál es la diferencia entre opciones, Features y variaciones en CS-Cart?
Las opciones recogen elecciones o datos introducidos por el comprador, las Features describen y clasifican Products, y las variaciones agrupan Products gestionados de forma independiente según valores de Features. Prepárelas como conjuntos de evidencia separados.
¿Cómo deben documentarse varios escaparates de CS-Cart?
Registre para cada escaparate su dominio, idioma, moneda, tema, Products, Categories, contenido, rutas, Features y alcance de empresa. Los registros compartidos y restringidos deben quedar visibles en una única matriz.
¿Qué registros de proveedores deben incluirse en un paquete de preparación para Multi-Vendor?
Incluya perfiles y estados de proveedores, administradores, propiedad de Products y Orders, planes, comisiones, transacciones contables, pagos, retiros e identificadores externos de vendedores cuando se utilicen.
¿Deben tratarse los datos de extensiones de CS-Cart como campos ordinarios de Product u Order?
No automáticamente. Registre la extensión, las entidades afectadas, sus tablas o campos, IDs representativos y el consumidor empresarial. Los registros activos necesitan un responsable explícito; los datos obsoletos pueden archivarse o excluirse.
¿Qué Orders deben seleccionarse para preparar una migración a CS-Cart?
Utilice Orders ordinarios y complejos, líneas con variaciones y opciones, distintos totales y estados, reembolsos, seguimiento e IDs externos y, cuando intervenga Multi-Vendor, Orders principales/secundarios, responsabilidad del proveedor y registros contables vinculados.