Si Wix se selecciona como plataforma de destino, la preparación debe separar registros comerciales, contenido del sitio, identidad de Members, datos CRM, colecciones CMS, aplicaciones y código personalizado antes de ejecutar cualquier migración. Wix Stores, Wix Contacts, Wix Members, Wix CMS, Wix Blog y el ecosistema más amplio de aplicaciones de Wix pueden participar dentro del mismo sitio, pero no son propietarios de los mismos registros.
Un paquete de preparación útil documenta cuatro elementos para cada área principal: la acción necesaria, el responsable, la evidencia que debe proporcionarse y la condición para considerarla preparada. Esto evita que un registro de Product se confunda con una implementación completa de la tienda online, que un Contact se trate como Member o que se presuponga que una colección CMS representa datos propiedad de una aplicación.
Confirmar el modelo operativo del sitio y del comercio en Wix
Defina qué productos y capas del sitio Wix funcionarán en la tienda de destino.
| Área de preparación | Decisión que debe registrarse | Responsable | Evidencia de preparación |
|---|---|---|---|
| Wix Stores | Si Products, checkout, Orders, inventario y procesamiento son centrales para el destino | Responsable de comercio | Resumen del funcionamiento de la tienda |
| Estructura del sitio Wix | Qué páginas, menús, páginas dinámicas, áreas de Members y rutas regionales son necesarias | Responsable del sitio | Mapa de páginas y navegación |
| Wix Contacts y Members | Qué identidades son Contacts, Customers, Members, suscriptores o participantes de aplicaciones | Responsable de Customers | Matriz de clasificación de identidades |
| Wix CMS | Qué colecciones personalizadas, referencias, permisos y páginas dinámicas siguen siendo necesarias | Responsable de contenido/datos | Inventario de colecciones y relaciones |
| Aplicaciones de Wix | Qué registros pertenecen a Wix Blog, Bookings, Pricing Plans, Reviews, Events u otras aplicaciones | Responsables de aplicaciones | Registro de dependencias por aplicación |
| Sistemas externos | Qué ERP, PIM, WMS, CRM, mercados en línea, sistemas fiscales, de envío o analítica siguen siendo autorizados | Responsable técnico | Mapa de sistemas de registro |
El modelo operativo está preparado cuando cada familia principal de registros tiene un propietario previsto en Wix o en un sistema externo y el equipo del sitio entiende qué requisitos pertenecen a los datos de migración y cuáles corresponden a configuración del sitio Wix.
Preparar accesos, archivos del origen y responsabilidad sobre cambios
Reúna:
- acceso de administrador a la plataforma de origen y al sitio Wix;
- permisos necesarios para Wix Stores, Contacts, Members, CMS, Blog, aplicaciones, dominio y SEO;
- exportaciones o copias de seguridad fechadas de Products, Customers, Orders, contenido, multimedia, Categories, URLs, Reviews y datos personalizados;
- exportaciones de aplicaciones y documentación de API cuando estén disponibles;
- identificadores externos utilizados por ERP, CRM, almacenes, mercados en línea o sistemas de procesamiento de pedidos;
- un responsable de cambios en el origen para Products, Customers, Orders, contenido e inventario durante la ventana de migración.
| Elemento de evidencia | Por qué importa | Condición de preparación |
|---|---|---|
| Registro de acceso | Confirma que pueden revisarse las áreas necesarias del origen y de Wix | Los responsables disponen de los permisos necesarios |
| Archivo fechado del origen | Conserva un estado de referencia recuperable | Los archivos se abren correctamente e incluyen fechas de exportación |
| Archivo multimedia | Protege recursos de Products, páginas, Blog Posts y CMS | Los archivos y sus relaciones de origen pueden identificarse |
| Inventario de aplicaciones | Expone registros fuera de exportaciones habituales de catálogo y contenido | Cada aplicación activa tiene un responsable y una fuente de evidencia |
| Registro de IDs externos | Protege sincronización y conciliación | Cada clave está asignada al nivel de entidad correcto |
| Registro de cambios | Registra actualizaciones del origen posteriores al archivo de referencia | Los cambios en Products, Orders, Customers, contenido e inventario tienen responsables definidos |
Cuando una aplicación de origen no pueda proporcionar una exportación, registre la limitación y el responsable en lugar de tratar los datos como inexistentes.
Preparar Products, opciones, variantes, modificadores y contenido multimedia
Wix Catalog V3 representa cada Product mediante al menos una variante. Las opciones de Products crean variantes, mientras que los modificadores recogen información adicional sin crear variantes. Prepare familias representativas de Products que hagan visibles estas diferencias.
Incluya:
- Products simples con una variante predeterminada;
- Products con varias combinaciones de opciones;
- SKU, código de barras, precio, coste, peso, contenido multimedia y stock específicos de variante;
- modificadores como mensajes de regalo, personalización o selecciones adicionales;
- Products digitales y archivos digitales a nivel de variante cuando corresponda;
- Products con marcas, ribbons, Info Sections, Categories y Customizations reutilizables;
- paquetes, suscripciones, reservas o funcionamiento de Products propiedad de aplicaciones;
- identificadores de ERP, PIM, mercados en línea, proveedores y procesamiento de pedidos.
| Funcionamiento del origen | Decisión de preparación | Evidencia necesaria | Condición de preparación |
|---|---|---|---|
| Una elección crea una combinación vendible | Definir opciones y propiedad de variantes | IDs padre/hijo, SKU, precio, peso, contenido multimedia y stock | Cada combinación tiene una variante Wix prevista |
| Una elección recoge información del comprador | Definir propiedad de modificador o aplicación | Tipo de entrada, valores admitidos, efecto sobre precio y ejemplo de línea de Order | El valor no se clasifica erróneamente como elemento con inventario |
| Product contiene datos descriptivos estructurados | Definir propietario entre campo de Product, Info Section, marca, Category, CMS o aplicación | Esquema del campo y sistema que lo seguirá utilizando | Cada campo tiene un propietario Wix o externo definido |
| El funcionamiento del Product pertenece a una aplicación | Identificar la aplicación que continuará o su sustituta | Registros de Products relacionados y evidencia de configuración | Los datos necesarios de aplicación están incluidos en el registro de dependencias |
| Product utiliza datos maestros externos | Definir el sistema de registro y la clave | IDs ERP/PIM y ejemplos de consulta | Cada identificador sigue vinculado con la variante o Product correctos |
El área de catálogo está preparada cuando cada patrón principal de Products tiene una estructura Product-variante-opción-modificador definida y la evidencia del origen distingue los datos reutilizables de Products de los datos introducidos por compradores o propiedad de aplicaciones.
Preparar ubicaciones de inventario y reglas de disponibilidad
En Wix Catalog V3, el inventario se controla a nivel de variante y ubicación. Cada Inventory Item conecta una variante con una ubicación de inventario y puede usar seguimiento por cantidad o por disponibilidad, con reglas de preorder cuando corresponda.
Prepare:
- la lista de almacenes, tiendas, centros de procesamiento y ubicaciones virtuales de inventario;
- la ubicación de inventario predeterminada en Wix;
- los identificadores de Product y variante utilizados por cada fuente de stock;
- ejemplos de cantidad, disponibilidad, stock ilimitado, preorder y no disponible;
- asignaciones entre ubicaciones del origen y Wix;
- el futuro sistema autorizado de inventario;
- cantidades iniciales y la marca temporal o instantánea del origen que representan.
| Caso de inventario | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Stock en una ubicación | Responsable de inventario | Informe de cantidad por variante | Cada cantidad se asigna a una variante Wix en la ubicación predeterminada |
| Stock en varias ubicaciones | Responsable de operaciones | Matriz variante-ubicación | Cada ubicación del origen tiene un destino previsto en Wix o sistema externo |
| Stock propiedad de ERP o WMS | Responsable de integración | Clave del sistema y ejemplo de sincronización | Los valores iniciales en Wix y la autoridad futura están documentados |
| Product con preorder | Responsable de merchandising | Reglas de preorder por variante y ubicación | Capacidad de preorder y propiedad de disponibilidad están claras |
| Seguimiento por disponibilidad sin cantidad | Responsable de catálogo | Products representativos y estados del origen | Los estados de disponibilidad no se confunden con cantidades numéricas |
No sume stock específico de ubicaciones salvo que el destino utilice intencionadamente un único grupo consolidado. La condición de preparación es una representación controlada desde la identidad vendible y ubicación del origen hasta el Inventory Item previsto en Wix.
Preparar Contacts, Members, Customers y contexto de marketing
Wix Contacts y Wix Members están relacionados, pero son distintos. Contacts puede contener identidad, etiquetas, estado de suscripción y campos ampliados. Members tiene IDs de Member, estado de cuenta, visibilidad de perfil y relaciones con Members Area. Customers comerciales y participantes de aplicaciones pueden añadir contexto adicional.
Prepare:
- compradores registrados, compradores invitados, suscriptores, Contacts, Members y participantes de aplicaciones;
- ejemplos de emails y teléfonos duplicados;
- etiquetas Contact, campos personalizados, estado de suscripción y evidencia de consentimiento;
- requisitos de estado Member, privacidad, perfil, insignias y campos personalizados;
- direcciones y relaciones históricas con Orders;
- propiedad de fidelización, reservas, Pricing Plans, comunidad o CRM;
- identificadores externos de Contact, Customer y Member.
| Tipo de identidad | Responsable de preparación | Evidencia necesaria | Condición de preparación |
|---|---|---|---|
| Comprador o invitado | Operaciones de Customers | Ejemplos de Customer y Orders | El contexto histórico de comercio está conectado con el Contact o Customer previstos |
| Contact | Responsable CRM | Etiquetas, campos, estado de suscripción y fuente de consentimiento | El significado de Contact está documentado independientemente de la membresía |
| Member del sitio | Responsable de Members Area | Member ID, Contact ID, estado, perfil y expectativas de acceso | Las identidades Member y Contact no se tratan como IDs intercambiables |
| Participante de aplicación | Responsable de aplicación | Registros de reserva, plan, fidelización, Review o comunidad | La relación con la aplicación tiene un propietario que continuará activo |
| Registro externo de CRM | Responsable de integración | ID de CRM y regla de correspondencia | La clave duradera está vinculada con la identidad Wix correcta |
La autenticación debe prepararse por separado de la identidad. Si las contraseñas del origen no pueden reutilizarse, documente el responsable y la comunicación necesaria con Customers sin tratar la portabilidad de contraseñas como datos Customer ordinarios.
Preparar Orders históricos y contexto de transacciones
Seleccione Orders que expongan identidad de Product y variante, modificadores, descuentos, impuestos, facturación, envío, pagos, transacciones, procesamiento, reembolsos y referencias externas.
Incluya:
- Orders normales, cancelados, reembolsados y parcialmente procesados;
- Orders con Products variantes y modificadores;
- Orders de invitados y Customers registrados;
- varios envíos o registros de procesamiento;
- Orders procedentes de aplicaciones relevantes para Wix o canales externos;
- referencias de mercados en línea, contabilidad, ERP, WMS, CRM o soporte.
| Área histórica | Evidencia | Condición de preparación |
|---|---|---|
| Artículos adquiridos | Ejemplos de Product, variante, modificador, cantidad y precio | La configuración adquirida puede explicarse con el paquete de evidencia del origen |
| Contexto de Customer | Identidad invitada/registrada y direcciones | La relación prevista Contact, Customer o Member está documentada |
| Contexto de pago y reembolso | Ejemplos de método, transacción, reembolso y total | Las referencias históricas están separadas de la configuración actual de pagos en Wix |
| Contexto de procesamiento | Ejemplos de envío, seguimiento, estado y asignación por línea | El procesamiento pasado puede comprenderse sin configurar el envío activo |
| Linaje externo | IDs de Orders de sistemas conectados | Las claves de conciliación se conservan al nivel correcto de Order |
Los Orders históricos conservan el comercio pasado. La configuración actual de checkout, pagos, procesamiento, notificaciones y actualizaciones de inventario en Wix sigue siendo una preparación separada propiedad de los responsables del sitio y operaciones.
Preparar colecciones CMS, páginas, Blog Posts, contenido multimedia y URLs
Wix CMS puede contener colecciones personalizadas, elementos de datos, campos de referencia, permisos, índices, relaciones con páginas dinámicas y conexiones a bases de datos externas. Las colecciones de aplicaciones Wix pueden reflejar datos propiedad de aplicaciones Wix. Prepare estas capas por separado.
Reúna:
- esquemas, campos, referencias, permisos e índices de colecciones CMS;
- elementos de datos representativos y referencias padre-hijo;
- páginas dinámicas y campos de colección utilizados en sus rutas;
- CMS Pages, Wix Blog Posts, contenido de Products y Categories y contenido propiedad de aplicaciones;
- inventarios de imágenes, vídeos, archivos y texto alternativo;
- URLs de alto valor, metadata, enlaces internos, menús, redirecciones y planes de dominio;
- propiedad de bases de datos externas y dependencias de conexión.
| Área de contenido | Responsable | Evidencia necesaria | Condición de preparación |
|---|---|---|---|
| Colección CMS | Responsable de datos/contenido | Esquema, campos, referencias, permisos y elementos de muestra | Cada colección tiene un propósito empresarial y una ruta o sistema consumidor |
| Colección de aplicación Wix | Responsable de aplicación | Nombre de la aplicación, registros del origen y expectativas de lectura/escritura | Los datos propiedad de la aplicación no se tratan como colección personalizada ordinaria |
| CMS Page o Blog Post | Responsable editorial | Contenido, contexto de autor/fecha, multimedia, metadata y URL de origen | Cada registro tiene un propietario de contenido y una ruta previstos en Wix |
| Página dinámica | Responsable del sitio | Colección, campo slug, campos de referencia y representación de página | La página puede reconstruirse a partir de relaciones documentadas |
| URL prioritaria | Responsable SEO | Ruta de origen, destino, redirección y decisión de retirada | Cada ruta de alto valor tiene un resultado aprobado |
Las redirecciones de URLs en Wix tienen restricciones propias de la plataforma, por lo que los patrones de origen no compatibles deben identificarse en el registro de rutas antes de ejecutar la migración y no después de retirar las rutas antiguas.
Inventariar aplicaciones, lógica Velo, APIs y sistemas externos
Cree un registro de dependencias para cada aplicación de Wix, aplicación del origen, API, webhook, automatización, función Velo, plugin de servicio, base de datos externa y plataforma empresarial conectada.
Para cada dependencia, registre:
- propósito empresarial;
- Products, variantes, Contacts, Members, Orders, elementos CMS o contenido afectados;
- sistema autorizado e IDs externos;
- disponibilidad de exportación o API;
- responsable de configuración y credenciales;
- decisión de continuidad, sustitución o retirada en el destino;
- evidencia del origen necesaria antes de configurar el flujo de destino.
Las dependencias prioritarias incluyen ERP, PIM, WMS, CRM, impuestos, envío, mercados en línea, fidelización, suscripciones, reservas, eventos, Pricing Plans, membresías, Reviews, búsqueda, analítica y plataformas de marketing.
El registro está preparado cuando cada campo personalizado o registro de aplicación activo tiene un propietario, entidad padre, consumidor que continuará y clave duradera definidos.
Seleccionar muestras representativas para la prueba de migración
| Muestra | Finalidad de preparación |
|---|---|
| Product simple | Establecer el patrón ordinario de Product y variante predeterminada |
| Product con varias opciones y variantes | Exponer propiedad de opciones, SKU, multimedia, precio y variantes |
| Product con modificadores | Exponer relaciones entre datos del comprador y líneas de Orders |
| Inventory Item en varias ubicaciones | Exponer propiedad variante-ubicación y autoridad sobre stock |
| Contact relacionado con Member | Exponer IDs distintos de Contact y Member y contexto de perfil |
| Order histórico complejo | Exponer variantes, modificadores, pagos, reembolsos, procesamiento e IDs externos |
| Colección CMS con referencias | Exponer esquema, relaciones padre-hijo, permisos y páginas dinámicas |
| Ruta de contenido prioritaria | Exponer propiedad de CMS, Blog, multimedia, URL y redirecciones |
| Registro propiedad de aplicación o sistema externo | Exponer la aplicación que continuará y los identificadores padre estables |
Para cada muestra, registre el ID de origen, URL de origen cuando corresponda, motivo empresarial, propietario previsto en Wix, exclusiones conocidas, claves externas y revisor responsable.
Completar la puerta de preparación para Wix
| Pregunta de preparación | Evidencia necesaria | Condición para estar preparado |
|---|---|---|
| ¿Los accesos y archivos del origen son recuperables? | Registro de acceso y exportaciones/copias de seguridad fechadas | Los registros necesarios pueden revisarse independientemente del origen activo |
| ¿Está definido el modelo operativo de Wix? | Mapa de propiedad de sitio, Stores, Contacts, Members, CMS y aplicaciones | Cada familia principal de registros tiene un propietario previsto |
| ¿Están preparadas las estructuras de Products e inventario? | Matrices Product/variante/modificador y variante-ubicación | Cada patrón vendible principal tiene una representación definida |
| ¿Están preparadas las relaciones de identidad? | Clasificación Contact/Member/Customer y reglas de correspondencia | IDs, consentimiento, acceso y relaciones con aplicaciones están documentados |
| ¿Está completa la evidencia de Orders y contenido? | Paquete histórico de Orders y registro de contenido/URLs | Las transacciones y rutas pueden explicarse desde la evidencia del origen |
| ¿Se han inventariado aplicaciones y sistemas externos? | Registro de dependencias | Cada dependencia crítica tiene un propietario que continuará |
| ¿Se han seleccionado muestras representativas? | Registro de muestras | Se cubre la complejidad de catálogo, inventario, identidad, Orders, CMS e integraciones |
| ¿Están controlados los elementos pendientes? | Registro de decisiones | Cada elemento abierto tiene responsable y fecha límite |
La puerta está completa cuando ninguna decisión crítica sobre Products, inventario, Contacts, Members, Orders, CMS, URLs, aplicaciones o sistemas externos depende de un supuesto no documentado.
Conclusión
La preparación para Wix debe producir un paquete de evidencia de sitio y comercio que separe Wix Stores, Contacts, Members, CMS, Blog, aplicaciones y sistemas externos. Los Products deben estar conectados con sus variantes y modificadores reales, el inventario debe asignarse por variante y ubicación, los registros de identidad deben conservar sus funciones distintas y los datos CMS o de aplicaciones deben tener propietarios definidos.
Cuando estas decisiones están documentadas antes de la prueba representativa de migración, el conjunto de muestras puede revelar la arquitectura prevista de Wix sin convertir diseño del sitio, acceso a cuentas o configuración activa en supuestos de datos de migración.
Preguntas frecuentes
¿Qué debe prepararse primero para una migración hacia Wix?
Comience por el mapa de propiedad de Wix. Defina qué registros pertenecen a Wix Stores, Contacts, Members, CMS, Blog, otras aplicaciones Wix y sistemas externos antes de preparar exportaciones detalladas.
¿Por qué deben prepararse por separado las opciones y modificadores de Products en Wix?
Las opciones crean variantes, mientras que los modificadores recogen información adicional sin crear variantes. Combinarlos puede producir SKUs falsos o eliminar valores introducidos por el comprador de las líneas históricas de Orders.
¿Cómo debe prepararse el inventario en varias ubicaciones?
Prepare una matriz variante-ubicación que muestre cantidades del origen, métodos de seguimiento, reglas de preorder, IDs de ubicación y futuro sistema de registro. No reduzca los datos a una única cantidad del Product padre salvo que la consolidación sea intencional.
¿Wix Contacts y Members son el mismo registro?
No. Members suele estar relacionado con Contacts, pero el Member ID y el Contact ID son distintos y los registros cumplen funciones diferentes de cuenta, perfil, privacidad y CRM.
¿Qué debe prepararse para las colecciones de Wix CMS?
Documente propósito, esquema, campos, referencias, permisos, índices, elementos representativos, páginas dinámicas, conexiones con bases de datos externas y propietario que continuará para cada colección.
¿Cuándo está completa la preparación para Wix?
Está completa cuando accesos, Products, ubicaciones de inventario, Contacts, Members, Orders, contenido, colecciones CMS, rutas, aplicaciones, sistemas externos, muestras y decisiones pendientes tienen responsables y evidencia recuperable.