Las migraciones a Gambio suelen fallar cuando se confunde un recuento completo de registros con la conservación del comportamiento comercial. La plataforma puede combinar relaciones de catálogo, reglas de Customer Groups, contenido multilingüe, Orders, integraciones y responsabilidades operativas gestionadas o autohospedadas. Cada problema que se presenta a continuación aísla un patrón de fallo recurrente y define la evidencia necesaria para demostrar que está bajo control.
Problema 1: Elegir el modelo operativo sin asumir sus consecuencias
Qué sale mal
Gambio Cloud y una instalación Gambio autohospedada pueden representar el mismo catálogo y, al mismo tiempo, asignar responsabilidades muy distintas sobre hosting, actualizaciones, acceso al código, extensiones e integraciones personalizadas. Una migración puede conservar Products y Orders y aun así fallar operativamente si el comercio espera flexibilidad de autohospedaje en un entorno gestionado o, a la inversa, espera mantenimiento gestionado mientras conserva código personalizado y dependencias de servidor.
Señales de alerta
El destino se describe únicamente como “Gambio” sin especificar su modelo operativo. Las tareas cron existentes, personalizaciones a nivel de archivo, scripts de servidor o procesos directos sobre base de datos no tienen responsable futuro. O bien el destino es autohospedado, pero nadie se responsabiliza de actualizaciones, copias de seguridad, supervisión y compatibilidad de extensiones.
| Señal | Supuesto oculto probable | Consecuencia para el negocio |
|---|---|---|
| PHP personalizado o tareas de servidor deben continuar | El destino necesita control sobre código e infraestructura | Un entorno gestionado puede no reproducir esa dependencia |
| No hay responsable técnico asignado | Se asume que hosting y mantenimiento están incluidos | Las operaciones autohospedadas pueden quedar sin gestión |
| La elección del destino se basa solo en compatibilidad de registros | Se excluyó la responsabilidad operativa | La tienda puede llenarse de datos, pero no operar de forma sostenible |
Prevención
Registre el modelo operativo del destino antes de decidir cómo continuará el comportamiento personalizado. Separe los registros migrados del hosting, mantenimiento, actualizaciones, instalación de extensiones, acceso a archivos, tareas programadas e integraciones externas. Para Gambio autohospedado, asigne responsables de infraestructura y actualizaciones. Para Gambio Cloud, identifique cada requisito que dependa de acceso directo al código, servidor o base de datos y decida si existe una alternativa compatible.
Ejemplo de recomendación
Un comercio utiliza un script nocturno de servidor para enriquecer datos de Product antes de publicarlos. La migración conserva los campos de Product, pero el script se trata como una dependencia operativa independiente. El equipo lo reasigna a una integración compatible o elige un entorno donde pueda mantenerse deliberadamente.
Condición de aprobación
El modelo operativo del destino está definido, cada dependencia de infraestructura o código tiene un responsable y ningún proceso crítico depende de un acceso o una responsabilidad de mantenimiento que el entorno seleccionado no proporciona.
Problema 2: Aplanar propiedades, opciones y diferencias entre Products vendibles
Qué sale mal
Los registros de Product en Gambio pueden contener datos descriptivos ordinarios junto con relaciones de opciones o propiedades que cambian lo que el comprador selecciona y lo que el negocio procesa. Tratar cada opción del origen como un atributo de texto puede conservar etiquetas y perder identidad de combinaciones, efectos sobre precio, comportamiento de stock, imágenes, peso, tiempo de envío o el modelo de Product utilizado por sistemas conectados.
Señales de alerta
Los Products sencillos parecen correctos, pero aquellos con varias dimensiones de selección generan opciones duplicadas, combinaciones imposibles, un único valor de stock compartido o líneas de Order que no identifican la variación comprada. Los SKU o identificadores externos del origen existen a un nivel más granular que el Product migrado.
| Patrón observado | Significado en riesgo | Fallo habitual |
|---|---|---|
| La elección cambia SKU o stock | Identidad de combinación vendible | Se procesa el artículo equivocado |
| La elección solo cambia la presentación | Opción de visualización o valor descriptivo | Se crean Products duplicados innecesarios |
| La combinación de propiedades tiene precio o imagen propios | Datos comerciales específicos de la combinación | El precio o la imagen del carrito no coincide con la selección |
Prevención
Clasifique los valores del origen por función: información descriptiva, selección del comprador, combinación vendible, personalización introducida por el comprador o clave de sistema externo. Conserve las relaciones entre registro principal y combinación y todos sus efectos comerciales. No deduzca la identidad de la combinación solo por las etiquetas cuando exista un SKU, número de modelo o identificador de origen estable.
Ejemplo de recomendación
Un cable configurable utiliza longitud y tipo de conector. Cada combinación válida tiene número de modelo, cantidad de stock y precio propios. Mantenga un único Product principal para merchandising, pero conserve el conjunto de combinaciones válidas y sus identificadores operativos, en lugar de convertirlas en elecciones libres desconectadas del inventario.
Condición de aprobación
Cada Product complejo representativo muestra únicamente elecciones válidas, añade al carrito el precio y la identidad de artículo correctos, conserva el responsable de stock adecuado y sigue siendo trazable mediante el identificador utilizado por los sistemas de procesamiento de pedidos o inventario.
Problema 3: Conservar Categories pero romper el descubrimiento de Products
Qué sale mal
Un árbol de Categories puede estar numéricamente completo y, aun así, debilitar el descubrimiento por parte del comprador. Los Products pueden pertenecer a varias Categories, ramas profundas pueden tener significado de navegación y el contenido o las URL de Category pueden contribuir al merchandising y a la visibilidad en buscadores. Aplanar la jerarquía, conservar una sola asignación o recrear nombres sin contexto de ruta puede dificultar encontrar los Products.
Señales de alerta
Los recuentos de Categories coinciden, pero Products representativos desaparecen de rutas de navegación esperadas. Los breadcrumbs cambian sin intención, aparecen Categories duplicadas, ramas profundas quedan vacías o rutas de Category de alto valor no tienen un destino claro.
| Comprobación | Patrón de fallo | Por qué importa |
|---|---|---|
| Estructura padre-hijo | Los niveles se aplanan o duplican | Cambia la intención de navegación |
| Asignaciones de Product | Solo se conserva una Category | Desaparecen rutas de cross-merchandising |
| Ruta y contenido de Category | Existe el nombre sin un destino equivalente | Se debilitan SEO y rutas de entrada del comprador |
Prevención
Mapee la jerarquía y las asignaciones de Product por separado. Identifique relaciones de Category principales y adicionales, nombres localizados, descripciones, imágenes y rutas prioritarias. Retire ramas obsoletas únicamente con un destino explícito. Utilice Products representativos de niveles superiores, intermedios y más profundos para comprobar que los recorridos de navegación previstos siguen siendo posibles.
Ejemplo de recomendación
Un Product pertenece a “Outdoor”, “Camping” y una Category de promoción estacional. Conserve la identidad estable del Product y todas las asignaciones previstas, mientras define qué ruta será la principal para breadcrumbs y qué ruta estacional debe seguir activa o redirigirse.
Condición de aprobación
Los Products representativos son accesibles por todas las rutas de Category previstas, jerarquía y breadcrumbs son coherentes, las rutas retiradas tienen destinos deliberados y ningún Product queda expuesto u oculto porque una asignación se haya eliminado silenciosamente.
Problema 4: Copiar Customer Groups sin sus permisos y precios
Qué sale mal
Gambio puede asociar acceso a Products, precios u otro tratamiento comercial con Customer Groups. Migrar Customers y nombres de grupos sin conservar las relaciones controladas crea cuentas aparentemente clasificadas que reciben visibilidad o precios predeterminados. El fallo es especialmente grave en poblaciones mayoristas, restringidas o con condiciones negociadas.
Señales de alerta
Customer Groups existe en administración, pero Products muestra el mismo precio y disponibilidad a todos los compradores. Campos de permisos de grupo, reglas de descuento o identificadores externos de Customers faltan o se reducen a notas.
| Relación | Señal de alerta | Efecto potencial |
|---|---|---|
| Customer con grupo | La pertenencia queda como una etiqueta | El tratamiento de la cuenta vuelve al predeterminado |
| Grupo con visibilidad de Product | Products restringidos aparecen de forma general | Fallan los límites del catálogo privado |
| Grupo con precio o descuento | Todos los grupos reciben el mismo resultado | Se pierden acuerdos comerciales |
Prevención
Documente el resultado que controla cada grupo, no solo su nombre. Conserve la pertenencia del Customer por separado de permisos de Product, relaciones de precio y configuración del destino. Consolide grupos obsoletos deliberadamente y conserve los identificadores externos que necesiten ERP, CRM o procesos de gestión de cuentas.
Ejemplo de recomendación
Un grupo de distribuidores puede comprar Products seleccionados a precios negociados. Conserve la pertenencia al grupo, la relación de acceso a Product y el responsable de precios. No apruebe el resultado solo porque el perfil del Customer siga mostrando “Dealer”.
Condición de aprobación
Customers representativos entran en el contexto de grupo previsto, ven únicamente los Products y condiciones comerciales correctos y conservan los identificadores que requieren los sistemas de cuentas conectados sin obtener acceso indebido.
Problema 5: Reducir Orders a totales y nombres de estado
Qué sale mal
La cabecera de un Order puede sobrevivir mientras se pierde su significado histórico. Los atributos de línea de Product, descuentos, impuestos, envío, referencias de pago, códigos de seguimiento, comentarios e historial de estados explican qué se compró y qué ocurrió después. Copiar solo totales y un estado visualmente parecido deja a soporte y finanzas sin capacidad para reconstruir la transacción.
Señales de alerta
Los recuentos de Orders y los totales generales parecen plausibles, pero el personal no puede identificar la propiedad de Product seleccionada, explicar un descuento, seguir referencias de envío o distinguir el contexto de cancelación, devolución y reembolso.
| Elemento del Order | Patrón de pérdida | Impacto operativo |
|---|---|---|
| Atributos de artículo | Falta la elección comprada | Las decisiones de sustitución y soporte dejan de ser fiables |
| Componentes del total | Descuento, impuesto o envío se aplana | La conciliación deja de explicar el total general |
| Historial y seguimiento | Solo sobrevive el estado actual | El personal no puede reconstruir la cronología de la transacción |
Prevención
Conserve cabeceras de Order, líneas, atributos seleccionados, componentes de total, direcciones, fechas, referencias del origen, notas de historial y relaciones de seguimiento cuando el destino pueda representarlos. Cuando un proceso del origen no tenga equivalente, mantenga contexto histórico legible en lugar de inventar un estado activo del proceso en el destino.
Ejemplo de recomendación
Un Order devuelto incluye dos opciones de Product, un cupón, impuesto de envío y código de seguimiento. El historial migrado conserva esos componentes y deja legible el contexto de la devolución, mientras que el comportamiento activo de reembolso sigue siendo un proceso del destino en lugar de deducirse de la antigua etiqueta de estado.
Condición de aprobación
El personal puede abrir Orders ordinarios y excepcionales representativos, identificar exactamente qué se compró, reconciliar el total mostrado, entender el estado histórico y seguir las referencias conservadas sin volver a la tienda de origen.
Problema 6: Tratar URL multilingües y metadatos como texto decorativo
Qué sale mal
Las descripciones de Product y Category, palabras clave de URL, metadatos, texto alternativo de imágenes e información del proceso de compra pueden variar por idioma. Elegir un único idioma como fuente universal o copiar texto traducido sin relaciones de rutas puede sobrescribir significado específico de cada mercado, crear rutas duplicadas o dejar enlaces internos apuntando a URL obsoletas.
Señales de alerta
Un idioma está completo mientras otro contiene valores alternativos, metadatos mezclados, slugs ausentes o enlaces internos rotos. Las rutas de Product y Category de alto valor no tienen un mapa de destino específico por idioma.
| Capa de contenido | Patrón de fallo | Efecto para el Customer |
|---|---|---|
| Nombres y descripciones | Un idioma sobrescribe a otro | Las páginas localizadas quedan incompletas |
| Palabras clave de URL y metadatos | Las rutas se regeneran sin asignación | Se rompen accesos orgánicos y favoritos |
| Enlaces internos y texto de imágenes | Enlaces o alt text conservan rutas/idioma del origen | El contenido queda incoherente o inaccesible |
Prevención
Inventaríe los idiomas activos y clasifique cada campo traducible. Asigne las rutas específicas por idioma de Product, Category y contenido a los destinos previstos. Conserve identificadores estables de contenido cuando existan y cree relaciones de redirección para rutas prioritarias en lugar de depender de una generación automática de slugs.
Ejemplo de recomendación
Una página de Product en alemán y su equivalente en inglés utilizan slugs y metadatos distintos. Conserve ambos registros de idioma, asigne cada ruta por separado y actualice enlaces internos para que la página inglesa no apunte a la ruta alemana retirada del origen.
Condición de aprobación
Cada idioma activo tiene contenido completo de Product y Category, metadatos coherentes, enlaces internos funcionales y un destino definido para cada URL prioritaria del origen, sin sobrescrituras entre idiomas.
Problema 7: Mover CMS y contenido del proceso de compra sin su contexto en la tienda pública
Qué sale mal
CMS Pages, información de Product para el proceso de compra, contenido de confianza e información legal o de servicio pueden existir como registros y, aun así, faltar en los lugares donde el comprador los necesita. Las posiciones del tema, menús, enlaces de footer, plantillas de Product y superficies del proceso de compra son independientes del propio contenido.
Señales de alerta
Las páginas existen en administración, pero no se puede acceder a ellas desde la navegación. Falta información específica del proceso de compra en el Product correspondiente o el contenido de políticas aparece en una ruta genérica sin su ubicación esperada.
| Tipo de contenido | Pregunta independiente de propiedad | Fallo si se ignora |
|---|---|---|
| CMS Page | ¿Qué menú, footer o ruta la expone? | La página existe, pero no es accesible |
| Información de Product para el proceso de compra | ¿Qué Products y qué paso de compra la utilizan? | Desaparecen instrucciones importantes |
| Contenido de confianza o políticas | ¿Qué ubicación de la tienda pública lo presenta? | Customers no encuentran información necesaria |
Prevención
Trate registro de contenido, asignación, ruta y presentación como relaciones independientes. Conserve el contenido y su propiedad de Product o navegación y después reconstruya deliberadamente su ubicación en el destino. Revise enlaces internos y referencias multimedia dentro del mismo recorrido de contenido.
Ejemplo de recomendación
Una familia de Products incluye instrucciones de compra para medidas personalizadas. Conserve el contenido de las instrucciones y su relación con Product y confirme después que aparece en el paso de compra previsto en lugar de convertirse en una CMS Page sin enlaces.
Condición de aprobación
El contenido prioritario es exacto, accesible por la ruta prevista de la tienda pública, está vinculado a los Products o áreas de navegación correctos y no depende de enlaces exclusivos del origen ni de dependencias de presentación no resueltas.
Problema 8: Conservar Products descargables sin preservar el significado del procesamiento digital
Qué sale mal
Un Product descargable es más que una referencia a un archivo. El derecho de acceso, estado del Order, disponibilidad de descarga, caducidad, número de descargas, acceso del Customer y seguridad del archivo pueden determinar si la compra es utilizable. Copiar únicamente Product y nombre de archivo puede exponer archivos antes de tiempo o impedir el acceso a compras legítimas.
Señales de alerta
Los Products descargables aparecen en el catálogo, pero Customers históricos no tienen contexto de acceso, las rutas de archivos apuntan al almacenamiento del origen o todos los estados de Order conceden el mismo derecho de acceso.
| Componente digital | Riesgo si se aplana | Resultado |
|---|---|---|
| Relación con archivo | La ruta del origen se copia como texto | El recurso no puede entregarse |
| Regla de derecho de acceso | Se pierden estado de Order y propiedad del Customer | El acceso se concede o deniega incorrectamente |
| Caducidad o número de descargas | Desaparecen valores de control | La política del Product digital cambia silenciosamente |
Prevención
Identifique cada recurso digital, relación con Product, condición de acceso, necesidad histórica y límite de seguridad. Mueva los recursos mediante una ruta de almacenamiento aprobada y conserve únicamente el historial de acceso que el destino pueda representar con seguridad. Separe la evidencia histórica de las reglas activas de acceso.
Ejemplo de recomendación
Un Product de software permite tres descargas después del pago y caduca tras un periodo definido. Conserve el Product y el registro histórico de compra y configure explícitamente el modelo de acceso del destino, en lugar de asumir que la antigua ruta del archivo y el estado del Order recrean el acceso.
Condición de aprobación
Customers autorizados pueden acceder a los recursos correctos bajo las condiciones previstas, usuarios no autorizados no pueden hacerlo, las compras históricas siguen siendo comprensibles y ninguna ruta de archivo del origen se trata como mecanismo funcional de entrega.
Problema 9: Suponer que las conexiones de pago, envío y marketplace acompañan a los registros
Qué sale mal
Products, Customers y Orders pueden migrarse sin recrear credenciales activas de pago, servicios de envío, publicaciones de marketplace, suscripciones de webhooks ni el estado de sincronización. Las referencias históricas pueden ser útiles, pero no activan el servicio conectado en Gambio.
Señales de alerta
El proyecto marca como “incluido” un gateway, transportista, marketplace o ERP únicamente porque existen Orders relacionados o Product IDs. Ningún responsable ha confirmado credenciales, acceso de cuenta, compatibilidad de la extensión en el destino, contratos de campos o flujos de eventos.
| Dependencia | Datos que pueden conservarse | Comportamiento que necesita propiedad separada |
|---|---|---|
| Proveedor de pago | Nombre del método y referencia de transacción | Credenciales, callbacks, liquidación, reembolsos |
| Transportista | Etiqueta del servicio y número de seguimiento | Tarifas, etiquetas, eventos de seguimiento |
| Marketplace o ERP | IDs externos y referencias históricas | Publicaciones, sincronización, reglas de conflicto |
Prevención
Cree un registro de dependencias que nombre el sistema de registro actual, identificadores intercambiados, credenciales, dirección de eventos, gestión de errores y responsable en el destino. Conserve IDs externos solo cuando sigan conectando registros. Reconfigure o reconstruya el comportamiento activo por separado del historial migrado.
Ejemplo de recomendación
Orders históricos conservan un Order ID de marketplace y una referencia de pago. Después se configura el conector del marketplace con sus propias credenciales y reglas de asignación; la presencia de esos IDs históricos no se toma como prueba de que la sincronización esté activa.
Condición de aprobación
Cada conexión necesaria tiene un responsable, credenciales funcionales, identificadores y rutas de eventos definidos y ningún comportamiento activo del negocio se deduce únicamente de registros migrados o etiquetas históricas.
Problema 10: Trasladar personalizaciones autohospedadas como datos sin analizar
Qué sale mal
Las tiendas Gambio autohospedadas pueden contener plantillas modificadas, módulos personalizados, campos adicionales de base de datos, tareas programadas o integraciones directas. Las exportaciones estándar pueden omitir sus datos, mientras que copiar tablas personalizadas sin comprender el código que las consume puede conservar fragmentos inutilizables o crear responsabilidades contradictorias en el destino.
Señales de alerta
El origen contiene columnas desconocidas, tablas personalizadas, archivos modificados o informes que dependen de valores ausentes de registros ordinarios de Product, Customer u Order. Nadie puede indicar qué proceso los lee o escribe.
| Evidencia de personalización | Pregunta que debe resolverse | Supuesto inseguro |
|---|---|---|
| Campo o tabla personalizada | ¿Qué proceso de negocio lo consume? | Todo valor almacenado debe copiarse |
| Plantilla/módulo modificado | ¿Ese comportamiento sigue siendo necesario en el destino? | El código puede moverse junto con los registros |
| Integración programada | ¿Qué IDs y eventos de cambio necesita? | La tarea continuará sin cambios |
Prevención
Trace cada personalización desde el valor almacenado hasta su uso de negocio. Clasifíquela como dato que debe continuar, configuración del destino, estado de integración, lógica de presentación, referencia histórica o comportamiento obsoleto. Conserve claves estables cuando un sistema que continúa las necesite y excluya residuos técnicos huérfanos en lugar de copiarlos sin responsable.
Ejemplo de recomendación
Un campo personalizado de Product controla el embalaje del almacén y lo lee una exportación al ERP. Conserve el valor y la clave externa de Product en un campo propiedad del destino o en un contrato de integración. No copie la antigua tabla del módulo si el proceso del destino nunca la leerá.
Condición de aprobación
Cada campo, tabla, módulo y proceso programado personalizado tiene un propósito documentado y un responsable en el destino; los valores que continúan siguen siendo utilizables, el residuo retirado se excluye deliberadamente y ningún proceso crítico depende de código de origen no identificado.
Prioridades de prevención entre problemas
La secuencia de prevención más sólida empieza por la propiedad del modelo operativo y continúa con la identidad de Products vendibles, descubrimiento, tratamiento de Customers, historial de Orders, rutas de contenido, procesamiento digital, integraciones y datos personalizados. Estas áreas deben mantenerse conectadas mediante identificadores estables y propiedad explícita. Un Product no puede aprobarse de forma aislada cuando su Category, permiso de grupo, clave externa o derecho digital aún carece de una relación de destino.
Las tablas de apoyo destacan patrones de alerta, pero la decisión debe seguir siendo específica de cada registro. El equipo debe poder explicar no solo que el dato existe, sino cómo lo utilizará la tienda de destino y qué sistema o configuración independiente posee cualquier comportamiento que no resida en el registro migrado.
Conclusión
Una migración fiable a Gambio conserva las relaciones que hacen comercialmente utilizables los registros. Distingue responsabilidades Cloud y autohospedadas, mantiene trazables las elecciones de Product, protege el descubrimiento multilingüe y las rutas de contenido, conserva contexto significativo de Customers y Orders y asigna cada integración o personalización a un responsable real. Aprobar únicamente los totales de registros sin estas relaciones no es suficiente.
Preguntas frecuentes
¿Por qué deben tratarse de forma distinta Gambio Cloud y Gambio autohospedado?
Pueden contener registros comerciales similares, pero difieren en hosting, actualizaciones, acceso al código, extensiones personalizadas y responsabilidad de infraestructura. Esas diferencias determinan si las personalizaciones y procesos operativos del origen tienen un responsable viable.
¿Cuál es la muestra de Product con mayor riesgo en Gambio?
Utilice un Product cuyas elecciones afecten al SKU, precio, stock, imagen o procesamiento de pedidos. Un Product sencillo no puede revelar si las relaciones de propiedades y combinaciones siguen siendo comercialmente utilizables.
¿Los nombres de Customer Groups demuestran que se conservó el comportamiento del grupo?
No. Las relaciones de pertenencia, permisos de Product, precios, descuentos e impuestos deben seguir produciendo la experiencia de Customer prevista. Una etiqueta sin los resultados que controla está incompleta.
¿Cómo deben revisarse los Orders históricos de Gambio?
Revise atributos de línea, componentes del total, direcciones, historial de estados, seguimiento, comentarios y referencias externas. El Order debe explicar la transacción sin fingir que un antiguo estado del proceso sigue activo en el destino.
¿Los registros de pago y marketplace recrean sus integraciones?
No. Los nombres históricos de métodos e IDs externos pueden conservarse, pero credenciales, extensiones, flujos de eventos, sincronización y gestión de errores necesitan un responsable separado en el destino.
¿Cuándo debe excluirse un campo personalizado de Gambio?
Exclúyalo cuando ningún proceso que continúe lo lea y no tenga valor histórico ni de conciliación. Consérvelo únicamente cuando su propósito de negocio y responsable en el destino estén definidos explícitamente.