La planificación de una migración a Adobe Commerce no consiste únicamente en comprobar si Products, Customers, Orders, Categories, CMS Pages, Blog Posts y Reviews pueden trasladarse. La cuestión más amplia es si esos registros pueden sostener el modelo operativo empresarial que Adobe Commerce deberá ejecutar después del lanzamiento. La estructura de Products, el alcance de las tiendas, las relaciones entre empresas B2B, los catálogos compartidos, los grupos de Customers, Content Staging, la propiedad del inventario, las URLs y las integraciones cambian la forma en que deben interpretarse los datos de origen.
Una tienda de origen puede mostrar registros aparentemente limpios y aun así carecer de la estructura necesaria para Adobe Commerce. Un Customer puede existir sin autoridad dentro de una empresa. Un Product puede existir sin el conjunto de atributos correcto, asignación de website, relación con SKU secundarios o visibilidad mediante catálogo compartido. Una página puede migrarse pero perder el momento de campaña, la localización o el significado de su ruta. Por ello, la revisión del modelo de datos debe centrarse en el funcionamiento empresarial y no únicamente en la presencia de campos.
El significado de los datos en Adobe Commerce empieza por el funcionamiento empresarial
Adobe Commerce hereda gran parte de la base de datos de la familia Magento, pero la interpretación de la migración cambia porque suele elegirse para operaciones comerciales con mayor gobernanza. Un mismo registro de Product, Customer, Order o página puede tener que participar en estructuras multi-tienda, compras B2B, reglas de aprobación, precios por grupos de Customers, visibilidad mediante catálogos compartidos, integraciones empresariales o contenido programado.
| Área de datos | Interpretación en Adobe Commerce | Implicación para la planificación |
|---|---|---|
| Products | Tipos de producto, SKU secundarios, atributos, conjuntos de atributos, websites, Categories, precios, visibilidad y relaciones de inventario. | El catálogo debe respaldar el funcionamiento comercial empresarial, no solo mostrarse correctamente. |
| Customers | Compradores individuales, grupos de Customers, usuarios de empresa, direcciones, historial de Orders y autoridad de cuenta. | Los datos pueden tener que conservar identidad y contexto de compra. |
| Empresas | Administradores, usuarios, roles, permisos, crédito, cotizaciones, órdenes de compra y estado de aprobación. | Los datos B2B deben definirse antes de tratar Customers como cuentas ordinarias. |
| Catálogos compartidos | Visibilidad y precios específicos por comprador mediante grupos de Customers o asignación de empresas. | La existencia de un Product no implica que todos los compradores deban verlo. |
| Alcance de tienda | Websites, stores, store views, idioma, moneda, contenido, configuración y asignación de catálogo. | Los datos multi-marca, regionales o multilingües no deben aplanarse. |
| Contenido y campañas | CMS Pages, CMS Blocks, actualizaciones programadas, momento de promociones, landing pages y recursos de campaña. | Migrar contenido estático puede no conservar la intención comercial dependiente del tiempo. |
| Inventario | Sources, stocks, criterios de venta, asignación por canal y propiedad externa del stock. | La cantidad debe evaluarse respecto a la estructura de procesamiento de pedidos, no solo por SKU. |
| URLs | URL keys, reescrituras, redirecciones, rutas localizadas, rutas personalizadas y landing pages de alto valor. | La continuidad SEO depende del significado y alcance de la ruta, no solo de trasladar la página. |
La pregunta práctica es si cada registro dispone de suficiente estructura para seguir funcionando dentro de Adobe Commerce. Incluso un registro compatible puede necesitar una relación distinta en destino, una asignación de alcance, una decisión de propiedad o un límite de implementación diferente cuando contiene reglas empresariales.
Los datos de Products dependen del tipo, los atributos y la gobernanza
La migración de Products a Adobe Commerce requiere una interpretación cuidadosa porque sus datos pueden afectar la experiencia de compra, merchandising, filtros, búsqueda, precios, inventario e integraciones. El tipo de Product es la primera capa de significado. Products simples, configurables, agrupados, virtuales, bundle y descargables no funcionan de la misma manera. Un elemento de origen con opciones puede tener que convertirse en un Product configurable con Products simples asociados. Un paquete o kit puede requerir revisión antes de tratarlo como bundle, grouped, tratamiento personalizado o exclusión del alcance estándar.
Los Products configurables son especialmente importantes. El Product principal ofrece al comprador una única experiencia visible, mientras que los Products simples asociados contienen el significado comercial a nivel de SKU. Talla, color, material, tamaño de paquete o especificación técnica pueden afectar identidad de SKU, precio, imagen, inventario y referencias de integraciones. Si estas relaciones se aplanan, el catálogo puede parecer completo mientras fallan compra, procesamiento de pedidos, informes o sincronización con ERP.
Los atributos y conjuntos de atributos añaden otra capa de gobernanza. Los atributos pueden controlar campos visibles, búsqueda, navegación por filtros, comparación, importación/exportación, condiciones de promociones, mantenimiento administrativo e integraciones. Los conjuntos de atributos agrupan familias de Products en plantillas estructuradas. Un campo personalizado del origen no debe convertirse automáticamente en texto descriptivo si gobierna filtros, precios, sincronización con PIM, búsqueda, informes u operaciones posteriores.
| Estructura de Product | Qué debe interpretarse | Por qué importa en Adobe Commerce |
|---|---|---|
| Tipo de Product | Estructura simple, configurable, grouped, bundle, virtual, descargable o con tratamiento personalizado. | El tipo determina cómo el comprador selecciona y compra. |
| Relación con SKU secundarios | Asignación principal-secundario, etiquetas de opciones, imágenes, diferencias de precio, stock e identificadores. | Relaciones rotas pueden dejar Products visibles pero no utilizables comercialmente. |
| Atributos | Campos visibles, buscables, filtrables, entradas de reglas, IDs de integración y campos administrativos. | Las decisiones sobre atributos afectan gobernanza del catálogo y descubrimiento de Products. |
| Conjuntos de atributos | Plantillas por familia de Products y campos requeridos. | Una mala planificación dificulta el mantenimiento posterior. |
| Asignación a Categories | Navegación, merchandising, alcance, visibilidad y comportamiento de URLs. | Un significado incorrecto de Categories puede afectar descubrimiento, SEO y confianza del comprador. |
| Relaciones entre Products | Products relacionados, upsells, cross-sells, accesorios, sustitutos y referencias de compatibilidad. | Perder relaciones puede reducir ventas y perjudicar procesos comerciales. |
El objetivo no es recrear exactamente cada campo de origen. Es conservar el significado comercial del catálogo en una forma que Adobe Commerce pueda operar y gobernar sin convertir el catálogo de destino en un archivo de campos heredados del sistema de origen.
El alcance de la tienda cambia el significado de los registros
El alcance de Adobe Commerce puede modificar el significado de casi cualquier registro migrado. Una plataforma de origen puede representar marcas, regiones, idiomas, portales B2B, canales minoristas, áreas mayoristas y tiendas internacionales mediante Categories, dominios, etiquetas de Customers, markets, plugins o campos personalizados. Adobe Commerce puede requerir que esas diferencias se conviertan en websites, stores, store views, árboles de Categories, grupos de Customers, catálogos compartidos, reglas de configuración o variantes de contenido.
El alcance debe definirse antes del mapeo detallado. El nombre de un Product puede ser global mientras su descripción varía por store view. Una CMS Page puede necesitar versiones localizadas. Un Product puede pertenecer a un website pero no a otro. Una ruta de Categories puede ser válida para una tienda minorista y no para un catálogo B2B privado. Un precio puede depender del grupo de Customers o del acceso a un catálogo compartido, no solo del Product.
Los errores de alcance suelen ser invisibles en los recuentos. Puede migrarse el número esperado de Products, Categories, Customers o páginas mientras una tienda recibe el idioma, precio, Category, visibilidad o contexto de URL equivocados. Por ello, el modelo de destino necesita una asignación explícita para cada marca, región, idioma, website, store, store view, segmento B2B y contexto de catálogo privado importante.
Los datos de Customers pueden incluir identidad individual y autoridad empresarial
En Adobe Commerce, los datos de Customers pueden representar algo más que la identidad de una cuenta individual. Pueden incluir grupos de Customers, relaciones con cuentas de empresa, administradores, usuarios, permisos, cotizaciones, órdenes de compra, crédito de empresa, métodos de pago, reglas de métodos de envío, dirección legal y asignación a catálogos compartidos. Un Customer puede migrarse correctamente como cuenta individual y aun así fallar si el comprador pierde autoridad dentro de su empresa o acceso al catálogo correcto.
La planificación B2B debe separar la identidad de Customer del control de compra. Adobe Commerce asocia cuentas estándar de Customers con cuentas Company, y una Company puede contener administrador, equipos, usuarios, roles, permisos y relaciones de aprobación. Email, dirección e historial de Orders pueden ser suficientes para B2C, pero la continuidad B2B puede requerir identidad de empresa, dirección legal, asignación de administrador, jerarquía organizativa, estado de cuenta, referencias fiscales, contexto de crédito e IDs externos de cuenta.
| Capa de Customer | Qué revisar | Implicación para la migración |
|---|---|---|
| Cuenta individual | Email, nombre, dirección, estado, estrategia de contraseñas y asociación con Orders. | Los compradores necesitan continuidad reconocible de su cuenta. |
| Grupo de Customers | Descuentos, impuestos, catálogo, precios o tratamiento por tienda. | La asignación puede afectar experiencia de compra y precisión de Orders. |
| Cuenta de empresa | Administrador, dirección legal, usuarios de empresa, jerarquía y estado. | La migración B2B debe conservar la estructura empresarial, no solo cuentas individuales. |
| Roles y permisos | Autoridad para comprar, aprobar, cotizar, usar crédito o gestionar usuarios. | La identidad sin permisos correctos puede romper el proceso de compra. |
| IDs externos | ERP, CRM, account IDs o referencias de ventas. | La trazabilidad puede depender de sistemas fuera de Adobe Commerce. |
Los catálogos compartidos representan acceso y precios, no solo Products
Los catálogos compartidos de Adobe Commerce pueden controlar qué Products ve una empresa y qué precios se aplican. Una tienda de origen puede representar este significado de otras formas: listas de precios mayoristas, etiquetas de Customers, grupos de distribuidores, Categories ocultas, listas privadas de Products, precios contractuales, reglas gobernadas por ERP o campos personalizados. Durante la migración, estas estructuras deben reinterpretarse, no copiarse sin más.
La representación de un catálogo compartido debe responder cuatro preguntas: qué empresas tendrán acceso, qué Products pertenecen a cada catálogo, qué precios personalizados se aplican y qué permisos de Categories o reglas de visibilidad deben representarse en Adobe Commerce. Las listas de precios de origen, Categories ocultas, etiquetas de distribuidores y referencias contractuales del ERP son evidencias de la relación prevista; no son automáticamente equivalentes a un catálogo compartido.
Los Orders contienen contexto comercial, B2B y de integración
La migración de Orders a Adobe Commerce debe conservar un historial útil sin sugerir que todo el funcionamiento del proceso de compra del origen pasa a convertirse en funcionamiento activo de Adobe Commerce. Los Orders históricos pueden incluir líneas, Products, cantidades, descuentos, impuestos, envío, facturación, referencias de Customers, estados, referencias de pago, reembolsos, facturas, envíos, credit memos, órdenes de compra, referencias de cotización, contexto de empresa e IDs externos.
En tiendas B2B y empresariales, el historial puede requerir interpretación adicional. Un Order puede pertenecer a una empresa y no solo a un Customer individual. Un descuento histórico puede reflejar precio contractual o de catálogo compartido. Un método de pago puede depender de reglas empresariales. Una orden de compra puede tener significado de aprobación. Para los equipos de soporte, un número de Order del ERP puede ser más importante que el número generado por la tienda.
| Contexto de Order | Qué conservar o clasificar | Por qué importa |
|---|---|---|
| Relación Customer-empresa | Cuenta del comprador, cuenta de empresa, relación como administrador o usuario y grupo asociado. | Soporte necesita entender quién realizó la compra y bajo qué cuenta. |
| Detalle financiero | Subtotal, descuentos, impuestos, envío, reembolsos, credit memos, facturas y referencias de pago. | El historial debe seguir siendo interpretable para atención y conciliación. |
| Contexto de proceso B2B | Cotización, orden de compra, crédito de cuenta, aprobación o referencia contractual. | El significado histórico B2B puede no ser un dato ordinario de Order. |
| Estado del procesamiento del pedido | Envío, procesamiento parcial, cancelación, devolución, referencia de almacén o estado ERP. | Operaciones necesita interpretar qué ocurrió después de la compra. |
| Identificadores externos | ID de Order de ERP, contabilidad, marketplace, oportunidad CRM o referencia de almacén. | La continuidad de integraciones puede depender de identificadores externos. |
El modelo de Orders en destino debe contemplar las relaciones diferentes de Orders B2C, Orders B2B, Orders reembolsados o abonados, descuentos e impuestos, referencias externas y contexto de empresa o grupo de Customers. Estas relaciones determinan si el historial seguirá siendo comprensible después de migrar.
Contenido, campañas y URLs requieren una interpretación separada
La migración de contenido en Adobe Commerce puede incluir CMS Pages, CMS Blocks, contenido de Categories, descripciones de Products, landing pages, Blog Posts cuando proceda, recursos multimedia, metadatos y activos promocionales. En tiendas empresariales, el contenido también puede estar vinculado con calendarios de campañas, tiendas regionales, planificación de merchandising, gobernanza de marca, revisión legal o procesos de aprobación.
Content Staging cambia la forma de interpretar el contenido cuando las actualizaciones programadas son importantes. Adobe Commerce puede programar cambios de Products, Categories, reglas de precios de catálogo y carrito, CMS Pages y CMS Blocks como parte de campañas. Una landing page, banner de Category, promoción o cambio programado de precio puede existir como contenido pero perder su momento comercial si se reduce a un registro estático. El alcance debe distinguir contenido permanente, campañas futuras, cambios programados activos y material de campañas ya finalizadas.
Las URLs requieren una separación similar. URL keys de Products y Categories, rutas CMS, reescrituras, rutas localizadas, redirecciones y rutas de landing pages personalizadas deben revisarse según su valor empresarial. Un recuento de páginas puede ser correcto mientras se pierde la continuidad de páginas de Products de alto valor, accesos B2B, portales de distribuidores, URLs regionales o páginas de campaña.
Los datos gobernados por integraciones deben identificarse antes del mapeo
Los proyectos de Adobe Commerce suelen depender de ERP, PIM, CRM, OMS, WMS, sistemas fiscales, pagos, envíos, marketplaces, fidelización, suscripciones, analítica, búsqueda, personalización o marketing. Estos sistemas pueden gobernar campos e identificadores que no son evidentes al revisar la tienda pública.
Algunos ejemplos son IDs de Products del ERP o PIM, IDs de cuentas de empresa, IDs de distribuidores, IDs de contratos, referencias de listas de precios, códigos de stock de almacén, identificadores de exención fiscal, referencias de cuentas CRM, IDs de marketplace, IDs de suscripción y números externos de Orders. Si se eliminan, renombran o se colocan en campos incompatibles, la tienda puede parecer correcta mientras fallan procesos posteriores.
Los datos gobernados por integraciones deben clasificarse antes de decidir el mapeo final entre origen y destino. Un valor puede pertenecer a un atributo nativo, un campo de extensión, una clave entre sistemas, una carga de datos separada para la integración o una estructura heredada que debe excluirse. La decisión debe seguir al sistema que seguirá gobernando el dato, no al lugar donde casualmente estaba almacenado en el origen.
Las relaciones de Adobe Commerce necesitan resultados de propiedad explícitos
Un modelo de destino completo asigna propiedad y significado a toda la cadena de relaciones. Los registros de Products respaldan la gobernanza del catálogo; Customers y Company accounts conservan autoridad de compra; Orders mantienen un historial utilizable; el contenido conserva el contexto correcto de tienda y campaña; las URLs mantienen la intención de las rutas; y los campos de integración siguen siendo trazables para los sistemas que los utilizan.
Una revisión útil debe preguntar:
- ¿Pueden mantenerse los Products por familia, conjunto de atributos, website y alcance de tienda?
- ¿Pueden los compradores B2B acceder al catálogo, precio, cuenta, cotización, orden de compra y contexto de crédito correctos?
- ¿Puede el equipo de soporte interpretar Orders históricos sin volver al sistema de origen para comprender datos básicos?
- ¿Pueden contenido y URLs respaldar lanzamiento, continuidad SEO y necesidades de campaña?
- ¿Pueden los sistemas externos seguir reconociendo los registros migrados de los que dependen?
Si estas preguntas no pueden responderse a partir del alcance, las relaciones de destino siguen sin estar definidas aunque los registros de origen estén disponibles.
Conclusión
Adobe Commerce cambia la planificación porque los datos suelen contener reglas operativas empresariales. Products no son solo artículos: incluyen tipos de Product, atributos, conjuntos de atributos, websites, store views, Categories, relaciones de inventario y referencias de integraciones. Customers no son solo perfiles: pueden representar empresas, usuarios, administradores, grupos de Customers, compradores de catálogos compartidos y participantes en procesos de aprobación. Contenido, URLs, Orders e inventario pueden depender de alcance, tiempo y sistemas externos.
Una buena migración a Adobe Commerce trata el trabajo sobre el modelo de datos como una representación del significado empresarial. El objetivo es situar los registros en una estructura capaz de respaldar gobernanza del catálogo, compras B2B, alcance de tiendas, continuidad del contenido y propiedad de integraciones.
Preguntas frecuentes
¿Por qué una migración de datos a Adobe Commerce requiere algo más que mapear campos?
Porque muchos registros de Adobe Commerce contienen significado operativo. Products, Customers, Orders, contenido, URLs e inventario pueden afectar compras B2B, catálogos compartidos, alcance de tiendas, gobernanza de atributos y propiedad de integraciones.
¿En qué se diferencian los catálogos compartidos de Adobe Commerce de Categories ordinarias?
Categories organizan navegación y merchandising. Los catálogos compartidos pueden controlar visibilidad y precios específicos por comprador, normalmente en relación con empresas o grupos de Customers. Deben planificarse como lógica de acceso y precios, no solo como estructura de catálogo.
¿Qué hace más complejos los datos de Customers en Adobe Commerce?
Pueden incluir cuentas individuales, grupos de Customers, cuentas de empresa, usuarios, administradores, roles, crédito, permisos de cotización, permisos de órdenes de compra y asignaciones a catálogos compartidos. Un Customer puede migrarse como cuenta y aun así perder significado de compra B2B.
¿Debe tratarse Content Staging como contenido CMS normal?
No. Las actualizaciones de campañas dependientes del tiempo, contenido programado, páginas promocionales y cambios específicos de lanzamiento deben revisarse por separado. Parte del contenido puede migrarse como contenido CMS estable, mientras que el momento y comportamiento de aprobación pueden requerir configuración en Adobe Commerce o reconstrucción manual.
¿Cuándo necesitan los datos de Adobe Commerce un tratamiento separado en destino?
Se necesita tratamiento de migración o implementación separado cuando el alcance incluye datos de extensiones no compatibles, estructuras de base de datos personalizadas, relaciones de empresa o catálogo no estándar, identificadores de sistemas externos o funcionamiento sin un destino nativo en Adobe Commerce.
¿Cómo deben representarse los identificadores externos en Adobe Commerce?
Conserve un identificador externo solo cuando un proceso continuo de ERP, CRM, PIM, procesamiento de pedidos, fiscalidad o informes siga dependiendo de él. Defina si debe quedar en un campo nativo, un campo gestionado por extensión, una referencia de integración o una clave documentada entre sistemas. El objetivo es que el personal y los sistemas conectados puedan rastrear el registro migrado sin mostrar ese identificador como contenido de la tienda ni confundirlo con el ID interno de Adobe Commerce.