Si BigCommerce se selecciona como plataforma de destino, la preparación debe definir cómo se convertirá la tienda de origen en un catálogo BigCommerce manejable antes de ejecutar cualquier migración. Products, variantes, opciones, modificadores, campos personalizados, metafields, Categories, listas de precios, grupos de Customers, canales, Customers, Orders, contenido e integraciones son áreas de responsabilidad independientes. Una plataforma de origen puede combinar varias de ellas en un mismo Product o registro de extensión.
El paquete de preparación debe indicar quién será propietario de cada elemento en destino, aportar evidencia representativa, asignar un responsable y definir una condición de preparación. Así, el conjunto de muestras utilizado en la migración representativa puede rastrearse hasta evidencia concreta del origen.
Definir el alcance operativo y del catálogo en BigCommerce
Primero registre los límites operativos previstos en BigCommerce.
| Área | Decisión de preparación | Evidencia |
|---|---|---|
| Identidad del catálogo | Qué registros del origen se convierten en Products y variantes | Mapa de familias de Products con IDs de origen y propiedad de SKU |
| Elecciones del comprador | Qué valores son variantes, modificadores, campos personalizados o datos de aplicaciones | Matriz representativa de opciones |
| Organización del catálogo | Qué Categories, marcas, filtros y landing pages del origen se mantienen | Esquema de Categories y descubrimiento |
| Contexto comercial | Qué grupos de Customers, listas de precios, precios por volumen, promociones y monedas son relevantes | Inventario de relaciones de precios |
| Alcance por canal | Qué Products, Categories, contenido, monedas y locales pertenecen a cada canal o escaparate | Matriz de asignación de canales |
| Datos personalizados | Qué registros pertenecen a campos personalizados, metafields, aplicaciones o sistemas externos | Registro de campos y dependencias |
Documente si la “tienda” de origen representa un único escaparate, varios escaparates regionales, un canal de marketplace, una marca, una unidad de negocio o un catálogo específico por Customer. Products similares pueden necesitar una identidad compartida de BigCommerce con asignaciones por canal, o identidades separadas cuando la propiedad comercial sea distinta. El mismo criterio debe aplicarse de forma coherente a Categories, contenido, precios, monedas y acceso de Customers para que el catálogo de destino no mezcle registros pertenecientes a contextos de venta distintos.
Preparar accesos, exportaciones y definiciones del origen
Prepare los accesos del origen y de BigCommerce necesarios para recuperar e interpretar los datos incluidos en el alcance. Conserve copias fechadas para que el equipo pueda explicar el estado del origen incluso si la tienda activa cambia.
Recopile:
- acceso administrativo a la tienda de origen y BigCommerce con permisos adecuados;
- exportaciones de Products, variantes, Categories, Customers, Orders, contenido y redirecciones cuando estén disponibles;
- recursos multimedia y documentos de Products cuando los enlaces del origen puedan caducar o requieran autenticación;
- evidencia de listas de precios, grupos de Customers, precios por volumen, promociones y monedas;
- asignaciones a canales o escaparates y listas de contenido localizado;
- diccionarios de campos personalizados, metafields, aplicaciones e identificadores externos;
- informes de ERP, PIM, WMS, CRM, marketplaces o contabilidad que identifiquen claves compartidas;
- un registro de cambios del origen para los registros que probablemente cambien antes de la ventana de migración.
| Elemento de evidencia | Responsable | Condición de preparación |
|---|---|---|
| Registro de accesos | Administradores de la tienda | Las áreas necesarias del origen y de BigCommerce son accesibles |
| Archivo de exportaciones | Responsable de datos | Los archivos se abren, contienen los registros previstos y tienen fecha de exportación |
| Diccionario de campos | Responsable técnico o de catálogo | Los campos importantes tienen finalidad, tipo, entidad padre y propietario de destino |
| Evidencia de precios | Responsable comercial | Se distinguen contextos de precios base, por grupo, por lista, por volumen y promocionales |
| Inventario de canales | Responsable de canales | Cada canal tiene definido su alcance de Products, Categories, contenido, locale y moneda |
Preparar Products, variantes, opciones y modificadores
BigCommerce distingue entre variantes vendibles, modificadores del comprador y datos descriptivos de Product. Prepare ejemplos del origen que permitan ver esas diferencias.
Incluya:
- Products simples;
- Products con SKUs hijos y precio, stock, imagen, peso, código de barras o IDs externos a nivel de variante;
- opciones del origen que modifican un Product sin crear inventario independiente;
- personalización, carga de archivos, fechas, medidas o elecciones de servicio;
- Products con campos personalizados, metafields, especificaciones enriquecidas o datos de compatibilidad;
- bundles, kits, suscripciones, garantías o configuraciones propiedad de aplicaciones;
- Products con asignaciones distintas entre canales;
- Products sincronizados con sistemas externos de catálogo o inventario.
| Funcionamiento del origen | Decisión de preparación en BigCommerce | Evidencia que debe aportarse |
|---|---|---|
| La elección identifica un artículo vendible independiente | Definir propiedad de Product y variante | IDs padre/hijo, valores de opción, SKU, precio, stock, imágenes e IDs externos |
| La elección modifica el Product pero no tiene stock propio | Definir modificador u otra relación de destino | Tipo de entrada, valores permitidos, efecto en precio/peso y ejemplo de línea de Order |
| El valor describe el Product | Definir campo personalizado, metafield, contenido o propietario de aplicación | Tipo de campo, valores controlados, consumidores de presentación e integración |
| La combinación sigue lógica personalizada | Definir aplicación o propietario personalizado en destino | Ejemplos de reglas, IDs de componentes y evidencia histórica de Orders |
Normalice los nombres y valores de opciones antes de importar. Nombres inconsistentes pueden crear conjuntos de opciones separados y filtros débiles aunque el concepto comercial subyacente sea el mismo.
Preparar Categories, precios, grupos de Customers y canales
La preparación debe tratar descubrimiento y precios como estructuras relacionadas pero independientes.
Para Categories, prepare:
- jerarquía de origen y asignaciones de Products;
- relaciones de marcas y Manufacturers;
- valores de filtros o facetas;
- contenido y metadatos de landing pages;
- Categories internas u obsoletas;
- asignaciones de Categories específicas de canal;
- URLs y prioridades de redirección.
Para precios, prepare evidencia independiente de precios base, precios de oferta, precios por volumen, precios por grupo de Customers, listas de precios, Coupons y precios gobernados por aplicaciones o ERP.
| Relación comercial | Pregunta de preparación | Evidencia lista |
|---|---|---|
| Grupo de Customers | ¿Qué Customers pertenecen y qué significado de acceso o precio tiene el grupo? | Ejemplos de Customers y resumen de reglas del grupo |
| Lista de precios | ¿Qué Products o variantes, monedas, Customers o canales la utilizan? | Exportación de lista de precios y mapa de asignación |
| Precios por volumen | ¿Qué umbrales de cantidad y contextos de comprador se aplican? | Ejemplos de Products con umbrales |
| Asignación de canal | ¿Qué Products y Categories pertenecen a cada canal? | Matriz de catálogo por canal |
| Promoción | ¿La regla sigue vigente, es histórica o está obsoleta? | Responsable de la regla y decisión de mantener/reconstruir/retirar |
No mezcle los precios históricos de Orders con la configuración activa de precios. Los Orders históricos necesitan conservar sus valores registrados; el futuro modelo de precios de BigCommerce requiere reglas y asignaciones preparadas de forma independiente.
Preparar Customers y Orders históricos
Prepare muestras de Customers que incluyan compradores individuales, Orders de invitados, varias direcciones, grupos de Customers, estado fiscal, contexto de empresa o B2B, campos personalizados, preferencias de marketing, fidelización, suscripciones e IDs externos de cuenta.
Prepare muestras de Orders que cubran:
- Orders pagados, pendientes, cancelados, reembolsados y parcialmente reembolsados;
- varios estados de procesamiento y métodos de envío;
- descuentos, Coupons, gift certificates, impuestos, aranceles y ajustes manuales;
- selecciones de variantes y modificadores;
- contexto de grupos de Customers o listas de precios;
- origen en canal o marketplace;
- referencias de ERP, contabilidad, CRM y procesamiento.
| Pregunta de preparación | Evidencia | Condición de preparación |
|---|---|---|
| ¿Cómo se manejan Customers duplicados? | Ejemplos de duplicados y claves de coincidencia | Están documentadas las reglas para mantener separados o combinar registros |
| ¿Qué grupos de Customers se conservan? | Lista de grupos y finalidad comercial | Cada grupo retenido tiene responsable y regla relacionada |
| ¿Qué detalles de Orders necesita ver soporte? | Paquete representativo de Orders | Se explican líneas, modificadores, totales, estados, reembolsos y referencias |
| ¿Qué IDs externos seguirán operativos? | Mapa de claves entre sistemas | Cada clave está asociada al nivel de entidad correcto |
| ¿Qué campos sensibles son innecesarios? | Alcance de campos aprobado | Los datos excluidos están documentados antes de la migración |
Preparar contenido, URLs y entradas para redirecciones
Cree un inventario de rutas para Products, Categories, marcas, CMS Pages, Blog Posts, páginas de campaña, archivos y contenido localizado. Incluya importancia por tráfico, ingresos, backlinks, medios pagados, servicio al Customer o cumplimiento cuando se conozca.
Para cada ruta prioritaria, registre:
- ruta de origen;
- Product, Category, página, Blog Post, canal o destino externo previsto en BigCommerce;
- responsable del contenido;
- requisitos de metadatos y enlaces internos;
- alcance de canal y locale;
- necesidad de redirección o decisión de retirada.
Separe los registros de contenido de la presentación del tema y Page Builder. Una página de origen puede contener contenido reutilizable, referencias de Products, formularios, widgets, scripts y definiciones de diseño que necesiten propietarios distintos en destino.
Inventariar aplicaciones, metafields y sistemas externos
Cree un registro de dependencias para aplicaciones, scripts personalizados, campos personalizados, metafields, webhooks y sistemas conectados. Incluya Reviews, búsqueda, suscripciones, bundles, fidelización, B2B, personalización, impuestos, envíos, pagos, marketplaces, ERP, PIM, WMS, CRM, contabilidad, analítica y sistemas de consentimiento.
Para cada dependencia, documente:
- finalidad comercial;
- registros que crea o modifica;
- Products, Customers, Orders o contenido relacionados;
- propietario de datos actual y futuro;
- evidencia de exportación o API;
- identificadores externos;
- si la dependencia continuará, será sustituida o se retirará.
El registro está listo cuando ningún valor personalizado importante se describe únicamente como “procedente de una aplicación”.
Seleccionar muestras representativas para una migración a BigCommerce
Elija un conjunto compacto que cubra relaciones ordinarias y excepcionales.
| Muestra | Finalidad de preparación |
|---|---|
| Product simple | Establecer el patrón ordinario de Product, Category, medios, precio e inventario |
| Product con muchas variantes | Exponer identidad Product/variante, opciones, stock, imágenes e IDs externos |
| Product impulsado por modificadores | Exponer entradas del comprador que no deben convertirse en variantes con inventario |
| Product con campos personalizados o metafields | Exponer propiedad de datos personalizados estructurados |
| Product con contexto de grupo de Customers o lista de precios | Exponer relaciones comerciales condicionales |
| Product o Category específico de canal | Exponer asignaciones de canal y alcance localizado |
| Customer complejo | Exponer grupos, direcciones, campos personalizados e IDs externos |
| Order histórico complejo | Exponer modificadores, descuentos, procesamiento, reembolsos y contexto de canal |
| Ruta de contenido prioritaria | Exponer preparación de página, metadatos, enlaces internos y redirecciones |
Adjunte IDs de origen, URLs de origen, propietarios previstos en destino, claves externas y exclusiones conocidas a cada muestra. El registro debe definir qué representa el registro de origen, qué relaciones importan y qué evidencia lo acompaña. Incluya al menos un registro ordinario y uno excepcional para cada área operativa principal. Cuando varias estructuras del origen difieran de forma material, utilice muestras separadas en lugar de pedir a un solo Product u Order que represente patrones contradictorios.
Completar el control de preparación para BigCommerce
| Pregunta de preparación | Evidencia requerida | Condición de preparación |
|---|---|---|
| ¿Está completo el acceso? | Registro de accesos | Las áreas necesarias del origen y destino están disponibles |
| ¿Están clasificadas las relaciones de Products? | Matriz de familias de Products y opciones | Variantes, modificadores, campos personalizados y datos de aplicaciones tienen propietarios |
| ¿Están documentadas las relaciones de precios y canales? | Matrices de precios y canales | Asignaciones de grupo, lista, Product, moneda y canal son explícitas |
| ¿Están representados Customers y Orders? | Registro de muestras | Se cubren los patrones importantes de cuentas e historial de Orders |
| ¿Están definidas las rutas prioritarias? | Inventario de URLs | Cada ruta prioritaria tiene un destino o una decisión de retirada |
| ¿Tienen responsable las dependencias? | Registro de aplicaciones e integraciones | Cada dependencia importante tiene un propietario futuro |
| ¿Están actualizadas copias y exportaciones? | Archivo fechado | La evidencia de origen puede recuperarse de forma independiente |
| ¿Están controladas las decisiones abiertas? | Registro de decisiones | Los puntos críticos tienen responsable y fecha límite |
La preparación está completa cuando el equipo puede explicar cómo debería representarse en BigCommerce cada relación de alto valor del origen sin depender de supuestos no documentados. Pueden quedar cuestiones abiertas, pero cada una debe tener responsable, requisito de evidencia y fecha de decisión anterior al trabajo de migración afectado.
Conclusión
La preparación para BigCommerce debe producir un modelo respaldado por evidencia para Products, variantes, modificadores, Categories, precios, grupos de Customers, canales, Customers, Orders, contenido e integraciones. La tarea más importante no es exportar más registros, sino definir qué objeto de BigCommerce será propietario de cada relación y recopilar muestras que revelen la complejidad real.
Un paquete disciplinado proporciona a las pruebas de migración representativa un conjunto de muestras rastreable y responsabilidades claras sobre la preparación.
Preguntas frecuentes
¿Qué debería prepararse antes de exportar un catálogo para BigCommerce?
Defina propiedad de Products y variantes, diferencie modificadores de variantes, documente Categories y canales e identifique relaciones de precios y datos personalizados. La exportación resulta más útil cuando el equipo sabe qué significa cada valor del origen.
¿Por qué deben prepararse por separado grupos de Customers y listas de precios?
Un grupo clasifica Customers, mientras una lista de precios asigna valores comerciales bajo condiciones definidas. Conservar uno sin el otro puede dejar incompleta la segmentación o los precios de Products.
¿Qué Products deben incluirse en el conjunto representativo?
Incluya un Product simple, uno con muchas variantes, uno impulsado por modificadores, uno con datos personalizados, uno con precios condicionales y uno específico de canal. Añada cualquier configuración propia de la plataforma que concentre ingresos o riesgo operativo importante.
¿Debe convertirse toda Category de origen en una Category de BigCommerce?
No. Algunas agrupaciones son enlaces de navegación, filtros, colecciones de campaña, estructuras de marca o clasificaciones internas. Asigne cada agrupación según su finalidad futura.
¿Qué evidencia de Orders conviene preparar?
Prepare Orders con selecciones de variantes y modificadores, descuentos, impuestos, envíos, varios estados, reembolsos y referencias de sistemas externos. Las muestras deben explicar el significado histórico sin definir la configuración futura del proceso de compra.
¿Cuándo está completa la preparación para BigCommerce?
Cuando el acceso funciona, la evidencia de origen está actualizada, Products y relaciones comerciales tienen propietarios de destino, las URLs prioritarias están mapeadas, las dependencias están inventariadas y las muestras representativas están documentadas.