Al evaluar Wix como posible plataforma de destino, el riesgo de migración aparece cuando se presupone que la base de datos, el tema, los scripts de checkout, las extensiones de Products o los registros de aplicaciones de la tienda de origen se convertirán en datos normales de Wix Stores. Wix combina comercio, creación de sitios web, datos CMS, funciones de relación con Customers, Members, aplicaciones y comportamiento programable dentro de una plataforma administrada, pero cada uno de estos dominios conserva propietarios y responsabilidades diferentes.
La arquitectura actual del catálogo de Wix añade otro límite importante: Catalog V3 utiliza variantes universales, separa opciones de modificadores y administra el inventario por variante y ubicación. Los Orders pertenecen a un dominio eCommerce más amplio con facturación, transacciones, facturas, procesamiento y configuración separados. Las colecciones CMS y sus campos de referencia pueden respaldar aplicaciones personalizadas del sitio, pero no sustituyen automáticamente entidades de Product, Customer, Order o registros propiedad de aplicaciones.
Por ello, cada cadena de riesgo debe hacer explícitos el supuesto de partida, la restricción de Wix, la consecuencia para la migración, el impacto operativo, la dirección de mitigación y la señal de control.
Límites entre sitio Hosted, comercio, CMS y aplicaciones
Wix no expone una base de datos genérica de destino en la que pueda copiarse cualquier tabla del origen. Los datos deben pertenecer a Wix Stores, eCommerce Orders, Contacts, Members, colecciones CMS, una aplicación de Wix, código Velo, un plugin de servicio o un sistema externo. El diseño del sitio y el funcionamiento de páginas dinámicas constituyen capas adicionales.
| Supuesto del origen | Restricción de Wix | Consecuencia para la migración | Impacto operativo | Señal de mitigación | Señal de control |
|---|---|---|---|---|---|
| Las tablas del origen pueden reproducirse directamente. | Wix utiliza recursos empresariales definidos, esquemas CMS, aplicaciones y APIs. | Los registros personalizados se reducen a campos o se sitúan en un dominio incorrecto. | El personal pierde estados de procesos, contexto para informes o vínculos externos. | Clasifique cada entidad no estándar por propietario y ciclo de vida antes de definir su representación. | Cada registro necesario tiene un propietario compatible en Wix o en un sistema externo. |
| Los datos del tema y del constructor de páginas migran junto con los registros. | Las páginas, secciones, páginas dinámicas, plantillas y presentación móvil de Wix son implementación del destino. | El contenido existe sin el layout o las interacciones que lo hacían utilizable. | Recorridos importantes quedan incompletos aunque los datos comerciales estén presentes. | Separe contenido duradero y referencias de la implementación de presentación. | Cada página clave tiene propietarios claros de contenido, ruta y funcionamiento. |
| Los scripts de checkout son campos ordinarios de Orders. | El funcionamiento activo del checkout depende de configuración de Wix, extensiones, plugins de servicios, aplicaciones y rutas de código compatibles. | Desaparecen cargos, reglas de aprobación, entradas personalizadas o comportamiento de proveedores. | Los nuevos Orders no pueden seguir las reglas empresariales necesarias. | Represente los datos históricos por separado y asigne el comportamiento futuro a un propietario que continúe activo. | La regla empresarial necesaria tiene un propietario explícito de implementación en Wix o un sistema externo. |
| Los registros de aplicaciones forman parte del núcleo de Wix Stores. | Bookings, Events, Restaurants, Pricing Plans, fidelización, suscripciones y otras aplicaciones poseen entidades propias. | Los registros especializados se reducen a Contacts, Products o notas de Orders. | Programaciones, derechos, saldos o historial de participantes dejan de ser utilizables. | Conserve las referencias al registro padre y traslade el registro especializado a su dominio real. | La aplicación que continúa operando reconoce el Contact, Product y transacción previstos. |
Este límite está en el origen de muchos riesgos de Wix y debe resolverse antes de considerar los campos individuales como alcance de migración.
Riesgo de Catalog V1, Catalog V3 y linaje de Products
Wix Catalog V3 no es solo un nuevo nombre de endpoint. Utiliza variantes universales, de modo que cada Product tiene al menos una variante incluso cuando no presenta opciones. Las opciones crean variantes y afectan al inventario. Los modificadores recogen información adicional sin crear variantes. Los Inventory Items se administran por separado y pueden representar una variante en una ubicación.
Las tiendas de origen y las integraciones antiguas de Wix todavía pueden reflejar supuestos de Catalog V1. El riesgo aumenta cuando registros antiguos o del origen se representan sin definir qué generación del catálogo y qué nivel de detalle de Product utilizará la tienda de destino.
| Supuesto | Restricción del catálogo | Consecuencia para la migración | Impacto operativo | Dirección de mitigación | Señal de control |
|---|---|---|---|---|---|
| Un Product sin opciones no tiene variante. | Catalog V3 utiliza una variante universal predeterminada. | Los identificadores y el stock a nivel de Product se representan de forma incoherente con sistemas basados en variantes. | Las actualizaciones de inventario e integraciones no pueden localizar la unidad vendible prevista. | Defina una identidad de variante de destino para cada Product, incluidos Products simples. | Cada Product tiene una variante vendible estable reconocida por las integraciones. |
| Los registros de Catalog V1 y V3 son intercambiables. | V3 cambia los límites entre Product, variante, customization, inventario y servicios relacionados. | IDs o relaciones se reutilizan bajo el modelo equivocado. | La sincronización del catálogo crea duplicados o no detecta cambios de variantes. | Registre el linaje del catálogo de origen y el mapa de entidades V3 del destino. | Cada Product y variante del origen se resuelve una sola vez en el catálogo de destino. |
| Crear un Product crea automáticamente todas sus relaciones de inventario. | Product e Inventory Item pueden crearse mediante operaciones separadas. | Existen Products sin los registros de inventario previstos. | Los artículos parecen vendibles, pero no siguen el funcionamiento de stock por ubicación. | Trate la identidad Product/variante y los Inventory Items como registros conectados pero separados. | Cada variante con seguimiento tiene la relación de inventario prevista con su ubicación. |
| Los datos de Products de una aplicación antigua son datos nativos de Catalog. | Las aplicaciones pueden ampliar o referenciar Products mediante sus propias entidades. | El comportamiento propiedad de la aplicación se copia como campos de Product sin explicación. | El personal ve valores que ningún flujo de Wix mantiene. | Mantenga separadas las entidades de aplicación y los Products del catálogo, conservando sus claves. | La aplicación puede resolver el Product o variante que amplía. |
Los propietarios afectados son los equipos de catálogo, integración y cualquier sistema que utilice IDs de Product o variante. La mitigación requiere un mapa de linaje, no una conversión genérica de campos.
Riesgo de opciones, modificadores, variantes y personalización
Las Customizations de Catalog V3 distinguen opciones y modificadores. Las opciones crean combinaciones con SKUs, precios e inventario diferentes. Los modificadores recogen texto o selecciones sin cambiar la identidad de variante o inventario. Los catálogos de origen suelen colocar talla, color, grabado, embalaje, mejoras de servicio, garantías y especificaciones dentro de una misma tabla de opciones.
| Patrón del origen | Restricción de Wix | Consecuencia para la migración | Impacto operativo | Señal de mitigación | Señal de control |
|---|---|---|---|---|---|
| Talla o color se tratan como metadata descriptiva. | Las elecciones vendibles deben formar variantes cuando poseen SKU, precio o stock. | El Product muestra el valor, pero no puede administrar la combinación adquirida. | Inventario y procesamiento utilizan el artículo incorrecto. | Conserve la relación opción-elección-variante. | La opción seleccionada resuelve la variante e Inventory Item previstos. |
| Grabado o texto libre se convierten en una opción. | Las opciones crean variantes; los modificadores recogen datos sin cambiar inventario. | El catálogo genera combinaciones sin sentido para cada ruta de personalización. | La administración de Products y del stock se vuelve inmanejable. | Utilice propiedad de tipo modificador para entradas que no afectan al inventario. | La información del Customer aparece en la transacción sin crear una variante. |
| Los extras de pago se convierten automáticamente en variantes. | Algunos extras cambian el precio pero no la identidad de inventario y pueden pertenecer a una aplicación o modificador. | Variantes artificiales fragmentan la elaboración de informes y la disponibilidad. | El personal no puede distinguir el Product base de un servicio opcional. | Defina si el extra pertenece a un modificador, aplicación, paquete o flujo externo. | Los detalles del Order muestran el extra mientras el inventario base sigue siendo coherente. |
| Los componentes de un paquete se almacenan como texto de Product. | El stock y procesamiento de componentes necesitan una relación separada. | La oferta es visible, pero no puede calcularse la disponibilidad de componentes. | Se producen ventas por encima del stock y errores de preparación. | Asigne la lógica de componentes a una aplicación compatible o sistema externo. | El sistema responsable del stock puede identificar cada componente. |
| Las especificaciones se convierten en dimensiones de variante. | Info Sections, marcas, Categories y otros campos de catálogo pueden describir Products sin crear combinaciones. | Aumenta el número de variantes y los compradores encuentran elecciones irrelevantes. | El mantenimiento del catálogo se vuelve complejo y propenso a errores. | Mantenga la información no seleccionable fuera de las dimensiones de opciones. | Las especificaciones siguen siendo reutilizables o descriptivas sin cambiar la identidad de variante. |
El riesgo queda controlado cuando cada entrada del comprador tiene un efecto claro sobre identidad vendible, inventario, precio, procesamiento o contexto histórico del Order.
Riesgo de inventario por variante y ubicación
Los Inventory Items de Wix pueden seguir el stock de una variante específica en una ubicación específica. Las ubicaciones pueden representar tiendas, almacenes o centros de procesamiento. Esto crea un modelo de riesgo más granular que una única cantidad por Product.
| Supuesto | Restricción de inventario | Consecuencia para la migración | Impacto operativo | Dirección de mitigación | Señal de control |
|---|---|---|---|---|---|
| Una cantidad del origen puede copiarse al Product. | El inventario pertenece a relaciones variante-ubicación. | La cantidad queda separada de la unidad vendible y de la ubicación de procesamiento. | Customers ven disponibilidad incorrecta y el personal procesa desde el grupo de stock equivocado. | Represente cada propietario de stock del origen mediante una variante y ubicación de destino. | Totales por ubicación y variante coinciden con el modelo operativo declarado. |
| Todos los Products deben tener seguimiento de stock. | Servicios, bienes digitales, artículos ilimitados y disponibilidad controlada externamente pueden usar reglas diferentes. | Las ofertas sin stock quedan indisponibles o aparecen cantidades engañosas. | Se bloquean ventas válidas o Products no compatibles permanecen expuestos. | Clasifique por separado casos con seguimiento, ilimitados, preorder y stock externo. | Cada clase de inventario produce el funcionamiento de venta previsto. |
| Crear el Product demuestra que el inventario está completo. | Los Inventory Items pueden requerir creación y propiedad separadas. | Los Products existen con registros de stock ausentes. | El personal asume que el stock migró porque el catálogo es visible. | Incluya las relaciones de Inventory Item dentro del modelo de catálogo. | Cada variante con seguimiento tiene un Inventory Item identificable en la ubicación prevista. |
| Una instantánea basta para un catálogo administrado por ERP. | Los sistemas externos continúan publicando stock después de la migración. | Las cantidades iniciales son correctas, pero las actualizaciones posteriores fallan o se vinculan de forma incorrecta. | El inventario por canal se desvía rápidamente. | Conserve claves de Product, variante, ubicación y sistema externo. | Una actualización continua alcanza el registro variante-ubicación previsto. |
| Los Orders históricos deben reproducir cambios de stock. | Las transacciones históricas y el inventario inicial tienen responsabilidades distintas. | La cantidad se descuenta una segunda vez. | La tienda comienza con stock disponible incorrecto. | Establezca el inventario inicial independientemente del historial importado de Orders. | Los Orders históricos no modifican la posición de stock inicial aprobada. |
El riesgo de inventario puede afectar a los ingresos con rapidez, pero el control estructural es claro: Wix y cada propietario externo del stock deben utilizar la misma identidad de variante y ubicación.
Contacts, Members, Customers y participantes de aplicaciones
Los Contacts de Wix pueden representar personas que interactúan con el sitio, mientras que Members añade relaciones de cuenta y acceso. Customers comerciales, remitentes de formularios, suscriptores, clientes de reservas, participantes de eventos, titulares de Pricing Plans, participantes de fidelización y perfiles de aplicaciones pueden solaparse sin ser la misma entidad.
| Supuesto del origen | Restricción de Wix | Consecuencia para la migración | Impacto operativo | Señal de mitigación | Señal de control |
|---|---|---|---|---|---|
| Todo Customer debe convertirse en Member. | La identidad Contact y el acceso Member son relaciones separadas. | Compradores invitados adquieren expectativas de acceso no compatibles o se pierde acceso exclusivo para Members. | El soporte de cuentas y el contenido protegido se vuelven incoherentes. | Conserve por separado el historial de comprador y los derechos Member. | Solo los usuarios previstos reciben acceso Member y los Orders siguen vinculados con el Contact correcto. |
| El email por sí solo demuestra una identidad única. | Duplicados del origen, emails compartidos, direcciones cambiadas e IDs externos pueden representar historiales distintos. | Contacts se combinan incorrectamente o una persona se convierte en varios registros. | Marketing, soporte e historial de Orders dejan de ser fiables. | Utilice IDs del origen, vínculos con Orders, email, teléfono y claves externas dentro de una jerarquía de identidad documentada. | Las personas de alto valor y los casos ambiguos resuelven el Contact previsto. |
| El consentimiento de suscripción es un dato ordinario de Contact. | El permiso de comunicación tiene propósito y procedencia separados de la identidad. | Contacts importados pueden considerarse aptos para marketing sin una relación válida. | Se debilitan cumplimiento y segmentación. | Conserve únicamente información de preferencias compatible y con significado claro. | Los flujos de marketing distinguen identidad de permiso de comunicación. |
| Los participantes de aplicaciones pertenecen a campos personalizados de Contact. | Bookings, Events, Pricing Plans, fidelización y otras aplicaciones poseen registros especializados. | Datos de programación, derechos, progreso o saldo se reducen a campos simples. | Atención a Customers no puede comprender la relación activa. | Mantenga el vínculo con Contact y migre o archive la entidad especializada bajo su propietario real. | La aplicación que continúa activa reconoce el Contact y registro de participación previstos. |
| Los IDs de CRM externo pueden sustituirse. | CRM y sistemas de soporte pueden considerar la clave existente como autorizada. | Las actualizaciones crean Contacts duplicados o se vinculan con el registro equivocado. | Segmentación e historial de soporte se fragmentan. | Conserve identificadores externos duraderos al nivel de Contact u organización utilizado por el CRM. | Una consulta en CRM devuelve el Wix Contact previsto. |
El control es un modelo de identidad por capas: las relaciones Contact, Member, Customer, participante y cuenta externa permanecen conectadas sin reducirse a una sola entidad.
Orders, facturación, transacciones, procesamiento y configuración
Los eCommerce Orders de Wix administran el ciclo posterior a la compra y conectan artículos adquiridos, detalles de pago, información de envío y estado de procesamiento. Wix también separa Order Billing, Order Transactions, Invoices, Payment Requests, Fulfillments y Order Settings. La migración histórica debe conservar evidencia en estas áreas sin asignar autoridad operativa actual a registros antiguos.
| Cadena de riesgo | Consecuencia para la migración | Impacto operativo | Dirección de mitigación | Señal de control |
|---|---|---|---|---|
| Un único estado del origen se copia como estado completo del Order. | Se comprimen los significados de pago, procesamiento, cancelación, factura y reembolso. | El personal no puede saber si sigue pendiente dinero o mercancía. | Conserve un estado histórico legible mediante las relaciones de Order relevantes. | Los Orders complejos pueden comprenderse sin acceso al sistema de origen. |
| Las líneas de Order solo se vinculan al Product padre. | Se pierde la variante adquirida, modificador o configuración propiedad de aplicación. | Soporte y procesamiento no pueden identificar qué se compró. | Conserve instantáneas de líneas y referencias fiables a Product/variante/customization. | El detalle muestra la identidad vendible y la entrada del comprador previstas. |
| Los datos históricos de pago se tratan como autoridad activa. | Los detalles de pago y Transactions documentan el pasado; proveedores y configuración actuales son independientes. | El equipo espera que credenciales o tokens antiguos procesen nuevo comercio. | Conserve referencias seguras de transacciones y configure el comportamiento actual de pago de forma independiente. | Los pagos históricos son rastreables sin exponer ni reutilizar credenciales. |
| Las etiquetas de envío recrean el procesamiento actual. | Fulfillments, configuración de entrega, transportistas y ubicaciones tienen propiedad actual separada. | Los nuevos Orders siguen rutas incompletas. | Conserve evidencia histórica de envíos y defina el procesamiento activo por separado. | Responsabilidades históricas y activas de procesamiento son distinguibles. |
| Los Orders importados activan actualizaciones actuales de inventario. | El historial de Orders y los Inventory Items iniciales tienen fines diferentes. | El stock vuelve a descontarse o se sincroniza incorrectamente. | Mantenga la importación histórica de Orders aislada de la autoridad sobre stock inicial. | El inventario permanece estable después de introducir los registros históricos. |
Los propietarios afectados son atención a Customers, finanzas, operaciones e integraciones. La mitigación consiste en conservar la evidencia histórica mientras la configuración actual de Wix mantiene la autoridad operativa.
Riesgo de colecciones CMS, páginas dinámicas y campos de referencia
Las colecciones de Wix CMS pueden almacenar elementos de datos estructurados y campos de referencia. Pueden alimentar páginas dinámicas, directorios, recursos, contenido personalizado de la tienda y flujos de aplicaciones. También pueden conectarse con bases de datos externas. Esta flexibilidad crea el riesgo de trasladar tablas personalizadas del origen a CMS sin conservar esquema, referencias, permisos, código o funcionamiento de páginas.
| Supuesto del origen | Restricción de CMS | Consecuencia para la migración | Impacto operativo | Dirección de mitigación | Señal de control |
|---|---|---|---|---|---|
| Una tabla del origen puede convertirse automáticamente en una colección CMS. | Campos de colección, esquemas de elementos, permisos, referencias, índices y páginas o código consumidores son independientes. | Las filas se transfieren mientras desaparecen relaciones y funcionamiento de edición. | Las páginas dinámicas muestran datos incompletos o no resuelven registros relacionados. | Defina esquema de colección, campos de referencia, permisos y consumidores como un único modelo. | Los elementos representativos resuelven todas las referencias y relaciones de página necesarias. |
| Los IDs numéricos del origen pueden copiarse como referencias. | Las referencias CMS deben apuntar a identidades de elementos de datos en el destino. | IDs antiguos se convierten en valores literales sin significado. | Registros relacionados y páginas dinámicas se desconectan. | Represente las relaciones del origen mediante campos de referencia del destino. | Cada relación padre-hijo o muchos-a-muchos se resuelve dentro de Wix CMS. |
| Actualizar un elemento conserva valores no especificados. | Algunas operaciones de actualización sustituyen el contenido del elemento cuando se omiten campos. | La sincronización parcial elimina datos de forma inesperada. | Sistemas externos borran campos que no les pertenecen. | Defina propiedad de campos y comportamiento seguro de actualización para integraciones continuas. | Las actualizaciones cambian únicamente los campos propiedad del sistema que publica. |
| Los datos CMS reflejan inmediatamente cada escritura en todos los contextos. | La recuperación de datos puede mostrar consistencia eventual en algunos flujos. | Automatizaciones o lecturas del frontend actúan sobre un estado desactualizado. | Aparecen acciones duplicadas o incoherencias temporales. | Diseñe integraciones que toleren propagación y utilicen gestión autorizada de eventos/estado. | Los flujos sensibles al tiempo no dependen de lectura inmediata después de escritura. |
| CMS puede sustituir dominios de Product, Order o aplicaciones. | CMS es almacenamiento flexible, pero no reproduce el funcionamiento de Wix Stores o de aplicaciones. | Registros comerciales principales o participantes se duplican en un modelo paralelo sin gobierno. | El personal mantiene fuentes de verdad contradictorias. | Use CMS solo cuando sea el propietario real en el destino, no como tabla genérica de desborde. | Cada entidad tiene un único sistema de registro declarado. |
El riesgo de CMS queda controlado cuando esquema, referencias, permisos, rutas y código que consumen los datos se tratan como una misma cadena de dependencias.
Riesgo de páginas, URLs, contenido multilingüe y SEO
La estructura de un sitio Wix puede incluir páginas estáticas, páginas dinámicas, rutas de Products y Categories, Blog Posts, menús, contenido multimedia, formularios, versiones multilingües, dominios, metadata SEO y redirecciones. Las rutas de la tienda de origen y las estructuras creadas por constructores de páginas no se trasladan necesariamente de forma directa.
| Dependencia del origen | Restricción de Wix | Consecuencia para la migración | Impacto operativo | Señal de mitigación | Señal de control |
|---|---|---|---|---|---|
| Los registros de Products o Categories recrean la navegación. | Categories, menús, páginas y rutas dinámicas de Wix están relacionados pero son independientes. | Los registros de catálogo existen sin la ruta de exploración prevista. | Los compradores no pueden encontrar Products de alto valor. | Asigne propietarios de navegación y páginas de destino independientemente de la pertenencia a Categories. | Las rutas prioritarias de compra alcanzan el Product o destino de Category previsto. |
| Las URLs del origen pueden mantenerse sin cambios automáticamente. | Las rutas dependen de estructuras de páginas, catálogo, idiomas y dominios de Wix. | Rutas de alto valor cambian sin continuidad. | Fallan tráfico orgánico, backlinks y marcadores. | Defina destinos canónicos y relaciones de redirección para URLs prioritarias. | Las rutas antiguas prioritarias resuelven recursos de destino utilizables. |
| Los datos del constructor de páginas son contenido portátil. | Secciones, componentes, páginas dinámicas, aplicaciones y código de Wix definen la presentación. | El texto se transfiere, pero formularios, consultas, interacciones y relaciones de layout desaparecen. | Los recorridos de contenido y compra quedan incompletos. | Separe contenido y multimedia duraderos de la presentación y funcionamiento del destino. | Cada página clave tiene propietarios operativos de contenido, ruta e interacción. |
| El idioma es un único campo del registro de origen. | El contenido multilingüe puede requerir coordinación entre rutas, páginas, elementos CMS, menús y valores de catálogo. | Existen traducciones pero no están conectadas con la experiencia lingüística prevista. | Los usuarios ven contenido en el idioma equivocado o duplicado. | Conserve identidad de traducción y contexto de ruta entre los propietarios pertinentes. | Rutas lingüísticas y contenido asociado son coherentes en recorridos prioritarios. |
| Transferir contenido multimedia conserva referencias incrustadas. | Contenido, multimedia de Products, elementos CMS y aplicaciones pueden referenciar recursos de forma diferente. | Los archivos existen mientras páginas o Products siguen apuntando a rutas antiguas. | Imágenes y descargas rotas reducen la confianza. | Represente las relaciones con adjuntos y enlaces incrustados junto con el registro propietario. | Las rutas representativas muestran los recursos previstos sin dependencias del dominio de origen. |
La señal de control es la continuidad del recorrido del comprador y del contenido, no una coincidencia en el número de páginas o archivos multimedia.
Aplicaciones, Velo, plugins de servicios y sistemas externos
El código Velo, las aplicaciones de Wix, plugins de servicios, webhooks y sistemas externos pueden calcular precios, validar entradas, consultar colecciones CMS, administrar membresías, sincronizar Products, publicar inventario o modificar el procesamiento. Sus registros y lógica no forman automáticamente parte del núcleo de Wix Stores.
| Supuesto sobre la dependencia | Restricción de Wix | Consecuencia para la migración | Impacto operativo | Dirección de mitigación | Señal de control |
|---|---|---|---|---|---|
| Aplicaciones similares tienen registros compatibles. | Cada aplicación define sus propias entidades, permisos, identificadores y ciclo de vida. | Los datos se trasladan a campos genéricos sin un propietario de aplicación operativo. | Desaparecen saldos, programaciones, membresías o historial. | Represente la entidad real del origen mediante la aplicación Wix o propietario externo previsto. | La aplicación que continúa reconoce su Contact, Product u Order padre. |
| El código Velo puede copiarse como datos. | El código depende de APIs de Wix, esquemas CMS, eventos, permisos y secretos. | Los scripts llegan sin dependencias válidas o propiedad definida en el destino. | Las reglas empresariales fallan silenciosamente o generan datos incoherentes. | Recree únicamente el funcionamiento necesario sobre el esquema de destino y APIs compatibles. | El funcionamiento tiene un propietario definido y ninguna dependencia inexplicada del origen. |
| Los IDs externos pueden regenerarse. | ERP, CRM, PIM, WMS, mercados en línea y sistemas contables pueden utilizar claves estables. | La sincronización se vincula con duplicados o registros incorrectos. | Se desalinean operaciones de stock, Customers y Orders. | Conserve identificadores al mismo nivel de entidad utilizado por el sistema autorizado. | Una consulta externa de ida y vuelta resuelve un único registro de Wix previsto. |
| Un campo personalizado reproduce una automatización. | Los campos almacenan valores; automatizaciones y plugins de servicios ejecutan comportamiento. | Los datos permanecen, pero desaparece la regla que los utiliza. | El personal ve valores desactualizados o engañosos. | Asigne por separado propiedad del valor y propiedad del funcionamiento. | El proceso que continúa actualiza e interpreta el campo correctamente. |
| Disponer de una API garantiza equivalencia de modelos. | Las APIs exponen recursos definidos y comportamiento de consistencia, no semántica arbitraria del origen. | El alcance se basa en conectividad y no en propiedad compatible. | Las relaciones ausentes aparecen después de implementar. | Evalúe compatibilidad de entidad y ciclo de vida antes de depender de la API. | Cada integración que continúa tiene un mapa definido de entidades de origen y destino. |
Este dominio afecta a desarrolladores, administradores de aplicaciones y responsables del negocio. La mitigación estructural requiere un mapa de dependencias de aplicaciones con IDs padre estables y propiedad explícita del funcionamiento.
Matriz de propiedad y control de riesgos
| Dominio de riesgo | Propietario principal | Impacto empresarial si no se controla | Dirección de mitigación | Señal de control |
|---|---|---|---|---|
| Linaje del catálogo | Responsable de catálogo e integraciones | Products y variantes duplicados o mal identificados | Definir linaje V1/V3 del origen e identidad universal de variantes. | Cada elemento vendible del origen se resuelve una vez en Catalog V3. |
| Opciones y modificadores | Responsable de catálogo y procesamiento | Variantes falsas o personalización perdida | Clasificar elecciones según su efecto sobre identidad, inventario y datos de Orders. | Las selecciones del comprador producen la variante o modificador previstos. |
| Inventario | Responsable de operaciones de inventario | Ventas por encima del stock y discrepancias entre ubicaciones | Proteger el nivel variante-ubicación y la autoridad externa sobre stock. | Cantidades iniciales y continuas alcanzan el Inventory Item previsto. |
| Contacts y Members | Responsable de operaciones de Customers | Fusiones falsas, errores de acceso e historial roto de aplicaciones | Conservar identidad por capas, acceso, consentimiento y relaciones con aplicaciones. | Identidades de alto valor y ambiguas se resuelven correctamente. |
| Orders | Atención a Customers y finanzas | Historial ilegible o supuestos operativos inseguros | Conservar instantáneas históricas y evidencia relacionada de transacciones/procesamiento. | Los Orders antiguos complejos pueden explicarse de principio a fin. |
| CMS y sitio | Responsable de sitio y contenido | Páginas dinámicas, rutas y referencias rotas | Definir juntos esquema, campos de referencia, páginas, permisos y URLs. | Recorridos dinámicos y estáticos prioritarios se resuelven correctamente. |
| Aplicaciones y Velo | Responsable de aplicaciones o ingeniería | Funcionamiento perdido e integraciones rotas | Reconstruir el comportamiento sobre entidades de destino e IDs estables. | Los flujos que continúan reconocen y actualizan los registros previstos. |
La matriz identifica propietarios de control para que implementación y verificación puedan seguir las relaciones declaradas en lugar de inventar una nueva propiedad durante la ejecución.
Conclusión
Las restricciones de una migración hacia Wix surgen de la interacción entre una plataforma administrada de creación de sitios, Catalog V3, variantes universales, Inventory Items por variante y ubicación, Contacts, Members, Orders, colecciones CMS, aplicaciones, Velo y sistemas externos. Los riesgos más importantes aparecen cuando estos dominios se tratan como una única base de datos o se mezclan supuestos de Catalog V1 y V3.
Una migración controlada protege el linaje de Products, distingue opciones de modificadores, asigna inventario a la variante y ubicación correctas, separa identidad Contact de relaciones Member y de aplicaciones, conserva Orders históricos sin otorgarles autoridad activa y trata el comportamiento de CMS, sitio y aplicaciones como dominios de propiedad explícitos. Estos controles convierten advertencias genéricas en cadenas específicas de causa, impacto y control para Wix.
Preguntas frecuentes
¿Por qué Catalog V1 frente a Catalog V3 representa un riesgo de migración?
Catalog V3 utiliza variantes universales y separa Products, Customizations, Inventory Items, ubicaciones y otros servicios de catálogo de manera más explícita. Reutilizar supuestos o identificadores de V1 sin un mapa de linaje puede crear Products duplicados, inventario ausente o integraciones rotas.
¿Qué riesgo existe al tratar los modificadores de Wix como opciones de Products?
Las opciones crean variantes y afectan SKU, precio e identidad de inventario. Los modificadores recogen información adicional sin crear variantes. Confundirlos puede generar combinaciones de inventario falsas o eliminar la identidad real de la variante adquirida.
¿Por qué un Wix Product puede existir sin comportamiento completo de inventario?
Las relaciones entre Product e Inventory Item pueden crearse por separado, y el stock con seguimiento es específico de variante y ubicación. Un Product visible no demuestra que cada variante con seguimiento tenga el Inventory Item y la asignación de ubicación previstos.
¿Wix Contacts, Members y Customers son la misma entidad?
No. Un Contact proporciona identidad y contexto CRM; un Member añade relaciones de cuenta o acceso; el comercio crea contexto de Customer y Orders; y las aplicaciones Wix pueden poseer registros independientes de participantes o derechos. Deben permanecer conectados sin reducirse a una sola entidad.
¿Los Orders históricos pueden demostrar que el checkout y el procesamiento actuales de Wix están listos?
No. Los Orders históricos conservan artículos adquiridos, detalles de pago, información de envío y estado de procesamiento. Proveedores activos, Order Settings, actualizaciones de inventario, notificaciones, reglas de entrega y servicios de procesamiento siguen siendo configuración actual.
¿Cuándo deben utilizar Wix CMS los datos personalizados del origen en lugar de una aplicación Wix o sistema externo?
Utilice CMS cuando la colección sea realmente propietaria de datos estructurados del sitio y estén definidos su esquema, referencias, permisos, páginas y comportamiento de actualización. Los registros especializados de comercio, membresía, programación o transacciones deben permanecer con la aplicación o sistema externo propietario de su ciclo de vida.