Si ShopWired se selecciona como plataforma de destino, la preparación debe distinguir entre registros que pueden parecer similares en una exportación, pero que cumplen funciones distintas dentro de la tienda. Las variaciones de Product, las opciones de Product, los extras, los campos de personalización, la entrega digital, los Customers comerciales, las Categories, las marcas, los filtros y los datos gestionados por aplicaciones pueden cambiar el significado real de un Product o de un registro de Customer. Una lista plana de Products no basta para explicar esas relaciones.
El objetivo de la preparación es crear un paquete de evidencia del origen que asigne un responsable, un artefacto y una condición de preparación a cada área importante. Ese paquete debe describir cómo se venden los Products, en qué se diferencian los Customers comerciales de los Customers habituales, cómo conservan los Orders las opciones seleccionadas y qué aplicaciones o sistemas externos son responsables de datos que quedan fuera de los registros habituales de ShopWired.
Establecer el acceso a la cuenta y registrar el entorno de ShopWired
Empieza documentando la cuenta exacta de ShopWired, el dominio principal, el tema activo, las aplicaciones instaladas, los roles del personal, el contexto fiscal y de divisas, la capacidad de exportar Products y Orders y los sistemas externos. Registra quién es responsable del catálogo, las cuentas comerciales, los Orders, el SEO, el código del tema, las finanzas, el procesamiento logístico de pedidos y las integraciones.
Prepara el acceso compatible con la ruta de migración seleccionada. El acceso a una plataforma alojada, las exportaciones y las credenciales autorizadas de API o integración no deben presentarse como si fueran intercambiables. La persona responsable del acceso debe proporcionar el método aplicable a la tienda actual y permanecer disponible para resolver dudas sobre permisos o alcance de los datos.
| Acción | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Confirmar la cuenta y el dominio | Administrador de la tienda | Datos de la cuenta, lista de dominios, estado de la tienda | La tienda de origen correcta queda identificada sin ambigüedad. |
| Inventariar las aplicaciones instaladas | Responsable de la plataforma | Lista de aplicaciones, finalidad, datos creados, estado actual | Los datos gestionados por aplicaciones pueden separarse de los registros nativos. |
| Registrar la responsabilidad sobre el tema y el código | Responsable del tema o agencia | Versión del tema, nota sobre código personalizado, repositorio o ubicación de la copia de seguridad | Las dependencias de presentación y código tienen un responsable identificado. |
| Confirmar las exportaciones y el acceso al origen | Responsable de datos o técnico | Permisos de exportación, datos de API o fuentes de datos cuando correspondan | Puede recopilarse la evidencia de origen necesaria. |
| Iniciar un registro de cambios | Responsable del proyecto | Cambios fechados en catálogo, Customers, Orders, aplicaciones y URL | El conjunto de evidencia no quedará desactualizado sin detectarlo. |
Preparar los Products según su forma de venta
ShopWired distingue entre variaciones de Product, opciones de Product y extras de Product. Las variaciones pueden tener su propio precio, SKU, cantidad de stock, imagen, peso, GTIN, MPN, tratamiento fiscal y otros atributos. Las opciones son conjuntos reutilizables aplicados a Products y pueden añadir un coste, pero no representan variantes con stock independiente. Los extras son complementos opcionales y, en algunos casos, pueden hacer referencia a otro Product para gestionar el stock. Los campos de personalización y las cargas de archivos pueden recoger información específica indicada por el comprador.
Prepara los Products según su funcionamiento, no solo según su cantidad. Incluye ID de Product, título, SKU, estado, precio, precio de oferta, tratamiento fiscal, stock, peso, Categories, marca, filtros, imágenes, contenido, campos SEO, estructuras de variaciones, opciones, extras, campos de personalización, referencias de entrega digital e identificadores externos.
| Patrón de Product | Acción de preparación | Evidencia | Condición de preparación |
|---|---|---|---|
| Variaciones | Registrar nombres de opciones, valores, combinaciones, estado de publicación, atributos de cada variación y herencia del Product principal | Exportación de variaciones y ejemplos de Products | Las combinaciones con significado independiente quedan documentadas. |
| Opciones de Product | Registrar el conjunto global de opciones, sus valores, coste adicional, asignación a Products, carácter obligatorio y visualización condicional | Inventario de conjuntos de opciones y Products asignados | Las opciones reutilizables elegidas por el comprador no se confunden con variantes. |
| Extras de Product | Registrar la finalidad del complemento, su precio, el Product vinculado cuando se utilice y el supuesto de stock | Lista de extras y Products representativos | Los complementos opcionales tienen una responsabilidad clara. |
| Personalización o carga de archivos | Registrar la etiqueta del campo, si es obligatorio, la entrada aceptada y cómo aparece en la línea del Order | Ejemplos de Products y Orders | La información específica del comprador permanece vinculada a la compra. |
| Product digital o de servicio | Registrar el método de entrega, el responsable del archivo o acceso y el estado del Product | Lista de Products y recursos de origen | La evidencia de entrega no física está disponible. |
| Product en preventa o programado | Registrar la fecha de envío o lanzamiento y el responsable operativo | Ejemplos de Products y reglas de fecha | El funcionamiento dependiente del tiempo queda documentado. |
No conviertas opciones o extras en variaciones solo porque sus etiquetas parezcan similares. Su gestión de stock, precios, reutilización y funcionamiento dentro de los Orders son diferentes.
Preparar Categories, marcas, filtros y descubrimiento en la tienda
Un Product puede estar completo como registro y aun así resultar difícil de encontrar si la evidencia de Categories, marcas, filtros, búsqueda o navegación está incompleta. Prepara la jerarquía de Categories, las asignaciones de Products, las marcas, los valores que alimentan los filtros, los menús, las páginas de destino y las rutas importantes como estructuras independientes pero relacionadas.
| Área de descubrimiento | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Categories | Responsable del catálogo | Jerarquía, asignaciones de Products, estado, contenido de la página de destino | Cada Category que se conserve tiene una finalidad conocida. |
| Marcas | Responsable de merchandising | Lista de marcas, relaciones con Products, URL, metadatos | El descubrimiento por marca se distingue de las etiquetas descriptivas. |
| Filtros | Responsable del catálogo o búsqueda | Nombres de filtros, valores, cobertura de Products, excepciones de limpieza | Los valores utilizados por los compradores son lo bastante coherentes para su correspondencia. |
| Menús y páginas de destino | Responsable de la tienda | Mapa de navegación, capturas de pantalla, Categories y páginas enlazadas | Las rutas de presentación quedan documentadas fuera de la exportación de Categories. |
| URL prioritarias | Responsable de SEO | Rutas de Products, Categories, marcas, páginas y campañas | Las rutas de alto valor tienen un destino previsto. |
Registra los Products asignados a varias Categories, las Categories ocultas o estacionales, las áreas exclusivas para clientes comerciales y las rutas de campaña. Estos casos revelan reglas de descubrimiento que una jerarquía simple no puede mostrar.
Preparar Customers, cuentas comerciales y evidencia de direcciones
ShopWired puede admitir Customers estándar y Customers comerciales con un funcionamiento de cuenta distinto. Las funciones para comercio B2B pueden incluir precios comerciales, Products o Categories exclusivos, cuentas de crédito, promociones restringidas y estados de activación de cuenta. La preparación debe mostrar qué Customers son cuentas habituales y cuáles dependen de relaciones comerciales.
Prepara ID de Customer, nombre, correo electrónico, estado de la cuenta, direcciones, preferencias de marketing, campos personalizados, estado comercial, contexto de crédito o pago, notas internas e identificadores externos. Revisa los correos electrónicos duplicados o compartidos porque el correo puede ser importante para relacionar cuentas y Orders.
| Patrón de Customer | Acción de preparación | Evidencia | Condición de preparación |
|---|---|---|---|
| Customer estándar registrado | Registrar identidad, direcciones, estado de la cuenta y relación con Orders | Ejemplos de Customers y Orders | La identidad de la cuenta es clara. |
| Comprador invitado | Registrar correo electrónico, historial de Orders y cualquier relación posterior con una cuenta | Muestras de Orders como invitado | El historial como invitado no se interpreta automáticamente como una cuenta registrada. |
| Customer comercial | Registrar estado activo, precios comerciales, Products o Categories restringidos, contexto de crédito y campos personalizados | Registro de Customers comerciales | El significado B2B está vinculado a Customers reales. |
| Correo duplicado o compartido | Identificar los registros, el motivo comercial y el tratamiento previsto | Lista de excepciones de identidad | La identidad ambigua tiene un responsable. |
| Customer vinculado a un sistema externo | Registrar identificadores de CRM, contabilidad, ERP o soporte | Diccionario de campos de integración | Los identificadores necesarios para búsquedas posteriores siguen disponibles. |
Preparar Orders históricos y selecciones de Product
Los Orders históricos deben conservar la información necesaria para atención al cliente, finanzas y operaciones. Los Orders de ShopWired pueden incluir variaciones seleccionadas, opciones, extras, texto de personalización, referencias a archivos cargados, precios comerciales, etiquetas de entrega, contexto fiscal, descuentos, reembolsos y notas. Selecciona Orders que hagan visibles cada uno de estos patrones.
| Área del Order | Acción | Evidencia | Condición de preparación |
|---|---|---|---|
| Configuración del Product | Incluir las selecciones de variación, opción, extra y personalización | Líneas de Order representativas | La configuración comprada puede interpretarse. |
| Identidad del Customer | Distinguir Orders registrados, de invitado y comerciales | Muestras de distintos escenarios | La titularidad del Order es clara. |
| Precios y descuentos | Incluir precio comercial, precio de oferta, cupón, ajuste manual y casos fiscales | Muestras de componentes del total | El contexto comercial histórico queda documentado. |
| Entrega y procesamiento logístico | Registrar método de entrega, estado, seguimiento, recogida y gestión inusual | Ejemplos de Orders y envíos | El historial logístico tiene un significado conocido. |
| Reembolsos y cancelaciones | Incluir importe, estado, notas y Order relacionado | Conjunto de Orders excepcionales | El historial financiero y de servicio sigue siendo comprensible. |
| Referencias externas | Registrar identificadores de contabilidad, ERP, canal de venta externo, logística o soporte | Orders sensibles a integraciones | Se identifican los valores necesarios para búsquedas posteriores. |
La evidencia histórica de Orders debe describir lo que ocurrió. No debe utilizarse como sustituto de la configuración activa de pagos, entrega, impuestos, correo electrónico o proceso de compra en la nueva tienda.
Inventariar aplicaciones, API, webhooks, fuentes de datos y código personalizado
Crea un registro de dependencias para cada aplicación de ShopWired, fuente de datos de Products, conexión con canales de venta externos, herramienta contable, CRM, ERP, servicio logístico, sistema de almacén, integración de analítica, flujo de API, webhook y personalización del tema. Registra si la dependencia crea datos, los consulta, modifica el proceso de compra o la visualización, cambia el stock o utiliza identificadores que deben seguir siendo localizables.
| Campo de dependencia | Detalle requerido | Condición de preparación |
|---|---|---|
| Responsable y finalidad | Responsable de negocio, responsable técnico, proceso compatible | La responsabilidad es explícita. |
| Objetos de datos | Products, Customers, Orders, stock, Categories, contenido o campos personalizados utilizados | Se conocen los registros afectados. |
| Dirección y frecuencia | Lectura, escritura, bidireccional, programada, basada en eventos o manual | La fuente de autoridad está documentada. |
| Identificadores | SKU, ID de Product, correo del Customer, número de Order, clave externa | Las dependencias de búsqueda se conservan. |
| Decisión de transición | Reconectar, reconstruir, retirar, sustituir o revisar | Ninguna dependencia se considera automáticamente operativa tras la migración. |
Incluye el código del tema cuando modifica las opciones de Product, la visibilidad comercial, la navegación, la presentación del contenido o la captura de Orders. El código únicamente visual y el código que gestiona datos no deben tratarse como el mismo tipo de riesgo.
Preparar contenido, medios, URL y evidencia del tema
Prepara páginas, contenido de blog o guías, políticas, formularios, recursos multimedia, archivos descargables, descripciones de Products y Categories, páginas de marca, metadatos, enlaces internos, expectativas de canonical y redirecciones. Registra qué contenido es nativo, cuál pertenece a una aplicación y cuál está integrado en el código del tema.
| Área de contenido | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Contenido de Products y Categories | Responsable del catálogo o marketing | Exportaciones, rutas de medios, páginas representativas | El contenido comercial puede asociarse con sus registros. |
| Páginas y políticas | Responsable de contenido | Inventario de páginas, estado, ruta, enlaces internos | Se registran las decisiones de conservar, reconstruir, combinar o excluir. |
| Recursos digitales | Responsable de operaciones o contenido | Archivos originales, relación con Products, reglas de acceso | Los archivos de origen están disponibles. |
| Rutas SEO | Responsable de SEO | URL prioritarias, metadatos, redirecciones, rutas de campaña | Los datos necesarios para mantener la continuidad de las rutas están completos. |
| Contenido dependiente del tema | Responsable del tema | Ubicaciones en plantillas, secciones personalizadas, capturas de pantalla | Se identifica el contenido oculto dentro del código de presentación. |
Preparar exportaciones, copias de seguridad y control de cambios del origen
Crea un archivo fechado que contenga exportaciones de Products, Customers, Customers comerciales, Orders, Categories, marcas, filtros, contenido y datos relacionados con aplicaciones, junto con recursos multimedia, capturas de pantalla, documentación de API o fuentes de datos, copia de seguridad del tema y notas explicativas. Conserva sin modificar las exportaciones originales y realiza la limpieza en copias de trabajo.
| Conjunto de evidencia | Contenido requerido | Condición de preparación |
|---|---|---|
| Exportaciones principales | Archivos, fecha de exportación, conjunto de campos, contexto de cuenta, checksum | Los registros están completos y pueden atribuirse a su origen. |
| Evidencia de opciones | Variaciones, opciones, extras, campos de personalización, asignaciones de Products | La forma de venta no se pierde en una exportación que solo contenga Products. |
| Tema y medios | Copia de seguridad del tema o registro de código, imágenes, descargas, recursos cargados | Pueden localizarse la presentación y los archivos de origen. |
| Registros de dependencias | Lista de aplicaciones, fuentes de datos, notas de API o webhook, identificadores externos | La responsabilidad de cada integración queda documentada. |
| Registro de cambios | Products, Customers, Orders, URL, aplicaciones y reglas comerciales nuevos o modificados | Los cambios posteriores en el origen pueden reconciliarse. |
Seleccionar registros representativos para una prueba de migración
Selecciona muestras que revelen estructuras distintas de ShopWired en lugar de limitarse a registros ordinarios. Cada muestra debe incluir una breve expectativa de origen que explique por qué se ha seleccionado y qué campos o relaciones son importantes.
| Grupo de muestra | Incluir | Objetivo de preparación |
|---|---|---|
| Products | Product simple, Product con varias variaciones, Product con muchas opciones, extra, Product con personalización o carga de archivos, Product digital, Product exclusivo para clientes comerciales | Hacer visibles distintas formas de venta. |
| Customers | Registrado, invitado, comercial, con contexto de crédito, excepción de correo duplicado, Customer con ID externo | Representar diferencias de identidad y B2B. |
| Orders | Variación, opciones, personalización, precio comercial, descuento, reembolso, entrega inusual, referencia externa | Conservar el contexto histórico. |
| Descubrimiento | Category prioritaria, marca, conjunto de filtros, ruta de menú, página de destino | Preparar evidencia de la estructura de la tienda. |
| Contenido e integraciones | Página sensible para SEO, recurso digital, campo gestionado por una aplicación, registro de fuente de datos o API | Representar dependencias no principales. |
El paquete de muestras está preparado cuando cada registro seleccionado tiene una expectativa de origen, evidencia vinculada, identificadores relevantes y una persona responsable de revisarlo.
Completar la puerta de preparación para ShopWired
| Verificación final | Condición de preparación |
|---|---|
| Acceso | Se confirman la cuenta correcta, las exportaciones, las aplicaciones, la responsabilidad del tema y los contactos técnicos. |
| Products | Se documentan variaciones, opciones, extras, personalización, entrega digital, visibilidad comercial e identificadores. |
| Descubrimiento | Se preparan Categories, marcas, filtros, menús y rutas prioritarias. |
| Customers | Se comprenden los casos estándar, de invitado, comerciales, duplicados, direcciones e ID externos. |
| Orders | Pueden interpretarse las selecciones de Product, totales, entrega, reembolsos, notas y referencias externas. |
| Dependencias | Aplicaciones, API, webhooks, fuentes de datos, código del tema y sistemas externos tienen una decisión definida. |
| Entradas | Están disponibles exportaciones, recursos, copias de seguridad, checksums y registro de cambios. |
| Muestras | Los registros representativos de migración cubren patrones de origen ordinarios y complejos. |
Conclusión
La preparación para ShopWired debe mantener la diferencia entre variaciones, opciones, extras, personalización, funcionamiento comercial y datos gestionados por aplicaciones. Esas distinciones determinan si un Product, Customer u Order sigue siendo comprensible fuera de la tienda de origen.
Cuando el acceso, las relaciones del origen, las exportaciones, los recursos, las dependencias y los registros representativos están documentados, puede configurarse la migración con una comprensión estable y verificable del origen que debe representarse en ShopWired.
Preguntas frecuentes
¿Por qué deben inventariarse por separado las variaciones, opciones y extras?
Porque tienen comportamientos distintos de precios, stock, reutilización y Orders. Tratarlos como una única estructura genérica de opciones puede eliminar significado comercial importante.
¿Qué Products de ShopWired deben incluirse en el conjunto de muestras?
Incluye Products simples, variaciones, opciones, extras, Products con personalización o carga de archivos, Products digitales o de servicio, Products exclusivos para clientes comerciales y registros con identificadores externos.
¿Cómo deben prepararse los Customers comerciales?
Documenta el estado activo, los precios comerciales, los Products o Categories restringidos, el contexto de crédito, los campos personalizados, las direcciones, el historial de Orders y cualquier identificador de sistemas externos.
¿Deben vincularse los Orders de invitados a Customers registrados durante la limpieza?
Solo cuando la empresa haya aprobado esa relación de identidad. Las direcciones de correo compartidas o reutilizadas pueden hacer que una consolidación automática sea poco fiable.
¿Qué información sobre aplicaciones se necesita antes de la migración?
Registra qué hace la aplicación, qué registros consulta o crea, sus identificadores, su responsable, la frecuencia de integración y si se reconectará, reconstruirá, retirará o sustituirá.
¿Cómo deben controlarse los cambios posteriores a la fecha de exportación?
Mantén un registro fechado de cambios en Products, Customers, Orders, URL, aplicaciones, código del tema y reglas comerciales para poder reconciliarlos con la evidencia preparada.