Si Bagisto se selecciona como plataforma de destino, la preparación debe documentar tanto los registros comerciales como las estructuras de la aplicación Laravel que los poseen. Los Products pueden utilizar distintos tipos, familias de atributos, canales, idiomas, monedas, fuentes de inventario, Customer Groups, Categories, recursos multimedia, precios y claves de URL. Las extensiones y paquetes personalizados pueden introducir registros marketplace, B2B, de reservas, suscripciones, pagos, envíos, API o arquitectura headless fuera del modelo de catálogo ordinario.
Cada tarea de preparación debe identificar responsable, evidencia y condición para considerar el punto listo. El paquete de preparación debe distinguir evidencia de origen e implementación del destino: relaciones de Product, Orders históricos, CMS Pages, URL, identificadores externos y registros pertenecientes a paquetes forman parte de la preparación de la migración; el funcionamiento activo de pagos, envíos, impuestos, colas, búsqueda, temas y proceso de compra pertenece a la implementación del destino.
Asegurar acceso a Bagisto, Laravel, base de datos, almacenamiento y recuperación
Confirme acceso al área administrativa de Bagisto, hosting o cloud, archivos de la aplicación Laravel, configuración del entorno, base de datos, almacenamiento público y privado, recursos multimedia de Products, archivos descargables, colas y tareas programadas, registros, gestión de paquetes y servicios conectados. No copie secretos en documentación editorial; registre solo quién los controla y dónde se mantienen.
| Acción de preparación | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Confirmar acceso administrativo | Administrador de Bagisto | Cuenta operativa y resumen de permisos | Pueden revisarse Products, atributos, Customers, Orders, canales, inventario y CMS. |
| Confirmar acceso a aplicación y base de datos | Responsable técnico | Resumen de acceso a hosting, proyecto Laravel, base de datos, almacenamiento, colas, scheduler y despliegue | Puede identificarse la fuente completa y autorizada. |
| Crear copias recuperables | Responsable de infraestructura | Dump de base de datos, archivo de aplicación, copia de almacenamiento/media/descargas y responsable de restauración | La tienda de origen puede recuperarse de forma independiente al entorno activo. |
| Registrar versiones y paquetes | Responsable de desarrollo | Inventario de Bagisto, Laravel/PHP, base de datos, tema, paquetes, módulos y código personalizado | Quedan documentados los registros y extensiones dependientes de versión. |
| Mapear sistemas externos | Responsables de integraciones | Endpoints y mapas de identificadores de ERP/PIM/WMS/CRM/marketplace/búsqueda/pagos/procesamiento | Se conocen sistemas que continúan y autoridad de sincronización. |
Conserve identificadores internos y externos de Products, Products secundarios, atributos, familias, Categories, canales, fuentes de inventario, Customers, Orders, facturas, envíos, reembolsos, registros CMS, paquetes e integraciones.
Preparar tipos de Product y relaciones vendibles
Bagisto admite varios tipos de Product cuyos registros y relaciones comerciales difieren. Los Products simples representan artículos vendibles ordinarios. Los configurables usan atributos seleccionables y Products secundarios asociados. Grouped y bundle hacen referencia a otros Products. Downloadable y virtual tienen un significado de procesamiento distinto, mientras que los Products booking pueden incluir citas, eventos, alquileres, mesas, slots, capacidad y fechas.
| Tipo o patrón de Product | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Simple Product | ID de Product, SKU, precio, Category fiscal, stock, dimensiones, Category, canal, idioma, media y Order | Un único registro identifica claramente el artículo vendido y procesado. |
| Configurable Product | Principal, Products secundarios, atributos configurables, valores de opción, SKUs secundarios, precios, stock e imágenes | Cada secundario vendible puede rastrearse hasta el principal y los atributos elegidos. |
| Grouped Product | Principal, Products simples vinculados, cantidades por defecto, orden y Order representativo | El grupo se distingue de la identidad de cada Product componente. |
| Bundle Product | Opciones del bundle, tipos de entrada, Products vinculados, cantidades por defecto, obligatoriedad, precios y líneas de Order | La configuración y relaciones entre componentes están completas. |
| Downloadable Product | Archivos/enlaces, título, precio, muestra, límites, vínculo con Product y Order completado | La evidencia de acceso digital puede recuperarse. |
| Virtual Product | Identidad del servicio, precio, disponibilidad y contexto de Order | No se inventan envío ni inventario físico. |
| Booking Product | Tipo de reserva, fechas, slots, capacidad, ubicación, valores de ticket o alquiler, estado de cancelación y registro Order/reserva | Las relaciones basadas en tiempo y capacidad están documentadas. |
No dé por supuesto que un Product de origen con opciones debe convertirse en Configurable Product. Registre si cada elección crea un secundario vendible independiente, un atributo descriptivo, una selección de bundle, una opción de reserva o una entrada puntual del Customer.
Preparar atributos, familias, Categories y recursos multimedia
Los atributos de Bagisto pueden usar tipos como text, textarea, price, Boolean, select, multi-select y date-time. Las Attribute Families agrupan los atributos utilizados para crear y editar Products. Las Categories organizan Products, mientras que los recursos multimedia y URL keys siguen asociados a Products o Categories concretos.
| Estructura | Evidencia | Responsable | Condición de preparación |
|---|---|---|---|
| Atributo | Código, tipo, etiquetas, opciones, estado required/unique, uso en filtrado/comparación y comportamiento por idioma/canal | Responsable de catálogo | Se conoce la función comercial de cada atributo. |
| Attribute Family | Código/nombre, atributos agrupados, asignaciones de Product y dependencias de paquetes | Responsable de catálogo | Los Products pueden asignarse sin perder campos necesarios. |
| Atributo configurable | Atributo, valores, Product principal, secundarios y etiquetas de línea de Order | Responsable de catálogo | La identidad de variante queda separada de los datos descriptivos. |
| Category | ID, jerarquía, Products asignados, visibilidad por canal/idioma, media, metadatos y URL key | Responsables de contenido/catálogo | Taxonomía y propiedad de rutas públicas están completas. |
| Media | Product/Category propietario, función principal/galería, ruta o fuente remota, orden y contexto alt | Responsable de contenido | Cada recurso prioritario está disponible y vinculado al registro correcto. |
| Campo personalizado de paquete | Esquema, entidad propietaria, tipo, relaciones y paquete consumidor | Responsable de desarrollo | Los datos del paquete no se confunden con atributos principales de Bagisto. |
Cree un registro de campos que distinga identidad vendible, descripción de Product, filtrado, administración, claves de integración y estado perteneciente a paquetes. Etiquetas parecidas no deben fusionarse salvo que su función comercial también sea equivalente.
Preparar canales, idiomas, monedas y fuentes de inventario
Los canales de Bagisto pueden definir hostname, Category raíz, idiomas, monedas, tema, fuentes de inventario y otros elementos de contexto de Store. Las fuentes de inventario representan ubicaciones de stock que pueden asignarse a canales, y las cantidades de Product pueden existir por fuente.
| Área de contexto | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Canal | ID/código, hostname, Category raíz, idiomas, monedas, tema, fuentes de inventario y responsable | Cada contexto de cara al Customer aparece una sola vez. |
| Idioma | Código, campos traducidos de Product/Category/contenido, fallback y asignaciones de canal | Los registros localizados siguen vinculados al canal previsto. |
| Moneda | Código, uso base/por defecto, asignación de canal y propiedad de precios | Los valores comerciales no quedan separados de su moneda. |
| Fuente de inventario | ID/código, nombre, dirección, estado, prioridad, canales e ID externo de almacén | Cada ubicación de stock tiene identidad estable. |
| Cantidad de Product | ID de Product/secundario, ID de fuente, cantidad, significado reserved/available cuando proceda y sistema que gobierna el dato | Se conocen unidad vendible y ubicación de cada cantidad. |
| Estado de Product específico por canal | Product/secundario, canal, estado, visibilidad, diferencias de precio/contenido y Category | El alcance del Product es explícito, no se infiere globalmente. |
Si un ERP, WMS, marketplace o fuente de datos del proveedor controla el stock, identifique el sistema que gobierna el dato y la clave que lo conecta con Product y fuente de inventario de Bagisto.
Preparar Customer Groups, Customers, direcciones y autenticación
La preparación de Customers debe incluir identidad, Customer Group, direcciones, estado de cuenta, consentimiento, Reviews, información de empresa o fiscal cuando exista, IDs externos y dependencias de autenticación. Los paquetes pueden añadir vendedores marketplace, cuentas de empresa, presupuestos, suscripciones, fidelización u otros perfiles.
| Área de cuenta | Evidencia | Responsable | Condición de preparación |
|---|---|---|---|
| Identidad de Customer | ID, email, nombre, estado, grupo, contexto de idioma/canal e ID externo | Responsable de datos de Customers | Las identidades duplicadas y Guest se resuelven deliberadamente. |
| Customer Group | ID/código, miembros, implicaciones de precio/acceso y dependencias de paquetes | Responsable comercial | El significado del grupo está documentado más allá de la etiqueta. |
| Dirección | ID, vínculo con Customer, uso para facturación/envío, país/estado, empresa y campos fiscales | Atención al cliente | Las direcciones guardadas se distinguen de instantáneas históricas de Orders. |
| Guest Customer | Email del Order, direcciones y contexto de soporte | Responsable de Orders | El historial Guest no exige inventar una cuenta. |
| Autenticación | Esquema de contraseñas, social login/SSO, MFA, ruta de reset y responsable de comunicaciones | Seguridad | El acceso se planifica sin asumir portabilidad de credenciales. |
| Perfil de extensión | ID de Customer/usuario, entidad de paquete, rol, estado y registros comerciales relacionados | Responsable del paquete | Los datos especializados tienen destino o responsable retenido. |
Incluya Customers de varios grupos, compradores Guest, varias direcciones, cuentas inactivas y tipos de cuenta definidos por extensiones cuando afecten Orders o acceso.
Preparar Orders, facturas, envíos, reembolsos y transacciones
Prepare los Orders como evidencia comercial histórica. Incluya cabeceras, Customers o Guest, direcciones, líneas de Product y secundarios, opciones elegidas, cantidades, precios, descuentos, impuestos, envío, etiquetas de pago, historial de estados, facturas, envíos, reembolsos, transacciones, notas y referencias externas. Paquetes de reserva, marketplace, B2B o personalizados pueden añadir registros relacionados.
| Evidencia de Order | Responsable | Condición de preparación |
|---|---|---|
| Cabecera y líneas | Responsable de datos de Orders | IDs de Product/secundarios, etiquetas históricas, valores seleccionados, cantidades, precios y contexto de Customer están completos. |
| Totales y ajustes | Finanzas | Subtotal, descuento, impuestos, envío, cargos, reembolsos y total final concilian. |
| Factura y envío | Finanzas/procesamiento | Números de documento, líneas enviadas, cantidades, transportista/tracking, fechas y archivos pueden recuperarse. |
| Reembolso | Finanzas/soporte | Importes, líneas afectadas, motivos, estados e IDs de transacción relacionados están documentados. |
| Transacción | Finanzas | Se conocen etiqueta del método de pago, referencia, importe, estado y clave externa del proveedor. |
| Registro de Order perteneciente a paquete | Responsable del paquete | Reservas, vendedor, presupuesto, suscripción o procesos personalizados permanecen vinculados al Order. |
| ID externo de Order | Responsable de integración | La trazabilidad con ERP, marketplace, contabilidad o procesamiento permanece disponible. |
Los totales históricos deben mantenerse como instantáneas. No deben recalcularse con precios, Categories fiscales, Customer Groups, envío o configuración de pago actuales.
Preparar CMS Pages, URL, búsqueda y contenido comercial
El contenido de Bagisto puede incluir CMS Pages, descripciones de Product y Category, metadatos, URL keys, navegación, bloques de tema, banners, términos de búsqueda, reglas de carrito y catálogo y contenido de email/notificaciones. Las extensiones pueden introducir page builders o fuentes headless.
| Área de contenido | Evidencia | Condición de preparación |
|---|---|---|
| CMS Page | ID, título, URL key, contexto de canal/idioma, estado, contenido, metadatos y posición de navegación | El contenido CMS permanece separado de la presentación del tema. |
| Contenido Product/Category | ID de entidad, idioma/canal, descripción, metadatos, imágenes y ruta prioritaria | El contenido de catálogo sigue vinculado a la entidad correcta. |
| Navegación y bloque de tema | Responsable, jerarquía/posición, objeto enlazado, media y dependencia de paquete/tema | Los recorridos del Customer no se infieren solo desde CMS o Categories. |
| URL prioritaria | Propietario Product/Category/Page, idioma/canal, ruta de origen, backlinks o valor de tráfico e intención de destino | Cada ruta importante tiene decisión keep/change/merge/retire/redirect. |
| Búsqueda y merchandising | Términos, sinónimos, reglas, Categories, estado featured/new y sistema responsable | Búsqueda y merchandising se separan de los datos maestros de Product. |
| Promoción histórica | Regla/código, fechas, condiciones, Products/Customers afectados y referencias de Orders | La evidencia histórica de descuentos se separa de la configuración futura. |
Recopile rutas prioritarias desde analítica, datos de búsqueda, backlinks, campañas, comunicaciones con Customers y navegación interna, no solo desde el sitemap.
Inventariar paquetes, tablas personalizadas, API y dependencias headless
La arquitectura Laravel de Bagisto permite que paquetes y código personalizado registren entidades, tablas, eventos, tareas programadas, API, estructuras marketplace/B2B, reservas, funcionamiento de pago y envío, búsqueda, fuentes de datos e integraciones. Cree un registro de propiedad antes de decidir qué registros entran en alcance.
| Dependencia | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Paquete/módulo | Nombre, versión, proveedor, estado, finalidad, responsable de configuración, migraciones/tablas, modelos y registros afectados | Los datos pertenecientes al paquete tienen destino o responsable retenido. |
| Tabla o modelo personalizado | Esquema, claves, relaciones, eventos, jobs y código consumidor | Los registros pueden interpretarse en lugar de copiarse a ciegas. |
| API o cliente headless | Endpoints, recursos, responsable de autenticación, IDs, supuestos sobre la carga de datos, rutas y responsable de despliegue | Las dependencias de frontend e integración están documentadas sin exponer secretos. |
| Paquete marketplace/B2B | Vendedores/empresas, roles, catálogos, presupuestos, comisiones, pagos, aprobaciones y Orders vinculados | Los registros especializados permanecen distintos de Customers y Orders principales. |
| Servicio de búsqueda/índice | Campos indexados, IDs externos, registros fuente, responsable de reconstrucción y sinónimos/reglas | Los datos generados del índice no se confunden con contenido autoritativo. |
| Cola/proceso programado | Tarea, activador, carga de datos, destino, responsable de reintentos/errores y entidades afectadas | La automatización operativa se separa de los datos estáticos migrados. |
| Datos generados | Caché, registros, sesiones, colas, índices, importaciones temporales y tablas abandonadas | Los datos técnicos no autoritativos se excluyen deliberadamente. |
Los paquetes inactivos deben permanecer en el registro cuando sus datos todavía aparecen en Products, Customers, Orders, reservas, vendedores o informes.
Seleccionar muestras representativas para pruebas de migración
Elija registros que expongan los tipos de Product, canales, inventario, contextos de Customer, Orders, contenido y paquetes que realmente utiliza la Store. Registre IDs de origen, SKU, URL keys, canal/idioma, fuente de inventario, claves externas, registros relacionados y motivo de selección.
| Muestra | Evidencia que debe prepararse | Finalidad |
|---|---|---|
| Simple Product | Precio, impuestos, stock, Category, canal, idioma, media y Order | Establece la referencia ordinaria. |
| Familia de Configurable Product | Principal, secundarios, atributos, opciones, SKUs, precios, stock por fuente, imágenes y Orders | Representa identidad de variantes. |
| Product bundle/grouped/booking | Relaciones de componentes o slots, cantidades, precios, capacidad, datos de paquete y líneas de Order | Representa estructura comercial no simple. |
| Caso de inventario multicanal | Product/secundario, canales, idiomas, monedas, fuentes, cantidades e IDs externos de almacén | Representa contexto y propiedad del stock. |
| Customer Group o cuenta de extensión | Customer, grupo/perfil, direcciones, implicaciones de acceso/precio y Order relevante | Representa identidad segmentada o definida por paquete. |
| Order complejo | Tipo de Product, opciones, descuento, impuesto, factura, envío, reembolso, transacción e IDs externos | Representa evidencia comercial histórica. |
| Caso CMS/URL | CMS Page o contenido de catálogo, idioma/canal, URL key, metadatos, enlaces e intención de destino | Representa propiedad de contenido y rutas. |
| Registro de paquete | Entidad principal, modelo/tabla del paquete, campos personalizados, jobs/eventos y clave de integración | Expone alcance no principal antes de ejecutar. |
El paquete de muestras está listo cuando cada registro tiene hoja de expectativa de origen, contexto de canal/inventario, archivos relacionados y revisor asignado.
Completar la revisión final de preparación para Bagisto
| Área | Condición de preparación |
|---|---|
| Acceso y recuperación | Administración, aplicación Laravel, base de datos, almacenamiento, media/descargas, copias y responsable de restauración confirmados. |
| Catálogo | Tipos de Product, secundarios/componentes, atributos, familias, Categories, media, precios, stock e identificadores rastreables. |
| Canales e inventario | Canales, idiomas, monedas, fuentes, asignaciones de Product, cantidades y autoridades externas documentados. |
| Customers y Orders | Cuentas, grupos, direcciones, Orders, líneas, totales, facturas, envíos, reembolsos, transacciones e IDs externos con evidencia. |
| Contenido y URL | CMS Pages, contenido de catálogo, navegación, rutas prioritarias, metadatos, enlaces y decisiones de redirección documentados. |
| Dependencias | Paquetes, tablas/modelos personalizados, API, clientes headless, jobs, búsqueda y sistemas externos con responsables. |
| Muestras | Registros representativos cubren cada tipo material de Product, canal, Customer, Order, contenido y patrón de paquete. |
El alcance está preparado cuando cada registro material puede rastrearse hasta su propietario en origen, entidades relacionadas, evidencia y destino previsto o sistema que seguirá manteniéndolo.
Conclusión
Preparar una migración hacia Bagisto requiere evidencia coordinada sobre acceso a Laravel y base de datos, tipos de Product, atributos y familias, Categories, canales, fuentes de inventario, Customers, Orders, registros CMS, URL, paquetes, API y sistemas externos. La lista debe hacer explícitas estas relaciones antes de ejecutar, en lugar de tratar Bagisto como una simple base de datos de Product-Customer-Order.
Un paquete completo conserva evidencia recuperable del origen, separa registros principales de estructuras pertenecientes a paquetes, distingue transacciones históricas de configuración activa y asigna un responsable a cada integración o dependencia personalizada.
Preguntas frecuentes
¿Qué debe prepararse primero para una migración hacia Bagisto?
Confirme acceso a administración de Bagisto, aplicación Laravel, base de datos, almacenamiento, media, descargas, colas, scheduler y paquetes; cree copias recuperables; y registre versiones de Bagisto, Laravel, PHP, base de datos, tema y paquetes.
¿Por qué deben inventariarse por separado los tipos de Product?
Configurable, grouped, bundle, downloadable, virtual y booking utilizan relaciones distintas con secundarios, componentes, archivos, slots, capacidad y Orders. Tratarlos como Products simples eliminaría estructuras que los hacen vendibles.
¿Cómo deben prepararse los atributos y Attribute Families?
Documente códigos, tipos, etiquetas, opciones, uso en filtros o comparación, comportamiento required/unique, asignación a familias y Products y si el campo pertenece al núcleo de Bagisto o a un paquete personalizado.
¿Por qué canales y fuentes de inventario forman parte de la preparación?
Los canales pueden definir hostname, idioma, moneda, Category raíz, tema y alcance de inventario. Las cantidades pueden pertenecer a fuentes específicas, por lo que un total global no conserva ubicación ni contexto de canal.
¿Qué Orders conviene elegir como muestras representativas?
Incluya Products simples y configurables, bundles o bookings si existen, descuentos, varios impuestos, facturas, envíos, reembolsos, transacciones, Customers Guest y agrupados, IDs externos y relaciones de Orders pertenecientes a paquetes.
¿Qué debe incluir el registro de paquetes y datos personalizados?
Registre cada paquete, tabla/modelo personalizado, API, cliente headless, job, evento, servicio de búsqueda, componente marketplace/B2B y conector externo que cree o consuma datos comerciales. Cada elemento necesita responsable, registros afectados, evidencia y decisión de destino o sistema retenido.