Las migraciones hacia Wix pueden fallar cuando Wix Stores, el CMS, Site Members, las aplicaciones, el contenido multilingüe, la lógica de Velo y las automatizaciones se tratan como una única capa de datos intercambiable. Estos sistemas pueden mostrar información relacionada y, al mismo tiempo, mantener propietarios, permisos y reglas de funcionamiento diferentes.
Para prevenir estos problemas, es necesario identificar quién es responsable de cada registro y cada función, conservar las tablas de apoyo que hacen visibles esos límites y definir una condición de aprobación práctica para cada patrón de fallo. El objetivo debe ser un sitio y una tienda Wix utilizables, no simplemente un panel con datos cargados.
Problema 1: Tratar Wix como un escaparate Hosted genérico
Qué sale mal
La migración se planifica como si Wix fuera únicamente un destino para Products, Customers y Orders. El equipo valida que los registros existan, pero no comprueba cómo funcionan los datos migrados dentro del entorno de comercio y creación de sitios de Wix. Los Products aparecen en el catálogo, mientras que la presentación de páginas, las colecciones, la navegación del sitio, la configuración del proceso de compra, los contactos, los miembros, el contenido del CMS, los medios, las URL y las aplicaciones quedan insuficientemente planificados.
Esto genera una falsa sensación de preparación para el lanzamiento. El sitio de destino puede contener registros migrados, pero los clientes podrían no encontrar Products importantes, seleccionar opciones correctamente, acceder a páginas de contenido relevantes, completar el proceso de compra o seguir las URL antiguas hasta el nuevo sitio Wix.
Señales de alerta temprana
| Señal de alerta | Por qué importa |
|---|---|
| El alcance de la migración solo enumera Products, Customers y Orders. | La estructura del sitio Wix, el contenido, las URL, las aplicaciones y la configuración pueden quedar fuera de la planificación del lanzamiento. |
| La revisión de Products se realiza únicamente en el panel de administración. | La presentación en la tienda y la capacidad de los compradores para encontrar Products todavía pueden fallar. |
| El diseño del sitio, los menús, los dominios y las redirecciones se posponen hasta el final. | Los recorridos del cliente dependen de algo más que los registros migrados. |
| No se inventarían aplicaciones, formularios, miembros, colecciones del CMS o lógica de Velo. | Funciones críticas para el negocio pueden encontrarse fuera de los registros principales de Wix Stores. |
Prevención
Planifique Wix como un destino que combina sitio web y comercio. Revise los registros del catálogo, las páginas de Products, la presentación de colecciones, las rutas de navegación, las páginas del CMS, los Blog Posts, los medios, el significado de Customers y miembros, los Orders históricos, las URL, las redirecciones, los dominios y las dependencias de aplicaciones como áreas operativas relacionadas.
Separe los registros transferidos de las funciones cuya responsabilidad corresponde al comerciante, a la configuración de Wix, a desarrolladores, a proveedores de aplicaciones y a sistemas externos. Esta distinción evita confundir carencias de configuración del destino con defectos de transferencia de registros.
Ejemplo de recomendación
Un comerciante que pasa de Shopify a Wix debería revisar, como un conjunto representativo conectado, un Product sencillo, un Product con muchas variantes, una colección de Products, una página de Product con mucho tráfico, un Blog Post, una página del CMS, un Order de invitado, un Customer recurrente, un registro relacionado con miembros y una redirección prioritaria.
Condición de aprobación
El sitio Wix de destino admite los flujos acordados de venta, contenido, Customers, historial de Orders y operación. Las carencias restantes tienen un responsable explícito: corrección de registros, configuración de Wix, implementación personalizada, trabajo en sistemas externos, reconstrucción manual o exclusión aceptada.
Problema 2: Aplanar Products, opciones, elecciones y variantes
Qué sale mal
El catálogo de origen se migra como un conjunto de Products sencillos de Wix sin preservar el significado de opciones, elecciones, variantes, SKU específicos por variante, precios, existencias, imágenes, peso, personalización o reglas de Products propias del origen. El número de Products puede parecer correcto, pero clientes y personal pierden contexto importante sobre las elecciones de compra.
Este problema es frecuente cuando la tienda anterior usa opciones de Products, Products configurables, opciones personalizadas, paquetes, extras de Products, campos de personalización, configuradores de Products o elecciones gestionadas por aplicaciones. Los Products de Wix pueden admitir opciones, elecciones y variantes, pero el significado del origen sigue necesitando una interpretación cuidadosa.
Señales de alerta temprana
| Señal de alerta | Por qué importa |
|---|---|
| Las opciones de Products no se distinguen de las variantes. | La elección puede mostrarse correctamente mientras el SKU, el precio, las existencias o el detalle del Order resultan incorrectos. |
| No se revisan muestras de inventario específico por variante. | Las existencias pueden parecer correctas solo a nivel del Product principal. |
| Los medios de Products se validan únicamente por cantidad de archivos. | Las imágenes pueden no aparecer en el contexto correcto del Product o de la elección. |
| El funcionamiento de paquetes, personalizaciones u opciones de pago se describe como datos ordinarios de Products. | El requisito puede necesitar implementación personalizada, configuración de aplicaciones, trabajo con Velo/API o reconstrucción manual. |
Prevención
Prepare un conjunto representativo de Products antes del cambio. Incluya Products sencillos, Products con muchas variantes, Products con precios distintos por variante, Products con SKU distintos por variante, variantes sensibles a existencias, Products con muchos medios, Products asignados a colecciones importantes y Products controlados por aplicaciones o lógica personalizada.
Clasifique el funcionamiento complejo de Products del origen antes de aceptar el alcance. Los campos explícitos de Products pueden encajar en una correspondencia directa. La lógica de Products propiedad de aplicaciones, los configuradores personalizados, las transformaciones específicas o el funcionamiento de catálogos externos requieren configuración en Wix, implementación personalizada, responsabilidad de un sistema externo o una exclusión deliberada.
Ejemplo de recomendación
Un Product de origen tiene variantes de color y talla, imágenes específicas por opción, valores de SKU diferentes y cantidades de existencias separadas. La muestra de validación en Wix debe confirmar no solo que el Product existe, sino que cada variante conserva el SKU, precio, imagen, existencias y significado correspondiente en las líneas de Orders.
Condición de aprobación
Los Products representativos de Wix pueden encontrarse, mostrarse, seleccionarse, añadirse al carrito y revisarse en el historial de Orders con el significado esperado de opción, elección, variante, SKU, precio, imagen e inventario.
Problema 3: Confundir las colecciones con toda la navegación del sitio
Qué sale mal
Las Categories, colecciones, menús, filtros, páginas de destino y grupos de merchandising del sistema anterior se tratan como si fueran el mismo objeto. La migración puede crear colecciones de Wix, pero los clientes todavía pueden perder rutas de navegación, lógica de menús, páginas de destino SEO o relaciones con páginas de campaña.
Las colecciones de Wix son importantes para agrupar Products, pero la experiencia completa del sitio también depende de páginas, menús, secciones dinámicas, galerías de Products, enlaces internos, funcionamiento de la búsqueda, redirecciones y diseño de páginas. Migrar colecciones por sí solo no reconstruye el modelo de descubrimiento de la tienda anterior.
Señales de alerta temprana
| Señal de alerta | Por qué importa |
|---|---|
| La migración de Categories se trata como migración de navegación. | Los clientes pueden no llegar a los Products adecuados después del lanzamiento. |
| Las antiguas páginas de destino no se incluyen en la revisión de URL. | Pueden perderse rutas de tráfico de alto valor. |
| Los grupos de Products se validan sin comprobar menús ni enlaces. | Las colecciones de Wix pueden existir y seguir desconectadas del recorrido del cliente. |
| Se supone que las reglas de filtrado o merchandising se transferirán. | El funcionamiento del origen puede requerir configuración en Wix, lógica de aplicaciones o trabajo manual sobre páginas. |
Prevención
Separe los datos de colecciones de las decisiones sobre navegación del sitio. Valide por separado la asignación de Products a colecciones, la presentación de galerías de Products, los enlaces de menús, los enlaces internos, las páginas de destino, las redirecciones, el funcionamiento de la búsqueda y las rutas de alto tráfico como responsabilidades distintas para el lanzamiento en Wix.
Un plan sólido de prevención transforma las funciones antiguas de Categories y colecciones en resultados concretos de Wix: agrupación de Products, entrada de menú, página de destino, destino de redirección, página de contenido, página dinámica del CMS o página retirada.
Ejemplo de recomendación
Una Category de origen llamada “Summer Essentials” podría haber funcionado como grupo de Products, enlace de campaña en la página de inicio, página de destino SEO y destino de campañas por correo electrónico. En Wix puede requerir una colección, una página de destino, una posición en el menú, una redirección y seguimiento analítico después del lanzamiento.
Condición de aprobación
Las rutas importantes para encontrar Products se han reconstruido, redirigido, retirado de forma intencionada o asignado a configuración en Wix. Las colecciones se validan como grupos de Products y la navegación se valida como estructura del sitio orientada al cliente.
Problema 4: Tratar los Orders históricos como prueba de que el proceso de compra está listo
Qué sale mal
La migración de Orders históricos se utiliza como prueba de que el proceso de compra de Wix está preparado. Los Orders migrados pueden conservar Products anteriores, etiquetas de pago, datos de envío, reembolsos, descuentos, impuestos, estado de procesamiento, notas y vínculos con Customers, pero no configuran proveedores de pago futuros, campos del proceso de compra, reglas de envío, impuestos, descuentos, notificaciones, flujos de procesamiento ni ajustes de Orders.
Esto genera un riesgo para el lanzamiento: el personal puede consultar Orders anteriores, mientras que la tienda de destino aún no es capaz de procesar correctamente nuevos Orders.
Señales de alerta temprana
| Señal de alerta | Por qué importa |
|---|---|
| Las muestras de Orders históricos se tratan como pruebas del proceso de compra. | Los datos de compras pasadas no demuestran que el futuro flujo de compra de Wix funcione. |
| Las etiquetas de pago se confunden con la configuración del proveedor de pagos. | La configuración de pago debe realizarse y probarse en Wix. |
| Los valores de envío e impuestos se revisan solo en Orders antiguos. | El cálculo futuro puede seguir incompleto. |
| No se identifican reglas personalizadas del proceso de compra. | Tarifas, validaciones o reglas de envío propias del origen pueden requerir aplicaciones, plugins de servicios, Velo/API o implementación personalizada. |
Prevención
Valide por separado los Orders históricos y el proceso de compra activo. La validación de Orders históricos debe comprobar la identidad del Order, los artículos comprados, totales, descuentos, impuestos, envío, etiquetas de pago, reembolsos, contexto de procesamiento, notas y vínculos con Customers. La validación del proceso de compra activo debe probar el flujo de compra configurado en Wix, pagos, envíos, impuestos, descuentos, procesamiento y notificaciones.
Si la tienda de origen utilizaba lógica personalizada en el proceso de compra, documente si esa función pertenece a configuración de Wix, configuración de aplicaciones, implementación de plugins de servicios, implementación personalizada o exclusión.
Ejemplo de recomendación
Un comerciante tiene Orders antiguos con tarifas de entrega local calculadas mediante zonas de entrega personalizadas. Esos importes históricos pueden migrarse como datos anteriores legibles. El futuro proceso de compra de Wix sigue necesitando una configuración de envío o entrega que reproduzca o sustituya la antigua regla de negocio.
Condición de aprobación
Los datos históricos de Orders son legibles y útiles para atención al cliente, mientras que el futuro proceso de compra de Wix se ha configurado y probado por separado para pagos, envíos, impuestos, descuentos, procesamiento y comunicaciones con clientes.
Problema 5: Interpretar incorrectamente Customers, contactos, miembros y participantes de aplicaciones
Qué sale mal
Las cuentas de clientes del origen se importan sin distinguir entre Customer, contacto, miembro, suscriptor, comprador invitado, usuario de fidelización, participante de reservas, usuario de planes de pago o identidad específica de una aplicación. Wix puede almacenar o exponer estos significados mediante funciones o aplicaciones diferentes, por lo que un registro de contacto migrado no recrea automáticamente acceso a la cuenta, funcionamiento de membresía, participación en fidelización o estado de marketing.
Esto puede crear problemas de atención al cliente y experiencia después del lanzamiento. El personal puede ver un registro sin entender si representa a un comprador, un Site Member, un contacto, un suscriptor o un participante de una aplicación.
Señales de alerta temprana
| Señal de alerta | Por qué importa |
|---|---|
| El número de Customers se utiliza como prueba de continuidad de identidad. | Los recuentos no confirman relaciones con cuentas, miembros, Orders o CRM. |
| No se revisan compradores invitados. | El historial de Orders de invitados puede comportarse de manera diferente al de Customers registrados. |
| Miembros y contactos se tratan como equivalentes. | Las reglas de acceso y el contexto de CRM pueden requerir tratamiento diferente en Wix. |
| Se supone que fidelización, suscripciones, reservas o planes de pago se migrarán automáticamente. | Los datos propiedad de aplicaciones suelen necesitar revisión o configuración independiente. |
Prevención
Defina las categorías de identidad antes de la migración. Distinga Customers, compradores invitados, contactos, miembros, suscriptores, participantes de formularios, participantes de reservas, usuarios de fidelización, miembros de planes de pago, registros mayoristas e identificadores de CRM externos. Después, asigne cada categoría a correspondencia de registros principales, configuración de Wix, importación mediante aplicación, implementación personalizada, trabajo en sistemas externos, reconstrucción manual o exclusión.
La validación debe incluir compradores recurrentes, compradores invitados, Customers con varias direcciones, miembros con requisitos de acceso, Customers vinculados con Orders y ejemplos de identidades específicas de aplicaciones.
Ejemplo de recomendación
Una tienda de origen contiene Customers, suscriptores del boletín, compradores mayoristas, miembros de pago y usuarios de fidelización. El alcance de Wix no debe tratar todos esos registros como una única entidad de cliente. Cada tipo de identidad debe tener su propia expectativa en el destino y su propia muestra de validación.
Condición de aprobación
Las relaciones migradas entre Customers, contactos, miembros e historial de Orders en Wix coinciden con el alcance acordado. Las funciones de identidad, acceso o CRM específicas de aplicaciones se han implementado, revisado por separado o documentado como excluidas.
Problema 6: Olvidar páginas del CMS, Blog Posts, medios, URL y continuidad SEO
Qué sale mal
La migración conserva Products pero debilita la experiencia del sitio Wix. Las páginas del CMS, los Blog Posts, las páginas dinámicas, los medios, las imágenes de Products, las páginas de colecciones, las páginas de destino, los menús, enlaces internos, redirecciones, títulos de página, meta descripciones, texto alternativo, requisitos de canonical, dominios, rutas multilingües y diseño móvil pueden no trasladarse como se espera si no forman parte del alcance y del plan de validación.
Este problema es especialmente importante para tiendas que dependen de búsqueda orgánica, guías de compra extensas, venta basada en contenido, páginas de destino de campañas o tráfico generado por el blog.
Señales de alerta temprana
| Señal de alerta | Por qué importa |
|---|---|
| El SEO se revisa únicamente a nivel de Products. | Pueden quedar riesgos en páginas, blog, colecciones, redirecciones y enlaces internos. |
| La transferencia de medios se considera equivalente a que la página esté lista. | Los archivos de imagen pueden existir sin la ubicación, contexto alternativo o diseño correctos. |
| Las redirecciones y los pasos de dominio se posponen hasta el día del lanzamiento. | El tráfico de búsqueda, marcadores, analítica y enlaces de campañas pueden romperse. |
| No se revisan muestras de Blog Posts o páginas del CMS. | La pérdida de contenido puede aparecer únicamente después del lanzamiento. |
Prevención
Cree una lista de validación de contenido y SEO. Incluya páginas prioritarias de Products, páginas de colecciones, páginas del CMS, Blog Posts, páginas con muchos medios, enlaces internos, rutas de menú, URL de alto valor, redirecciones, títulos de página, meta descripciones, contexto del texto alternativo, requisitos de canonical, pasos de dominio y tareas de presentación móvil.
Separe el contenido transferido del trabajo de diseño en Wix. La reconstrucción del diseño de páginas, la adaptación móvil, la estrategia de menús, el rediseño visual y el trabajo con dominios siguen siendo responsabilidades del lado de Wix o tareas de implementación personalizada.
Ejemplo de recomendación
Un comerciante tiene guías de compra, tutoriales en el blog y páginas de Categories de Products con buen posicionamiento. El plan de prevención en Wix debe incluir correspondencia de URL prioritarias, revisión de muestras de contenido, validación de Blog Posts, revisión de enlaces internos, planificación de redirecciones, comprobaciones de medios y revisión móvil antes del lanzamiento.
Condición de aprobación
Los Products, páginas, Blog Posts, medios, menús, redirecciones, metadatos y enlaces internos prioritarios se han validado en Wix. Las tareas de diseño, presentación, dominio, analítica y SEO que quedan fuera del alcance de la migración están asignadas antes del lanzamiento.
Problema 7: Suponer que aplicaciones, lógica de Velo, plugins de servicios y sistemas externos son datos estándar
Qué sale mal
Las aplicaciones, la lógica de Velo/API, colecciones del CMS, catálogos personalizados, plugins de servicios, reglas personalizadas del proceso de compra, cargos personalizados, integraciones de tarifas de envío, servicios de pago externos, conexiones con ERP/CRM/PIM/WMS/contabilidad o referencias de mercados en línea se tratan como campos ordinarios del catálogo, Customers u Orders. La tienda de destino puede superar comprobaciones básicas de migración y, aun así, fallar en flujos críticos para el negocio.
La capacidad de extensión de Wix no convierte cualquier función en datos transferibles de forma ordinaria. Algunas funciones pertenecen a configuración de aplicaciones Wix, permisos del CMS, código Velo, automatizaciones, integraciones externas, reconstrucción manual o exclusión deliberada.
Señales de alerta temprana
| Señal de alerta | Por qué importa |
|---|---|
| Los registros propiedad de aplicaciones no se enumeran por separado. | Datos importantes pueden no pertenecer al alcance principal de migración de Wix Stores. |
| El funcionamiento de Velo/API se describe sin ejemplos. | El funcionamiento controlado por código no puede validarse como registros ordinarios. |
| El funcionamiento de plugins de servicios se deduce a partir de datos históricos. | El proceso de compra, envío, pago y procesamiento puede necesitar implementación. |
| Los sistemas externos se prueban únicamente después del lanzamiento. | Los flujos operativos pueden fallar cuando el tráfico pase a Wix. |
Prevención
Inventaríe todas las dependencias personalizadas y externas antes de la migración. Para cada aplicación, campo personalizado, colección del CMS, script, función de plugin de servicios y sistema externo, identifique responsable, finalidad de negocio, muestra del origen, resultado esperado en Wix, forma de tratamiento y prueba de validación.
Utilice correspondencia de campos compatible solo para relaciones explícitas entre registros. Los registros propiedad de aplicaciones, el funcionamiento de Velo/API, identificadores externos, transformaciones específicas y dependencias de sistemas externos necesitan una aplicación de destino, implementación personalizada, un responsable de integración o una exclusión deliberada.
Ejemplo de recomendación
Una tienda de origen utiliza un configurador de Products, una aplicación de fidelización y sincronización con un ERP. Los registros de Products de Wix pueden migrarse, pero el funcionamiento del configurador, los saldos de fidelización y la sincronización con el ERP necesitan tratamiento independiente. Pueden requerir configuración de aplicaciones Wix, trabajo con Velo/API, implementación en el sistema externo, reconstrucción manual o exclusión aceptada.
Condición de aprobación
Todas las dependencias de aplicaciones, Velo/API, colecciones del CMS, sistemas externos y datos personalizados tienen un responsable declarado y un resultado de destino utilizable distinto de los registros principales de Wix Stores.
Problema 8: Tratar las colecciones de Wix CMS como datos del catálogo de Wix Stores
Qué sale mal
Las colecciones personalizadas del CMS y las colecciones de aplicaciones Wix se tratan como almacenes intercambiables de datos de Products. Un equipo puede ver Products, inventario, Orders o miembros expuestos mediante vistas del CMS y suponer que esas colecciones pueden importarse, editarse o recibir permisos como colecciones personalizadas ordinarias. El destino termina entonces con datos duplicados, registros de solo lectura, páginas dinámicas desconectadas o formularios que escriben en la colección equivocada.
Wix Stores y otras aplicaciones son responsables de sus colecciones de aplicación. Las colecciones personalizadas del CMS pueden admitir modelos de contenido separados, pero no se convierten automáticamente en el catálogo operativo de Wix Stores.
Señales de alerta temprana
| Señal de alerta | Por qué importa |
|---|---|
| Se propone una colección personalizada como destino de Products importados de la tienda. | La presentación de Products puede reconstruirse sin el funcionamiento comercial de Wix Stores. |
| Las colecciones de aplicaciones Wix se tratan como tablas personalizadas editables. | Los registros propiedad de aplicaciones pueden ser de solo lectura o estar sujetos a permisos fijos. |
| Las páginas dinámicas muestran contenido parecido a Products desde una colección personalizada. | La página puede parecer correcta aunque falten relaciones con carrito, inventario y Orders. |
| Formularios o código Velo escriben directamente en una colección sin decidir quién debe ser responsable de los datos. | Los datos pueden omitir la aplicación que debería gobernarlos. |
Prevención
Asigne cada colección a un propietario y una finalidad. Las colecciones de aplicaciones de Wix Stores deben seguir gobernadas a través de Wix Stores. Las colecciones personalizadas del CMS solo deben utilizarse cuando representen un modelo de contenido separado con campos, permisos, páginas dinámicas y lógica de integración definidos de forma deliberada. No duplique datos operativos de Products salvo que esa copia tenga un responsable de sincronización y una finalidad de negocio claramente definidos.
| Tipo de colección | Uso apropiado | Control principal |
|---|---|---|
| Colección de aplicación de Wix Stores | Mostrar o consultar datos comerciales propiedad de la aplicación. | Gestionar los datos operativos mediante Wix Stores. |
| Colección personalizada del CMS | Contenido estructurado, directorios, recursos o flujos personalizados. | Definir campos, permisos, páginas dinámicas y responsabilidad de los datos. |
| Colección privada para miembros | Registros o envíos específicos de miembros. | Preservar reglas de rol y acceso por elemento. |
| Réplica de un sistema externo | Elaboración de informes o uso de integración. | Definir sincronización, identificadores y tratamiento de conflictos. |
Ejemplo de recomendación
Una tienda de origen tiene una guía comparativa personalizada vinculada a Products. Importe los Products a Wix Stores y los registros de la guía a una colección personalizada del CMS. Relaciónelos mediante identificadores estables o referencias deliberadas; no reconstruya el catálogo de Products dentro de la colección de la guía únicamente porque ambos aparecen en páginas dinámicas.
Condición de aprobación
Cada colección tiene un propietario, finalidad, modelo de permisos y ruta de actualización declarados. Los Products operativos siguen gobernados por Wix Stores, mientras que el contenido personalizado del CMS admite únicamente la función independiente para la que fue diseñado.
Problema 9: Aplanar el contenido multilingüe y las relaciones entre URL
Qué sale mal
Los idiomas se migran como valores de texto duplicados sin conservar la relación entre contenido principal, contenido traducido, campos SEO específicos por idioma y URL localizadas. Las traducciones de Products, nombres de Categories, textos del proceso de compra, contenido del CMS y redirecciones pueden quedar incompletos o llevar al visitante a una versión lingüística incorrecta.
Una única lista de redirecciones es especialmente arriesgada cuando las rutas antiguas difieren por idioma o cuando el destino utiliza una estructura de URL multilingüe distinta.
Señales de alerta temprana
| Señal de alerta | Por qué importa |
|---|---|
| Las traducciones se almacenan sin relación con un registro principal. | Las actualizaciones pueden generar versiones lingüísticas incoherentes o huérfanas. |
| Las traducciones de Products y Categories se revisan por separado de los textos del proceso de compra y del correo electrónico. | El recorrido de compra puede cambiar de idioma inesperadamente. |
| Las redirecciones se preparan sin columna de idioma ni revisión del destino. | Los visitantes pueden terminar en la página del idioma predeterminado o en una ruta rota. |
| Se espera que las URL de páginas dinámicas del CMS se traduzcan exactamente igual que las páginas ordinarias. | El funcionamiento de las URL puede variar según el tipo de contenido. |
Prevención
Cree un mapa de relaciones lingüísticas que abarque Products, Categories, contenido del CMS, Blog Posts, menús, textos del proceso de compra, textos de correo electrónico, campos SEO y redirecciones. Defina idioma principal, responsabilidad de traducción, comportamiento alternativo y estructura de URL del destino. Revise las redirecciones dentro del contexto lingüístico correcto en lugar de tratarlas como una lista indiferenciada para todo el sitio.
| Componente multilingüe | Decisión de prevención |
|---|---|
| Texto de Products y Categories | Preservar la relación con el registro comercial principal. |
| Contenido del CMS y Blog | Relacionar campos traducidos con las páginas que los muestran. |
| URL y redirecciones | Asignar rutas antiguas y nuevas por idioma y relevancia del destino. |
| Proceso de compra y comunicaciones | Configurar etiquetas, correos electrónicos y mensajes operativos traducidos. |
Ejemplo de recomendación
Una tienda tiene páginas de Products en inglés y francés con rutas heredadas diferentes. Relacione ambas versiones lingüísticas con la misma identidad de Product de Wix Stores, cree después redirecciones apropiadas para cada idioma y confirme que la navegación, el texto de Products, las etiquetas del proceso de compra y el contenido del correo electrónico en francés permanecen en francés.
Condición de aprobación
Los recorridos representativos por idioma son coherentes desde la página de entrada hasta el descubrimiento de Products y el proceso de compra. Las traducciones permanecen vinculadas a los registros correctos y las URL heredadas prioritarias resuelven hacia destinos relevantes en el idioma previsto.
Problema 10: Suponer que Wix Automations y las notificaciones acompañan a los registros migrados
Qué sale mal
Products, contactos, miembros, Orders, formularios o registros del CMS aparecen en Wix y el equipo supone que las automatizaciones relacionadas empezarán a funcionar automáticamente. En realidad, Wix Automations depende de activadores, acciones, condiciones, tiempos, aplicaciones instaladas y, en algunos casos, código Velo o conexiones webhook configurados. Los datos históricos no recrean esas definiciones de flujo.
El resultado puede ser un fallo operativo silencioso: los Customers no reciben confirmaciones, no se crean tareas para el personal, los posibles clientes no se asignan o los sistemas externos dejan de recibir eventos.
Señales de alerta temprana
| Señal de alerta | Por qué importa |
|---|---|
| El origen tiene flujos de carrito abandonado, Orders, formularios, membresías o clientes potenciales sin inventario equivalente en el destino. | Pueden faltar activadores y acciones importantes. |
| Las notificaciones se deducen a partir de correos históricos o notas de Orders. | El resultado pasado no revela la definición completa del flujo. |
| Las aplicaciones se instalan después de planificar las automatizaciones. | El conjunto de activadores y acciones disponibles puede cambiar según las aplicaciones instaladas. |
| Webhooks o acciones de Velo no tienen responsable ni revisión de registros de ejecución. | Los procesos externos pueden fallar sin errores visibles en la tienda. |
Prevención
Inventaríe cada automatización crítica para el negocio por activador, condiciones, acciones, tiempos, audiencia, dependencia de aplicaciones, campos de datos y endpoint externo. Reconstruya únicamente los flujos que sigan respondiendo a una necesidad actual del negocio. Después de la configuración, utilice eventos activos representativos para confirmar que el activador se ejecuta, las condiciones dirigen correctamente el flujo, las acciones se completan y los sistemas externos reciben los datos esperados.
| Tipo de flujo | Control necesario |
|---|---|
| Automatización de Orders o carrito | Confirmar activador de Wix Stores, datos de Customers, mensaje, momento de ejecución y tratamiento de excepciones. |
| Automatización de formularios o clientes potenciales | Confirmar origen del formulario, correspondencia de campos, asignación y acción de seguimiento. |
| Automatización de miembros | Confirmar rol, evento de acceso, notificación y estado de membresía. |
| Flujo mediante webhook o Velo | Confirmar endpoint, contenido enviado, autenticación, tratamiento de errores y registro de ejecución. |
Ejemplo de recomendación
Una tienda de origen envía un correo al personal cuando se realiza un Order de alto valor y transmite los datos del Order a un ERP. Reconstruya la notificación al personal y la transferencia externa como flujos independientes en Wix; después, genere un Order representativo y confirme tanto la acción interna como los datos enviados al sistema externo.
Condición de aprobación
Cada automatización crítica para el negocio tiene un activador activo, condiciones correctas, acciones completas, un responsable y pruebas satisfactorias obtenidas mediante un evento representativo. Los registros migrados no se consideran prueba de que el flujo exista.
Prioridades de prevención comunes a varios problemas
| Área de control | Prioridad de prevención | Evidencia de control |
|---|---|---|
| Catálogo de Wix Stores | Preservar relaciones de Products, opciones, variantes, medios, inventario y Categories. | Los Products representativos siguen siendo seleccionables, comprables y comprensibles para la operación. |
| Descubrimiento en el sitio | Conectar intencionadamente Categories, menús, páginas, Blog Posts, contenido del CMS y páginas dinámicas. | Los clientes pueden pasar del contenido y la navegación a los Products previstos. |
| Identidad | Separar Customers, contactos, Site Members y participantes de aplicaciones según su función. | Cada tipo de identidad conserva el contexto de cuenta, acceso o comunicación que necesita. |
| Colecciones | Distinguir colecciones de aplicaciones Wix de colecciones personalizadas del CMS y sus permisos. | Cada colección tiene un propietario y una ruta de actualización declarados. |
| Estructura multilingüe | Preservar contenido traducido, campos SEO, URL y redirecciones como recorridos lingüísticos relacionados. | Los recorridos prioritarios permanecen coherentes en cada idioma compatible. |
| Funciones personalizadas | Inventariar aplicaciones, Velo, plugins de servicios, sistemas externos y campos personalizados. | Cada dependencia tiene una implementación de destino o una exclusión deliberada. |
| Automatizaciones | Reconstruir activadores, condiciones, acciones e integraciones por separado de los registros. | Los eventos representativos ejecutan el flujo interno y externo previsto. |
Conclusión
Los problemas de migración hacia Wix pueden prevenirse cuando Wix Stores, las colecciones del CMS, Site Members, el contenido, el enrutamiento multilingüe, las aplicaciones, la lógica de Velo y las automatizaciones se tratan como sistemas conectados pero con responsabilidades independientes. Un panel con datos cargados no es suficiente si la colección equivocada gobierna los datos, las traducciones pierden sus relaciones o dejan de existir los activadores de los flujos.
Una migración sólida preserva la profundidad específica de la plataforma y ofrece una lectura centrada en las decisiones. El texto explica causas y consecuencias; las tablas de apoyo aclaran señales de alerta, límites de responsabilidad y decisiones preventivas; y las condiciones de aprobación demuestran que el funcionamiento del destino es utilizable.
Preguntas frecuentes
¿Por qué Wix es más que un destino Hosted genérico para una tienda?
Wix combina Wix Stores con páginas, contenido del Blog, colecciones del CMS, Site Members, aplicaciones, funciones multilingües, código Velo y automatizaciones. Estos componentes pueden hacer referencia al mismo Customer o Product y, al mismo tiempo, mantener responsabilidades y permisos diferentes.
¿Cuál es el principal problema de estructura de Products en Wix Stores?
Las opciones y variantes del origen pueden no representarse directamente mediante las relaciones entre Product, opción, elección, variante, medios, precio e inventario de Wix. Revise los Products complejos según su funcionamiento real durante la compra, no solo por cantidad de Products.
¿Las colecciones de Wix CMS son iguales que las colecciones de Wix Stores?
No. Las colecciones de aplicaciones Wix exponen datos propiedad de la aplicación y están gobernadas por la aplicación correspondiente. Las colecciones personalizadas del CMS tienen sus propios campos, permisos y usos en páginas dinámicas; no se convierten automáticamente en un catálogo operativo de la tienda.
¿Cómo deben diferenciarse Customers, contactos y Site Members?
Clasifique cada identidad por la función que debe admitir: historial comercial, comunicación de marketing, inicio de sesión en el sitio, contenido restringido, fidelización, reservas u otra relación específica de una aplicación. Preserve únicamente los significados que tengan un responsable en el destino.
¿Qué hace arriesgada una migración multilingüe hacia Wix?
Las traducciones, textos de Products, contenido del CMS, campos SEO, idioma del proceso de compra y redirecciones deben permanecer vinculados a los registros principales correctos y a las rutas específicas de cada idioma. Una única lista genérica de traducciones o redirecciones no es suficiente.
¿Las Wix Automations se reanudan cuando se migran los registros?
No. Las automatizaciones necesitan activadores, condiciones, acciones, tiempos, dependencias de aplicaciones y, en algunos casos, código Velo o webhooks configurados. Reconstrúyalas y active eventos representativos para demostrar que los flujos funcionan.