Los fallos en una migración a BigCommerce suelen aparecer cuando los registros se conservan, pero se pierde la relación que les da significado comercial o operativo en la tienda. Las variantes y los modificadores de Product pueden parecer similares en el origen y, sin embargo, comportarse de manera distinta durante el procesamiento de pedidos. Los Customer Groups y las listas de precios pueden influir en lo que ve un comprador, pero no representan un único campo de precio. Los canales, sitios, árboles de Categories, contenido, ubicaciones de inventario y tecnologías de tienda añaden todavía más contexto.
Los problemas siguientes se centran en errores recurrentes que dejan una tienda BigCommerce poblada pero comercialmente incoherente. Cada medida preventiva identifica la relación que debe sobrevivir y la condición concreta que demuestra que el riesgo está bajo control.
Problema 1: tratar variantes, modificadores y campos de Product como el mismo modelo de elección
Qué falla
Las opciones del origen se asignan al campo de BigCommerce que parece más conveniente. Los SKU secundarios con inventario se convierten en modificadores, la personalización se convierte en variantes y las especificaciones técnicas se transforman en elecciones para el comprador.
Las variantes de BigCommerce son combinaciones de valores de opciones de variante y pueden llevar datos comerciales propios. Los modificadores representan elecciones del comprador que personalizan o añaden algo al artículo procesado, pero no cambian qué variante se selecciona del inventario. Los campos personalizados y metafields de Product cumplen otras funciones descriptivas u operativas.
Señales de alerta temprana
| Señal de alerta temprana | Qué indica |
|---|---|
| Las combinaciones de talla y color con stock independiente se crean como modificadores. | Las elecciones con inventario se están separando de la identidad de la variante. |
| El grabado, la fecha, la carga de archivos o las opciones de garantía se crean como variantes. | La personalización sin inventario se está convirtiendo en SKU artificiales. |
| Se pierden los SKU secundarios del origen porque el Product principal se trata como la única unidad de inventario. | La continuidad del procesamiento y del stock se romperá a nivel de variante. |
| Las especificaciones del Product solo aparecen dentro de descripciones o elecciones del comprador. | Los atributos estructurados se están mezclando con controles de venta. |
Prevención
Clasifique cada valor del origen según su función en el procesamiento del pedido. Use variantes para combinaciones vendibles identificables de forma independiente, modificadores para personalizaciones específicas de la compra que no seleccionan otra variante con stock, y campos personalizados o metafields para datos descriptivos u operativos.
Conserve como una sola relación los valores de opciones de variante, SKU, inventario, precio, peso, imágenes e identificadores externos. Conserve las selecciones de modificadores junto con la línea del Order y no asigne inventario a combinaciones de modificadores.
Ejemplo de recomendación
Para unos pantalones a medida, represente la cintura y el largo de pierna como variantes cuando cada combinación se almacene y procese por separado. Mantenga el texto del monograma como modificador y las instrucciones de cuidado del tejido como datos personalizados del Product.
Condición de Pass
Cada elección de muestra resuelve a la variante procesada correcta, las selecciones de modificadores siguen visibles en la línea del Order y los campos descriptivos no crean variantes ni registros de inventario ficticios.
Problema 2: conservar Categories pero romper los árboles de Categories y el descubrimiento en la tienda
Qué falla
Las Categories del origen se importan como una jerarquía única, plana o global sin considerar los árboles de Categories de BigCommerce, el contexto de canal, los menús, la búsqueda por facetas, la ordenación o la tecnología de la tienda. Los Products siguen asignados a Categories, pero los compradores encuentran ramas ausentes, filtros irrelevantes o el árbol equivocado en una tienda.
Una Category del origen también puede representar una marca, campaña, agrupación interna o página de destino SEO en lugar de una jerarquía de catálogo duradera.
Señales de alerta temprana
- Se supone que un solo árbol de Categories sirve para todas las tiendas o canales.
- Las asignaciones de Products se revisan sin comprobar qué árbol utiliza la tienda.
- Los valores de marca, atributo y campaña se convierten todos en Categories.
- Se espera que la navegación y la búsqueda por facetas se deriven automáticamente de las filas de Category importadas.
Prevención
Clasifique las agrupaciones del origen por finalidad. Cree o asigne el árbol de Categories previsto para cada contexto de tienda, conserve las relaciones Product→Category y mantenga separados los significados de marca, filtro, campaña y navegación.
Defina qué valores alimentan la búsqueda por facetas y qué Categories necesitan contenido, ordenación, imágenes o redirecciones. Trate Stencil, Catalyst y las tiendas headless como implementaciones que consumen relaciones del catálogo, no como resultados automáticos de importar Categories.
Ejemplo de recomendación
Para un comercio con tiendas minorista y mayorista, utilice árboles de Categories adecuados para cada canal cuando los recorridos de compra sean distintos, mantenga la identidad compartida de los Products y conserve como atributos o datos personalizados los valores de Product utilizados por filtros en lugar de duplicarlos como Categories.
Condición de Pass
Cada tienda utiliza el árbol de Categories previsto, los Products aparecen en las ramas correctas, la navegación llega a esas ramas y los filtros se basan en datos coherentes en lugar de duplicaciones accidentales de Categories.
Problema 3: separar Customer Groups de las listas de precios que les dan significado
Qué falla
Los Customer Groups se migran como etiquetas, mientras que las listas de precios, los registros de precios por variante, el acceso a Categories o las asignaciones de canal se gestionan por separado. Los compradores aparecen en el grupo correcto, pero siguen recibiendo precios de catálogo, la moneda equivocada o acceso al surtido incorrecto.
Las listas de precios de BigCommerce pueden sustituir precios de variantes y asignarse mediante Customer Groups, canales o una combinación de Customer Group y canal. Una lista de precios sin su asignación no constituye un modelo de precios completo.
Señales de alerta temprana
| Señal de alerta temprana | Qué indica |
|---|---|
| La migración de grupos se considera completa cuando los Customers muestran el nombre de grupo correcto. | No se ha conservado el significado comercial del grupo. |
| Los precios solo se asignan a nivel de Product aunque las variantes sean distintas. | La cobertura de la lista de precios será incorrecta para artículos vendibles concretos. |
| Las asignaciones de listas de precios omiten el contexto de canal. | Un precio válido puede aparecer en la tienda equivocada o no aparecer donde se necesita. |
| Los precios por volumen y las sustituciones de listas de precios se combinan sin reglas de precedencia. | Mecanismos de precio concurrentes pueden producir resultados inconsistentes. |
Prevención
Modele el grupo, el acceso a Categories, la lista de precios, el registro de precio de variante, la moneda, el canal y la asignación como estructuras conectadas. Conserve la relación exacta que determina qué comprador autenticado recibe qué precio de variante en qué tienda.
Separe los precios históricos de Orders de los registros activos de listas de precios. Conserve los identificadores de contratos externos o de precios de ERP cuando otro sistema siga siendo la fuente autorizada.
Ejemplo de recomendación
Para un grupo VIP que compra en una tienda regional, conserve la pertenencia al grupo, el acceso a Categories, la lista de precios, los registros de precios a nivel de variante, la moneda y la asignación que conecta ese grupo con el canal.
Condición de Pass
Un Customer representativo autenticado ve el surtido y los precios de variantes previstos en el canal correcto, mientras que los Customers fuera del grupo reciben el precio alternativo adecuado.
Problema 4: tratar canales, sitios y tiendas como simples etiquetas
Qué falla
Products, Categories, Customers, precios, monedas, menús y contenido se migran sin conservar las relaciones de canal y sitio que determinan dónde aparecen. La tienda dispone de una tienda principal correcta, mientras que marcas secundarias, regiones, marketplaces o experiencias headless heredan catálogo y configuración equivocados.
En BigCommerce, un canal representa un contexto de venta, mientras que un sitio representa un sitio web controlado por el comerciante y vinculado a un canal de tienda. Por tanto, las asignaciones y configuraciones específicas por canal afectan a mucho más que una etiqueta de visualización.
Señales de alerta temprana
| Señal de alerta temprana | Qué indica |
|---|---|
| Los registros se asignan por defecto al canal principal porque no se proporciona un ID de canal. | Falta la propiedad de canal en los registros migrados. |
| Las asignaciones de Products y listas de precios se revisan globalmente y no por tienda. | Se están aplanando diferencias de surtido y precios específicas de cada tienda. |
| Dominios, sitios, menús, monedas y árboles de Categories se documentan por separado. | La relación completa de la tienda no se está gestionando como un único sistema. |
| Las aplicaciones e integraciones suponen que toda interacción de Order o Product pertenece al canal predeterminado. | Los sistemas posteriores clasificarán incorrectamente el origen y el contexto. |
Prevención
Defina el modelo de canales antes de la asignación final. Identifique cada tienda, marketplace, POS, canal de marketing o canal personalizado; el sitio y dominio vinculados a cada tienda; y el contexto de Product, árbol de Categories, precios, moneda, menú, Order y aplicación que corresponde a cada uno.
Conserve los IDs de canal y las referencias de canal del origen en las asignaciones de integración. No utilice el canal predeterminado como alternativa implícita sin explicación.
Ejemplo de recomendación
Para dos tiendas de marca y un canal de Amazon, mantenga un catálogo compartido de Products cuando corresponda, asigne Products y listas de precios a los canales de tienda correctos, utilice el árbol de Categories y sitio previstos para cada marca y conserve por separado el origen de los Orders del marketplace.
Condición de Pass
Products, precios, menús, árboles de Categories, Orders e integraciones resuelven al canal y sitio previstos. Ninguna tienda secundaria depende accidentalmente del funcionamiento del canal predeterminado.
Problema 5: importar inventario sin contexto de ubicación y canal
Qué falla
Se copia una única cantidad de stock al Product o variante aunque el origen controle almacenes, tiendas físicas, puntos de recogida, proveedores o asignaciones por canal. El total parece razonable, pero la disponibilidad para recogida, el procesamiento de pedidos y la sincronización externa hacen referencia a la ubicación o unidad vendible equivocada.
El problema se agrava cuando el origen dispone de stock a nivel de variante pero la asignación del destino utiliza el Product principal, o cuando un WMS sigue siendo la fuente autorizada después de la migración.
Señales de alerta temprana
- Los archivos de inventario contienen SKU y cantidad, pero no identificador de ubicación.
- Se utiliza la cantidad del Product principal para Products con variantes reales.
- Las ubicaciones BOPIS o de recogida no aparecen en el mapa de ubicaciones.
- Se descartan los IDs de almacén externos después de importar las cantidades iniciales.
Prevención
Asigne el inventario a la variante de Product y ubicación de BigCommerce que realmente lo poseen. Conserve identificadores de ubicación, SKU de variantes, claves externas de inventario y cualquier relación de canal o recogida necesaria para el proceso que seguirá funcionando.
Separe el inventario actual vendible de movimientos históricos, stock reservado, stock dañado, disponibilidad de proveedores y otros estados que no pertenecen a la cantidad inicial.
Ejemplo de recomendación
Para un minorista con un almacén central y tres tiendas de recogida, asigne cada ubicación del origen a la ubicación correspondiente de BigCommerce, conserve cantidades por variante y claves de almacén, y mantenga las reglas de disponibilidad por canal o recogida separadas de la cantidad bruta.
Condición de Pass
Las variantes de muestra muestran la cantidad prevista en cada ubicación, los servicios de recogida o procesamiento reconocen al propietario correcto del stock y el sistema de inventario que continúa activo actualiza los mismos registros variante→ubicación sin duplicados.
Problema 6: tratar las redirecciones como una importación técnica final
Qué falla
Las redirecciones se generan después de haber finalizado las rutas de Product, Category, página y tienda. Las URL antiguas se asignan mecánicamente a la ruta de destino más cercana sin conservar la intención del usuario, canal, sitio, configuración regional o propiedad del contenido.
BigCommerce puede gestionar redirecciones y rutas de sitios, pero un archivo de redirecciones no resuelve contenido ausente, árboles de Categories incorrectos, diferencias de tecnología de tienda o destinos específicos por canal.
Señales de alerta temprana
| Señal de alerta temprana | Qué indica |
|---|---|
| La planificación de redirecciones incluye URL de Products pero excluye Categories, páginas, Blog Posts, rutas filtradas y contenido de campañas. | El inventario de redirecciones no representa toda la superficie de tráfico. |
| Se usa un único destino en varias tiendas aunque cada sitio tenga una estructura de rutas distinta. | Se están colapsando recorridos específicos por canal. |
| Las redirecciones apuntan a páginas no publicadas o ausentes de la tienda activa. | La asignación existe técnicamente pero no es utilizable por los Customers. |
| Se ignoran parámetros de consulta heredados y rutas generadas por aplicaciones. | Rutas importantes no canónicas o creadas por integraciones pueden fallar sin ser detectadas. |
Prevención
Cree un inventario de rutas vinculado a la propiedad del destino. Asigne cada URL importante del origen a un Product, Category, página, Blog Post, ruta de sitio, aplicación de tienda, contenido sustitutivo o decisión deliberada de retirada.
Priorice ingresos, tráfico orgánico, backlinks, marcadores de Customers y campañas activas. Mantenga explícito el contexto de canal y sitio cuando un mismo patrón de origen necesite destinos distintos.
Ejemplo de recomendación
Para un comercio con varias tiendas, asigne por separado las principales URL de Products y Categories para cada sitio de marca, conecte páginas de campaña retiradas con contenido sustitutivo relevante y conserve las rutas de aplicaciones headless cuando la tienda las gestiona fuera del catálogo central.
Condición de Pass
Las URL prioritarias llegan a contenido útil en el sitio y canal previstos, ninguna redirección apunta a un destino no disponible y las rutas omitidas cuentan con una decisión intencionada de retirada.
Problema 7: copiar campos personalizados y metafields sin conservar la propiedad de la aplicación
Qué falla
Campos personalizados del origen, datos de aplicaciones, indicadores de integraciones, valores SEO e identificadores externos se asignan todos a campos personalizados de Product o metafields. Los valores llegan sin tipos, permisos, namespaces, consumidores o recursos principales claramente definidos.
BigCommerce admite metafields en varios recursos y campos personalizados de Product para información de tienda, pero esas estructuras no recrean automáticamente la aplicación, el tema, la integración o el proceso que utilizaba los datos del origen.
Señales de alerta temprana
- El destino se elige a partir de la etiqueta del campo del origen en vez del consumidor del dato.
- Los valores de variante se adjuntan al Product principal.
- Los campos propiedad de aplicaciones se recrean bajo namespaces no relacionados.
- Los IDs del origen que hacían referencia a Products, Customers, contenido multimedia u Orders se copian literalmente.
Prevención
Clasifique los datos personalizados por responsable y finalidad. Use campos personalizados de Product para información adecuada que deba mostrarse en la tienda, metafields del recurso para datos operativos o de aplicación con tipo definido, y sistemas externos para los registros que sigan bajo su gobierno.
Traduzca las referencias a IDs del destino, conserve namespaces y permisos, y registre el tema, aplicación, API o integración que consume cada campo.
Ejemplo de recomendación
Guarde una especificación pública de material como campo personalizado de Product cuando la tienda deba mostrarla. Conserve un código de almacén a nivel de variante como metafield de la variante y mantenga el estado de suscripción bajo la aplicación de suscripciones que lo gestiona.
Condición de Pass
Los datos personalizados aparecen en el recurso correcto, son consumidos por la tienda o sistema previsto y no contienen namespaces huérfanos, sustituciones a nivel de Product principal ni IDs del origen copiados sin traducción.
Problema 8: tratar la presencia de Customers y Orders como continuidad operativa
Qué falla
Los recuentos de Customers y Orders coinciden, pero están incompletos la identidad, direcciones, asignación de grupo, consentimiento, variantes de líneas de Order, descuentos, impuestos, envíos, reembolsos, consignaciones, expediciones, estados y referencias externas. Después, las etiquetas históricas de pago y envío se confunden con la configuración actual de proceso de compra y procesamiento de pedidos.
Este fallo debilita a soporte y finanzas incluso cuando la tienda puede crear Orders nuevos correctamente.
Señales de alerta temprana
- La identidad del Customer se compara únicamente por correo electrónico.
- La asignación de grupo se revisa sin comprobar precios ni acceso a Categories.
- Los Orders se muestrean únicamente por número y total.
- Faltan Orders con varias direcciones, reembolsados, parcialmente enviados o originados en otros canales.
Prevención
Conserve identidad, direcciones, atributos, consentimiento, grupo e IDs externos del Customer según la finalidad empresarial. Conserve las líneas históricas de Order, variantes, precios, ajustes, impuestos, direcciones de envío, consignaciones, expediciones, reembolsos, estados, notas, canal de origen y referencias externas al nivel que necesitan soporte y finanzas.
Mantenga la evidencia histórica separada de la configuración actual de pagos, proceso de compra, envíos, impuestos y procesamiento de pedidos.
Ejemplo de recomendación
Para un Order regional enviado parcialmente, conserve el Customer y su grupo, las variantes compradas, el canal, las direcciones de envío, las consignaciones, el seguimiento de expediciones, descuento, impuestos, evidencia de reembolso e ID del Order en ERP. Configure por separado el proceso de compra y los envíos regionales futuros.
Condición de Pass
Los Customers siguen siendo identificables y están clasificados comercialmente, los Orders históricos continúan siendo comprensibles para soporte y finanzas, y las operaciones actuales no dependen de etiquetas importadas como si fueran configuración.
Prioridades de prevención comunes a varios problemas
| Prioridad | Control requerido |
|---|---|
| Propiedad de las elecciones | Separar variantes, modificadores, campos personalizados, metafields y datos de aplicaciones según su función. |
| Contexto de tienda | Conservar las relaciones entre canal, sitio, árbol de Categories, menú, ruta y precios. |
| Contexto comercial | Conectar Customer Groups con acceso a Categories, listas de precios, precios de variantes y canales. |
| Identidad operativa | Mantener estables los identificadores de variante, ubicación, Customer, Order, canal y sistema externo. |
| Separación histórica | Conservar evidencia de Orders sin tratarla como configuración activa de proceso de compra o procesamiento de pedidos. |
Revise estos controles conjuntamente porque los fallos de BigCommerce suelen atravesar varias capas. Un error de variante puede afectar a precios, inventario, elección en la tienda, evidencia de Orders e identificadores externos al mismo tiempo. El registro de prevención debe identificar al responsable y la prueba correspondiente para cada capa afectada.
Conclusión
Los problemas de migración a BigCommerce aparecen cuando registros relacionados se importan de forma independiente. Variantes, modificadores, árboles de Categories, Customer Groups, listas de precios, canales, sitios, ubicaciones de inventario, redirecciones, datos personalizados, Customers y Orders contienen contexto que debe mantenerse conectado.
El enfoque preventivo más sólido define esas relaciones antes de una asignación a gran escala. Cuando cada registro tiene el responsable, canal, contexto comercial, identidad externa y condición de Pass correctos, la tienda migrada puede operar de manera coherente entre tiendas y sistemas.
Preguntas frecuentes
¿Cuál es la diferencia entre una variante y un modificador de BigCommerce?
Una variante representa la combinación vendible que puede llevar SKU, precio, inventario, imágenes y otros datos comerciales. Un modificador cambia o personaliza el artículo procesado, pero no selecciona otra variante controlada por inventario.
¿Por qué pueden seguir fallando las Categories migradas en una tienda BigCommerce?
Los registros de Category también deben pertenecer al árbol de Categories y contexto de tienda previstos. La navegación, búsqueda por facetas, ordenación, contenido y asignación de canal son relaciones independientes.
¿Los Customer Groups recrean automáticamente los precios de grupo?
No. Los precios de grupo pueden depender de listas de precios, registros de precios a nivel de variante, acceso a Categories, moneda, canal y asignaciones de listas de precios. La etiqueta del grupo por sí sola no es suficiente.
¿Cómo afecta Multi-Storefront al alcance de migración?
Products, árboles de Categories, listas de precios, monedas, menús, sitios, rutas, Orders y aplicaciones pueden tener significado específico por canal. El modelo de migración debe conservar esas asignaciones en lugar de enviar todo por defecto a la primera tienda.
¿Todos los campos personalizados del origen deben convertirse en campos personalizados de Product en BigCommerce?
No. Algunos valores pertenecen a metafields de recursos, variantes, aplicaciones, sistemas externos o implementación de la tienda. El destino depende del responsable del campo, su consumidor, visibilidad y recurso principal.
¿Los Orders importados configuran el proceso de compra y el procesamiento de pedidos de BigCommerce?
No. Los Orders importados conservan evidencia histórica de transacciones. El funcionamiento actual de proceso de compra, pagos, envíos, impuestos, ubicaciones y procesamiento de pedidos requiere configuración independiente de BigCommerce y responsabilidad de integración.