La planificación del modelo de datos de BigCommerce debe comenzar por el significado, no por los recuentos. Products, Categories, Customers, Orders, CMS Pages, Blog Posts, redirecciones y campos auxiliares pueden tener nombres familiares, pero BigCommerce representa el comercio mediante estructuras definidas de catálogo, precios, canales, Customers, contenido e integraciones que pueden funcionar de manera diferente a la plataforma de origen.
Una tienda puede parecer completa después de migrar y seguir siendo comercialmente incorrecta. Las opciones de Product pueden terminar en la estructura equivocada. Las rutas de Categories pueden existir sin conservar el descubrimiento. Los registros de Customers pueden llegar sin el contexto de precios que les daba valor. Las redirecciones pueden funcionar técnicamente pero enviar a los compradores a destinos poco útiles. Los campos personalizados y metafields pueden conservarse y, aun así, quedar desconectados de la aplicación, ERP, búsqueda, merchandising o funcionamiento del escaparate que antes los utilizaba.
El enfoque más seguro consiste en traducir los registros del origen al significado que tendrán en BigCommerce antes de considerar definitivo el alcance.
Por qué el significado de los datos en BigCommerce requiere una revisión específica
BigCommerce es una plataforma SaaS alojada de destino con estructuras comerciales definidas. Esa estructura puede simplificar la gobernanza después de migrar, pero también exige decisiones de traducción más explícitas. Una plataforma de origen puede haber permitido que opciones de Product, campos de personalización, grupos de Customers, reglas de precios, landing pages y funcionamiento gestionado por aplicaciones se solaparan. BigCommerce suele exigir que esos significados queden más claramente separados.
La pregunta clave no es si un registro de origen tiene algún destino en BigCommerce. La pregunta más útil es si ese destino conserva la función comercial que cumplía el registro.
| Área de BigCommerce | Significado de migración que debe confirmarse |
|---|---|
| Opciones de Product | Si la opción del origen debe convertirse en variante, opción de variante, modificador, campo personalizado, metafield, configuración de aplicación u otra estructura definida del destino. |
| Estructura de Categories | Si las Categories del origen conservan organización del catálogo, navegación, merchandising y descubrimiento sensible al SEO. |
| Contexto de precios | Si los precios base, reglas por volumen, listas de precios, lógica de grupos de Customers y referencias externas siguen teniendo sentido. |
| Alcance por canal | Si Products, Categories, precios, contenido y URLs pertenecen al contexto correcto de escaparate o canal. |
| Registros de Customers y Orders | Si la identidad del Customer, contexto de cuenta, pertenencia a grupos, historial de Orders y valor para el servicio siguen siendo útiles. |
| Contenido y rutas | Si CMS Pages, Blog Posts, redirecciones y destinos de páginas preservan la intención del cliente. |
| Datos personalizados y de aplicaciones | Si campos personalizados, metafields, registros de aplicaciones e identificadores de sistemas externos requieren mapeo/filtrado directo, reestructuración de datos o configuración de la tienda de destino. |
Esta revisión evita una aprobación superficial. El negocio no debería limitarse a preguntar: “¿Se trasladó el registro?”. Debería preguntar: “¿BigCommerce lo conserva ahora en una estructura que respalda ventas, servicio, precios, descubrimiento y continuidad de las integraciones?”.
Estructura de Product: Products, variantes, opciones y modificadores
La estructura de Product de BigCommerce requiere interpretación cuidadosa porque las plataformas de origen usan las opciones de forma diferente. Algunas tiendas utilizan variantes para toda elección seleccionable. Otras dependen de campos de opciones personalizados, plugins, aplicaciones, configuradores, sistemas de bundles o lógica del tema. BigCommerce distingue varios conceptos de selección de Product, y esa separación influye en inventario, precios, procesamiento de pedidos, presentación y informes.
Una variante suele representar una versión vendible de un Product. Talla, color, material, paquete, modelo, acabado o unidad pueden pertenecer a la estructura de variantes cuando la elección afecta SKU, inventario, imagen, peso, precio, disponibilidad o procesamiento del pedido. Las opciones de variante describen las dimensiones seleccionables que forman esas combinaciones.
Los modificadores son diferentes. Un modificador puede representar una elección visible para el cliente que cambia la experiencia de compra sin crear necesariamente otro Product con inventario propio. Algunos ejemplos son texto de personalización, grabado, mensajes de regalo, extras opcionales, campos para cargar archivos, selección de garantía o personalización sin inventario. Si las opciones del origen se trasladan a la estructura incorrecta, la página del Product puede parecer completa mientras el funcionamiento operativo es erróneo.
| Elección de Product en origen | Pregunta de interpretación en BigCommerce | Significado que se pierde si se interpreta mal |
|---|---|---|
| Talla o color con SKU e inventario | ¿Debe convertirse en variante y opción de variante? | Puede debilitarse el significado del inventario y de las líneas de Order. |
| Grabado o mensaje de regalo | ¿Se parece más a un modificador o a un campo personalizado? | La entrada del comprador puede convertirse incorrectamente en una opción con inventario. |
| Selección de bundle o kit | ¿Es compatible, pertenece a una aplicación o depende de lógica personalizada? | Pueden romperse las expectativas de precios, procesamiento e inventario. |
| Campo de garantía o compatibilidad | ¿Es información visible, metadatos de Product o funcionamiento de una aplicación? | Puede conservarse texto pero perderse una función comercial importante. |
| Campo de carga o proceso de personalización | ¿Hace falta configurar una aplicación en destino o reestructurar los datos? | El Product puede migrar pero fallar el proceso de compra original. |
Las muestras de Product deben cubrir patrones reales del catálogo. Un Product simple, uno con muchas variantes, otro con numerosos modificadores, un bundle y un Product con datos personalizados revelan mucho más que el recuento total.
Campos personalizados, metafields y metadatos de Product
Los campos personalizados y metafields de BigCommerce tienen finalidades distintas y no deben utilizarse como contenedores intercambiables. Los campos personalizados de Product pueden guardar información adicional destinada a mostrarse en el escaparate. Los metafields son datos programáticos de clave-valor vinculados a recursos como Products, variantes, Categories y marcas; son útiles para aplicaciones e integraciones y no aparecen automáticamente como contenido ordinario del escaparate o del panel de administración.
Esta diferencia importa durante la migración. Un atributo de origen puede parecer simplemente “dato personalizado” y cumplir una función muy distinta:
| Finalidad del dato de origen | Pregunta sobre el destino en BigCommerce |
|---|---|
| Especificación visible para el Customer | ¿Debe ser campo de Product, campo personalizado, contenido estructurado de página u otro valor visible en el escaparate? |
| Elección vendible | ¿Define una variante, opción de variante o modificador en lugar de metadatos descriptivos? |
| Entrada para búsqueda o filtrado | ¿Qué estructura de BigCommerce o aplicación la utilizará realmente para el descubrimiento? |
| Referencia operativa interna | ¿Debe permanecer oculta en un metafield o seguir viviendo en el sistema externo? |
| Clave de ERP, PIM o contabilidad | ¿Qué recurso posee el identificador y cómo lo localizará el sistema conectado? |
| Funcionamiento propiedad de una aplicación | ¿La aplicación de destino admite importación o debe rediseñarse el proceso? |
El campo de destino debe elegirse según uso, visibilidad y propiedad. Trasladar todos los atributos a campos personalizados de Product puede exponer datos internos o crear un escaparate difícil de administrar. Trasladarlo todo a metafields puede conservar valores que ningún administrador, tema o aplicación utilizará. Un mapeo disciplinado registra el consumidor previsto, la relación con el recurso y si el valor sigue siendo visible para Customers, operativo, propiedad de una integración o excluido.
Categories, árboles de Categories, navegación y descubrimiento
Migrar Categories a BigCommerce no debe tratarse como copiar carpetas. Categories, árboles de Categories, asignaciones de Products, lógica de menús, descubrimiento del escaparate y rutas sensibles al SEO pueden influir en la navegación. Una Category de origen puede haber cumplido varias funciones a la vez: organización administrativa, landing page pública, colección de merchandising, agrupación de campaña, entrada de menú, filtro de búsqueda o página SEO.
La planificación debe separar esas funciones. Una Category puede necesitar convertirse en una Category de BigCommerce. Una relación de menú puede requerir configuración del escaparate. Una landing page de alto valor puede necesitar conservación de contenido o una redirección. Una estructura semejante a una colección puede requerir mapeo, reconstrucción manual, soporte de una aplicación o exclusión.
| Estructura del origen | Pregunta de planificación en BigCommerce |
|---|---|
| Category de Product | ¿Debe convertirse en Category o entrada de un árbol de Categories? |
| Colección o agrupación inteligente | ¿Es una Category, regla de merchandising, necesidad de configuración del escaparate o función equivalente de una aplicación? |
| Menú de navegación | ¿Pertenece a datos de catálogo o a configuración del tema/escaparate? |
| Landing page SEO | ¿Debe migrarse como contenido, contexto de Category, destino de redirección o página reconstruida? |
| Category de campaña o temporal | ¿Debe migrarse, retirarse, redirigirse o excluirse? |
Para negocios con varios escaparates o canales, el significado de una Category también depende de dónde deben aparecer los Products. Una Category útil en un escaparate puede ser confusa en otro. Las asignaciones de Products, nombres, rutas y destinos de redirección deben revisarse en el contexto comercial correspondiente.
Precios, grupos de Customers y listas de precios
Los precios son una de las diferencias más importantes del modelo de datos de BigCommerce porque pueden existir en varios niveles. Una tienda de origen puede tener precios base, de oferta, por volumen, por grupo de Customers, niveles mayoristas, precios regionales, precios negociados, lógica de listas de precios, reglas gestionadas por aplicaciones o sistemas externos.
La planificación no debe reducir todas esas relaciones a un único precio de Product salvo que el negocio quiera deliberadamente un modelo más sencillo. El contexto debe revisarse como una relación entre Products, Customers, grupos, listas de precios, condiciones de cantidad, escaparates, canales, aplicaciones y sistemas externos.
| Fuente del precio | Significado que debe preservarse |
|---|---|
| Precio base de Product | Valor de venta predeterminado. |
| Precio por volumen | Expectativas de precio basadas en cantidad. |
| Precio por grupo de Customers | Lógica de segmento de compradores o venta mayorista. |
| Lista de precios | Contexto más estructurado de audiencia, canal o precios empresariales. |
| Precio gestionado por una aplicación | Lógica comercial que puede seguir perteneciendo a una aplicación o a un sistema externo de precios. |
| Sistema externo de precios | Continuidad del identificador y la sincronización, no solo del valor visible. |
Un Product migrado puede mostrar el precio base correcto y aun así tener un significado comercial incorrecto para un comprador mayorista, grupo de Customers, canal o escaparate regional. Los casos sensibles deben formar parte explícita del modelo de relaciones como combinaciones Product–grupo de Customers–lista de precios–canal, no inferirse del precio base.
Canales, escaparates y contexto de venta
Las estructuras de canales y escaparates de BigCommerce pueden afectar disponibilidad de Products, presentación de Categories, contexto de moneda, relaciones con sites, menús, supuestos de precios, redirecciones y experiencia de Customers. Por ello, el significado del canal forma parte del modelo de datos y no es solo un ajuste de implementación.
Las plataformas de origen pueden expresar lógica de canal mediante varias tiendas, websites, marketplaces, regiones, versiones lingüísticas, dominios, integraciones o código personalizado. BigCommerce necesita una interpretación explícita de cada relación: qué Products se asignan a cada canal, qué árbol de Categories corresponde a cada site, qué contenido y rutas pertenecen a cada escaparate y qué precios o reglas de Customers se aplican en ese contexto.
| Significado en origen | Relación que debe definirse en BigCommerce |
|---|---|
| Escaparate regional o de marca | Canal, site, dominio, árbol de Categories, propiedad del contenido y destino de redirecciones. |
| Marketplace o canal social | Asignación de Products, propiedad de listings externos, identificadores y responsabilidad de sincronización. |
| Subconjunto de catálogo específico de una tienda | Asignación Product–canal y estructura de Categories visible en ese escaparate. |
| Precios específicos de una tienda | Lista de precios, grupo de Customers, contexto de canal, sistema externo de precios u otro propietario definido. |
| Contenido o navegación localizados | Contenido propiedad del escaparate, configuración del tema, contenido traducido o una capa de implementación separada. |
Los registros de Products compartidos pueden seguir siendo compartidos mientras sus asignaciones y presentación varían por canal. Aplanar esas relaciones puede hacer que la administración parezca completa mientras un escaparate recibe el surtido, ruta de Category, contexto de precios o destino de redirección equivocados. El mapa debe registrar tanto el registro compartido como cada relación específica por canal que debe mantenerse.
Customers, cuentas e historial de Orders
Los datos de Customers y Orders deben interpretarse como contexto comercial y de servicio. Un Customer puede incluir identidad, direcciones, estado de la cuenta, grupo, atributos personalizados, consentimiento, relaciones con Orders y expectativas de precios. Un Order puede conservar nombres de Products, SKUs, cantidades, descuentos, impuestos, envío, facturación, procesamiento, etiquetas de pago, notas, reembolsos y referencias externas.
El plan debe preguntar para qué necesita el negocio el historial de Customers y Orders. Servicio al cliente, recompra, acceso mayorista, consultas de soporte, informes, revisión de reembolsos y conciliación con integraciones pueden necesitar diferentes niveles de detalle.
Un sistema de cuentas del origen puede no traducirse exactamente al funcionamiento de cuentas de BigCommerce. Contraseñas, pertenencia a grupos, fidelización, suscripciones, procesos de cotización, cuentas de empresa, aprobaciones de Customers o referencias externas de CRM pueden requerir revisión específica. Algunos valores pueden mapearse. Otros pueden usar mapeo o filtrado directo. Otros necesitan reestructuración o una ruta específica de una aplicación. Algunos requieren configurar una aplicación en destino o permanecer fuera del alcance.
Los Orders requieren la misma disciplina. El historial debe seguir siendo legible y útil, pero la configuración activa de pagos, funcionamiento del proceso de compra, configuración de envíos, impuestos, notificaciones y procesamiento pertenece a la configuración de la tienda de destino.
Contenido, páginas, Blog Posts, redirecciones y significado de las rutas
El contenido y la continuidad de URLs forman parte de la traducción del modelo de datos porque páginas, Blog Posts, redirecciones, rutas de Products, rutas de Categories y destinos de escaparates influyen en la confianza y en la continuidad del tráfico. Una redirección puede funcionar técnicamente y aun así debilitar el recorrido del Customer si envía una URL antigua de Product, Category o contenido a un destino demasiado general o no relacionado.
CMS Pages y Blog Posts deben revisarse por finalidad. Algunas páginas respaldan confianza, políticas, explicación de marca, orientación de compra, tráfico de campañas o descubrimiento SEO. Algunos Blog Posts aportan tráfico de larga cola o educación sobre Products. Algunas páginas de origen ya no necesitan migrarse, pero pueden seguir requiriendo redirección a un destino útil.
| Tipo de contenido o ruta | Decisión de migración |
|---|---|
| URL de Product | Conservarla o redirigirla al Product más próximo. |
| URL de Category | Preservar la intención de descubrimiento cuando sea posible. |
| CMS Page | Migrar, reconstruir, consolidar, redirigir o retirar. |
| Blog Post | Conservarlo si aporta tráfico, educación, confianza o valor de enlaces internos. |
| Página de campaña | Decidir si la campaña sigue activa, necesita redirección o debe retirarse. |
| Ruta específica de escaparate | Confirmar el destino correcto de escaparate o canal. |
La identidad de las rutas pertenece al modelo de datos de BigCommerce porque las redirecciones conectan la intención del origen con un destino utilizable. Las buenas relaciones de redirección preservan recorridos del cliente, no solo mapeos técnicos aislados.
Aplicaciones, integraciones y datos de sistemas externos
Las migraciones a BigCommerce suelen cruzarse con sistemas externos. ERP, PIM, CRM, contabilidad, impuestos, envío, suscripciones, personalización, búsqueda, Reviews, fidelización, almacenes, marketplaces o marketing pueden depender de identificadores y campos personalizados que no aparecen en una revisión normal del escaparate.
La pregunta del modelo de datos es si BigCommerce debe ser propietario del dato, mostrarlo, entregarlo a una aplicación, conservarlo para conciliación o ignorarlo porque el proceso se reconstruirá. Son resultados distintos.
| Dependencia externa | Aspecto que debe revisarse en BigCommerce |
|---|---|
| ERP o contabilidad | IDs de Products, SKUs, referencias de Orders, identificadores de Customers y contexto fiscal/descuentos. |
| PIM | Propiedad de atributos, contenido de Products, imágenes, variantes y campos personalizados. |
| CRM o marketing | Identidad de Customers, consentimiento, segmentación, historial de Orders y atributos personalizados. |
| Aplicación de suscripción o fidelización | Registros propiedad de la aplicación, funcionamiento y expectativas de continuidad. |
| Aplicación de búsqueda o merchandising | Atributos de filtro, campos personalizados, etiquetas de Products, reglas y ordenación. |
| Sistema de envío o impuestos | Identificadores externos y funcionamiento próximo al proceso de compra. |
Si los datos ya tienen un destino adecuado en BigCommerce, el mapeo o filtrado directo puede bastar. Si pertenecen a una aplicación, están controlados externamente o dependen de una relación no nativa, hay que definir la aplicación de destino, el sistema externo o la reestructuración necesaria antes de cerrar el mapa origen→destino.
El alcance de datos debe evaluarse por su uso comercial
El alcance de una migración a BigCommerce debe juzgarse por el uso posterior. Products, Customers, Orders, Categories, CMS Pages, Blog Posts y redirecciones pueden encajar en destinos de registros ordinarios, pero su significado puede seguir dependiendo de opciones de Product, árboles de Categories, asignaciones de canales, grupos de Customers, listas de precios, campos personalizados, metafields, aplicaciones e identificadores externos.
Un mapa útil separa estos resultados:
| Resultado del mapeo | Significado en BigCommerce |
|---|---|
| Registro y relación nativos | El significado del origen encaja en un Product, variante, modificador, Category, Customer, Order, contenido, redirección u otra relación compatible de BigCommerce. |
| Configuración de escaparate o canal | El registro existe, pero su uso depende de asignaciones de canal, árboles de Categories, sites, temas, menús, contexto de precios u otra configuración de la tienda de destino. |
| Propiedad de aplicación o integración | El dato sigue perteneciendo a ERP, PIM, CRM, suscripción, fidelización, búsqueda u otro sistema conectado y necesita un identificador estable entre sistemas. |
| Transformación de datos específica | La estructura del origen debe cambiarse porque su significado no coincide con un registro o relación disponible en destino. |
| Excluir, archivar o rediseñar | El valor es obsoleto, duplicado, depende de lógica retirada o ya no tiene un propietario comercial vigente. |
Este modelo mantiene el foco en la traducción del significado y evita confundir un recuento elevado con un modelo utilizable. El mejor alcance explica en qué se convierte cada significado importante del origen, qué relación lo conserva, quién lo gobierna después del lanzamiento y qué debe permanecer deliberadamente fuera de la tienda de destino.
Conclusión
Las diferencias del modelo de datos de BigCommerce importan porque la plataforma asigna significado comercial estructurado a los registros migrados. Products, variantes, modificadores, Categories, grupos de Customers, listas de precios, canales, Customers, Orders, CMS Pages, Blog Posts, redirecciones, campos personalizados, metafields, aplicaciones e identificadores externos deben revisarse según la forma en que el negocio los utilizará después del lanzamiento.
El plan más sólido no conserva solo la presencia de los datos, sino su funcionamiento. Separa registros nativos de configuración por canal o escaparate, valores propiedad de integraciones, reestructuración de datos y expectativas excluidas deliberadamente antes de finalizar el modelo del destino.
Preguntas frecuentes
¿Por qué son importantes las opciones de Product de BigCommerce durante una migración?
Porque pueden representar significados comerciales distintos. Algunas opciones deben convertirse en variantes, otras se parecen más a modificadores, otras pueden ser campos personalizados y otras dependen de aplicaciones o lógica propia. Si se interpreta mal el significado, las páginas pueden parecer completas mientras inventario, precios, procesamiento o selección del Customer funcionan incorrectamente.
¿Bastan los campos personalizados y metafields de BigCommerce para todos los datos personalizados del origen?
No. Pueden conservar determinados datos adicionales, pero no reproducen automáticamente el funcionamiento de la plataforma de origen. Registros de aplicaciones, identificadores externos, lógica específica de Product y transformaciones personalizadas pueden necesitar reestructuración, migración de aplicación o configuración de la tienda de destino.
¿Las Categories de BigCommerce conservan automáticamente la navegación del origen?
No siempre. Categories, árboles de Categories, estructura de menús, landing pages SEO y contexto de escaparate/canal deben revisarse por separado. Un registro de Category puede existir mientras el camino de descubrimiento sigue dependiendo de navegación del destino, contexto de canal, contenido o redirecciones.
¿Cómo deben influir las listas de precios y grupos de Customers en la planificación?
Deben tratarse como relaciones, no como campos aislados. El precio de un Product puede parecer correcto mientras un grupo de Customers, lista de precios, regla de cantidad o condición del escaparate todavía necesita revisión.
¿Cómo deben representarse en BigCommerce los datos propiedad de aplicaciones o integraciones?
Primero identifique el sistema de registro que seguirá gobernándolos. Conserve un campo, metafield o identificador externo en BigCommerce solo cuando la aplicación o integración de destino vaya a utilizarlo. Contratos de suscripción, saldos de fidelización, reglas de búsqueda, estado de marketplace y registros similares deben seguir la ruta de datos compatible de la aplicación de destino, no aplanarse como campos genéricos de Product o Customer.
¿Cómo debe conservarse el significado del catálogo específico de cada canal?
Identifique qué Products, precios, Categories, contenido y reglas de visibilidad pertenecen a cada canal antes de mapear. Los registros compartidos pueden seguir siendo compartidos, pero las diferencias propias de cada canal no deben aplanarse cuando influyen en lo que ve el comprador o en lo que opera el equipo.