Adobe Commerce debe planificarse como un entorno empresarial para operar el comercio electrónico, no simplemente como una tienda más grande dentro de la familia Magento. Una migración a Adobe Commerce puede incluir registros comerciales habituales, como Products, Categories, Customers, Orders, Reviews, Coupons, CMS Pages y Blog Posts, pero la plataforma suele añadir una capa más exigente de gobernanza empresarial: cuentas de empresa, roles de compradores, catálogos compartidos, funcionamiento de las cotizaciones, reglas de órdenes de compra, tiendas con alcances diferenciados, contenido programado, módulos personalizados y dependencias con sistemas externos.
Esta capa empresarial cambia el punto de partida de la planificación. La pregunta no es solo si los registros de origen pueden trasladarse. La cuestión más importante es si los datos migrados podrán respaldar las reglas comerciales, las relaciones con compradores, el alcance de cada tienda, la lógica de precios, las operaciones de contenido y las responsabilidades de integración que la empresa espera después del lanzamiento.
Adobe Commerce comparte una base tecnológica de la familia Magento con Magento Open Source, por lo que siguen siendo relevantes los tipos de producto, atributos, conjuntos de atributos, el alcance por website/store/store view, Categories, URLs y las personalizaciones impulsadas por extensiones. La diferencia es que Adobe Commerce suele añadir expectativas operativas de nivel empresarial sobre esas estructuras. La planificación debe conservar la disciplina de datos propia de Magento y prestar atención adicional al B2B, la gobernanza, la programación, la escala y la responsabilidad organizativa.
Adobe Commerce como plataforma de destino empresarial
Adobe Commerce suele elegirse cuando la tienda de destino necesita un control operativo más sólido que el de un escaparate con catálogo sencillo. La empresa puede necesitar estructuras de cuentas B2B, visibilidad de catálogo similar a acuerdos comerciales, reglas de compra específicas por empresa, múltiples tiendas, contenido localizado, merchandising gobernado, flujos de aprobación más formales e integraciones con ERP, PIM, CRM, sistemas fiscales, almacenes, marketplaces, analítica o herramientas de marketing.
Estos requisitos convierten la migración en un ejercicio de diseño de la estructura del negocio. Los datos de Products, Customers, historial de Orders y contenido siguen siendo importantes, pero deben evaluarse dentro del entorno de Adobe Commerce que los utilizará.
| Área de Adobe Commerce | Relevancia para la migración | Decisión temprana de planificación |
|---|---|---|
| Alcance por website, store y store view | Las tiendas pueden representar regiones, marcas, idiomas, modelos de negocio o contextos de catálogo diferentes. | Definir qué valores serán globales, a nivel de website, store o store view. |
| Tipos de producto y atributos | La estructura de Products puede afectar variantes, filtros, búsqueda, merchandising e integraciones. | Clasificar tipos de producto, atributos y conjuntos de atributos antes de migrar. |
| Cuentas de empresa B2B | Los clientes empresariales pueden tener administradores, usuarios, permisos, crédito, cotizaciones y necesidades de órdenes de compra. | Determinar si los datos de Customers de origen representan cuentas individuales, empresas o relaciones personalizadas. |
| Catálogos compartidos y precios | La visibilidad de Products y los precios pueden variar según el comprador. | Definir si listas de precios, grupos de Customers o precios contractuales requieren mapeo compatible, configuración o revisión de alcance no estándar. |
| Content Staging | Los cambios de merchandising y contenido pueden programarse. | Separar el contenido migrado de la programación de campañas y la gobernanza que se configurarán en destino. |
| Extensiones e integraciones | Las tiendas empresariales suelen depender de módulos y sistemas externos. | Identificar cuanto antes registros de extensiones no compatibles, identificadores externos y procesos personalizados. |
Adobe Commerce puede respaldar operaciones comerciales sofisticadas, pero la calidad de la migración depende de que las estructuras de destino estén definidas antes de la Full Migration. Sin esas decisiones, los datos pueden llegar a Adobe Commerce y aun así no responder al modelo comercial previsto.
La base tecnológica de la familia Magento sigue siendo importante
Adobe Commerce pertenece a la arquitectura de la familia Magento. Por ello, muchas consideraciones de migración de Magento Open Source siguen aplicándose: tipos de producto, atributos, conjuntos de atributos, Categories, jerarquía de tiendas, reescrituras de URLs, grupos de Customers, historial de Orders, supuestos sobre inventario, módulos y campos personalizados.
El error consiste en usar esa relación como motivo para copiar sin cambios la planificación de Magento Open Source. Adobe Commerce añade implicaciones empresariales. Un Product de origen sigue necesitando un tipo correcto dentro del modelo Magento, pero también puede requerir visibilidad específica para determinados compradores o precios mediante catálogos compartidos. Un registro de Customer necesita datos de perfil correctos, pero puede requerir además pertenencia a una empresa, roles de cuenta, permisos de compra o contexto de representante comercial. Una CMS Page puede migrarse, pero el momento de publicación también puede depender de actualizaciones programadas o de la gobernanza de campañas.
Por tanto, esta relación debe utilizarse como un control de límites:
| Preocupación compartida con la familia Magento | Extensión empresarial de Adobe Commerce |
|---|---|
| Products configurables y Products simples asociados | Visibilidad específica por comprador, precios B2B, pedidos basados en cuentas y muestras de validación empresarial. |
| Atributos y conjuntos de atributos | Gobernanza del catálogo entre departamentos, integraciones y propiedad de datos en PIM o ERP. |
| Alcance por website/store/store view | Separación por marca, región, idioma y canales B2B/B2C. |
| Grupos de Customers | Asignación de catálogos compartidos, comportamiento de cuentas de empresa, precios, impuestos y reglas comerciales. |
| Reescrituras de URLs y contenido CMS | Continuidad SEO junto con programación de campañas, contenido planificado y aprobación empresarial del contenido. |
| Extensiones y datos personalizados | Revisión de alcance a medida cuando módulos o sistemas externos son propietarios de registros críticos para el negocio. |
Esta distinción ayuda a mantener el contenido sobre Adobe Commerce preciso. Adobe Commerce no es simplemente “Magento con más funciones”. Es una plataforma de destino en la que el modelo de datos de la familia Magento suele tener que servir a una gobernanza empresarial más compleja.
Alcance de las tiendas y estructura del negocio
Las decisiones de alcance en Adobe Commerce deben tomarse pronto porque pueden cambiar el funcionamiento de los registros migrados. Una empresa puede utilizar websites separados para marcas, países, unidades de negocio, canales B2B y B2C, monedas base, contextos fiscales o separación de cuentas de Customers. Los stores pueden controlar la navegación del catálogo mediante Categories raíz. Los store views suelen utilizarse para idiomas y presentación localizada.
Las tiendas de origen no siempre separan estos conceptos del mismo modo. Una plataforma de origen puede guardar los valores de idioma en un plugin de traducción, las marcas en Categories, precios regionales en campos personalizados, la visibilidad de Customers en una aplicación y permisos B2B en otro sistema. Si esos valores se migran sin un plan de alcance para Adobe Commerce, el resultado puede parecer completo y aun así ser comercialmente incorrecto.
La planificación del alcance debe responder preguntas prácticas:
| Pregunta sobre el alcance | Por qué importa |
|---|---|
| ¿Qué websites existirán en el lanzamiento? | La estructura por website puede afectar la separación de cuentas, el contexto comercial, la moneda y la configuración. |
| ¿Qué stores y Categories raíz respaldarán cada tienda? | La navegación y la organización del catálogo pueden variar por línea de negocio o región. |
| ¿Qué store views necesitan valores localizados? | Los nombres y descripciones de Products, URLs, metadatos, CMS Pages y Blog Posts pueden requerir tratamiento por idioma. |
| ¿Qué valores son globales y cuáles dependen del alcance? | Una herencia incorrecta puede sobrescribir datos localizados o específicos del negocio. |
| ¿Qué estructuras de la plataforma de origen no representan realmente alcances de Adobe Commerce? | Categories, etiquetas, grupos de Customers o campos personalizados pueden interpretarse erróneamente como websites o store views. |
Un plan de migración no debería enviar todos los registros al alcance predeterminado salvo que la empresa haya elegido esa estructura de forma deliberada.
Gobernanza del catálogo y significado de los Products
La gobernanza del catálogo en Adobe Commerce empieza por comprender qué representa cada Product. Los Products simples, configurables, agrupados, bundle, virtuales, descargables y gift card pueden tener implicaciones diferentes para la migración. Los Products configurables son especialmente importantes porque el Product principal visible y sus Products simples asociados deben conservar el significado de SKU, opciones, precio, imágenes e inventario de una forma que compradores y administradores puedan utilizar correctamente.
Los atributos y conjuntos de atributos también requieren gobernanza. Los atributos pueden servir a páginas de Products, búsqueda, navegación por filtros, comparación de Products, promociones, informes o integraciones. En un entorno empresarial, un atributo mal migrado puede generar algo más serio que desorden visual. Puede perjudicar la búsqueda de Products por parte de los compradores, la alineación con PIM, las referencias del ERP, la precisión de las cotizaciones, las exportaciones a marketplaces o el mantenimiento interno.
La planificación del catálogo debe distinguir los datos de presentación de los datos operativos:
| Tipo de campo de origen | Pregunta de planificación en Adobe Commerce |
|---|---|
| Especificaciones de Products | ¿El valor debe mostrarse al cliente, poder buscarse, filtrarse, compararse o ser solo interno? |
| Opciones que generan variantes | ¿El valor debe formar parte de Products configurables u otra estructura de producto? |
| Indicadores de precios o disponibilidad B2B | ¿Corresponden a catálogos compartidos, grupos de Customers, lógica personalizada o sistemas externos? |
| IDs de ERP/PIM/marketplaces | ¿Deben mapearse a campos compatibles, conservarse mediante mapeo o ajustes de configuración compatibles, o requieren tratamiento no estándar? |
| Atributos antiguos o duplicados | ¿Deben limpiarse, combinarse, excluirse o conservarse como referencia histórica? |
La migración a Adobe Commerce no debe maximizar la cantidad de campos transferidos. Debe conservar los campos que respaldan el modelo de gobernanza del catálogo de destino.
Cuentas de empresa B2B y relaciones entre compradores
B2B suele ser la diferencia más clara entre Adobe Commerce y Magento Open Source. Las cuentas de empresa pueden incorporar administradores, usuarios, roles, permisos, crédito de empresa, comportamiento de órdenes de compra, permisos de cotización, restricciones de pago y envío y relaciones con catálogos compartidos. Estas estructuras cambian el significado de la migración de Customers.
Un Customer de origen no equivale necesariamente a una cuenta de empresa. Un grupo de Customers mayoristas no equivale necesariamente a una jerarquía de compradores. Una lista de precios para distribuidores no equivale a un catálogo compartido. Un campo de representante comercial no equivale a una asignación nativa de empresa en Adobe Commerce. Estas diferencias deben revisarse antes de aprobar el alcance de la migración.
Para planificar una migración B2B a Adobe Commerce, prepare ejemplos representativos:
| Ejemplo B2B | Valor para la migración |
|---|---|
| Empresa con un administrador y varios compradores | Permite probar la jerarquía de la cuenta y las relaciones entre usuarios. |
| Empresa asignada a precios o visibilidad de Products específicos | Permite comprobar implicaciones de catálogos compartidos o grupos de Customers. |
| Customer con proceso de cotización u orden de compra | Hace visibles las necesidades de configuración y validación en destino. |
| Empresa con crédito o métodos de pago/envío restringidos | Separa los datos históricos de la configuración comercial activa. |
| Registro B2B de origen controlado por campos personalizados o un CRM/ERP externo | Identifica necesidades de revisión para alcance a medida o integraciones. |
El éxito de una migración B2B no se demuestra con el número de registros de Customers. Se demuestra cuando el comprador puede iniciar sesión, ver el catálogo y los precios correctos, utilizar los permisos previstos y seguir el proceso de compra empresarial después del lanzamiento.
Content Staging, merchandising y momento del lanzamiento
Content Staging de Adobe Commerce puede cambiar la forma en que los equipos planifican el lanzamiento. Products, Categories, reglas de precio del carrito, reglas de precio del catálogo, CMS Pages, CMS Blocks y widgets pueden formar parte de campañas de merchandising o contenido programadas. La migración no debe asumir que transferir el contenido recrea automáticamente la gobernanza de las campañas.
Una tienda de origen puede tener promociones programadas, landing pages estacionales, futuros lanzamientos de Products, banners de campaña o revisiones de contenido gestionadas mediante aplicaciones o procesos editoriales. La planificación debe clasificar esas expectativas. Parte del contenido debe migrarse como registros. Otra parte debe reconstruirse o programarse en Adobe Commerce. Algunos elementos pueden requerir revisión manual porque el proceso de origen no tiene un equivalente directo en destino.
Por ello, la planificación del lanzamiento debe distinguir:
| Elemento de contenido o merchandising | Tratamiento de planificación |
|---|---|
| CMS Pages y Blog Posts ordinarios | Migrarlos cuando sean compatibles y validar contenido, URLs y metadatos. |
| Promociones programadas | Decidir si las reglas migran, necesitan configuración en destino o requieren reconstrucción manual de la campaña. |
| Landing pages estacionales | Validar continuidad de URLs, bloques de contenido, recursos multimedia y momento de publicación. |
| Contenido gestionado por page builders o aplicaciones | Revisar si entra en el alcance compatible, requiere reconstrucción manual o tratamiento no estándar. |
| Gobernanza de campañas | Tratarla como planificación de procesos en destino, no solo como transferencia de datos. |
Content Staging aporta valor cuando la empresa puede utilizarlo de forma intencionada. Se convierte en un riesgo cuando los equipos dan por hecho que la programación del origen se ha trasladado simplemente porque los registros de contenido aparecen en la tienda de destino.
Integraciones y responsabilidad empresarial
Los proyectos de Adobe Commerce suelen depender de sistemas que están fuera de la tienda. El ERP puede ser el sistema que gobierna IDs de Products, cuentas de Customers, facturas o inventario. El PIM puede gobernar atributos y contenido de Products. El CRM puede gobernar relaciones con empresas o asignaciones comerciales. Los sistemas fiscales y de envío pueden decidir parte del proceso de compra. Marketplaces, analítica, fidelización, suscripciones o herramientas de marketing pueden ser propietarios de registros que parecen datos comerciales, pero no son datos nativos de la plataforma.
La planificación debe identificar quién gobierna cada dato antes de decidir cómo tratarlo en la migración. Si la plataforma de origen solo muestra un valor cuyo sistema de referencia está en otro lugar, trasladar ese campo visible puede no conservar el proceso de negocio. Si un módulo creó el dato, la exportación estándar puede no incluirlo. Si una integración personalizada escribe valores en campos privados, esos valores pueden requerir revisión de alcance no estándar o trabajo de implementación separado.
La distinción de planificación es sencilla:
| Requisito | Mejor clasificación |
|---|---|
| Un registro compatible requiere filtrado o ajustes de mapeo | Planificar explícitamente el filtrado o mapeo necesario. |
| Un registro compatible necesita tratamiento sensible a la configuración | Separar el tratamiento de migración de la configuración en destino. |
| Deben conservarse registros gestionados por extensiones o aplicaciones | Requiere revisión de alcance no estándar. |
| Los identificadores de sistemas externos deben seguir siendo operativos | Revisión de alcance a medida o de integración. |
| Una integración activa debe conectarse después de migrar | Trabajo de implementación en destino, no solo migración de datos. |
Adobe Commerce ofrece flexibilidad para respaldar modelos operativos complejos, pero esa flexibilidad solo ayuda cuando la propiedad de los datos y la responsabilidad sobre las integraciones están claramente definidas.
Conclusión
La planificación de una migración a Adobe Commerce debe comenzar por el modelo operativo empresarial que tendrá que respaldar la tienda de destino. Los registros de Products, perfiles de Customers, Orders, Categories, CMS Pages, Blog Posts y URLs siguen siendo importantes, pero son solo una parte del conjunto. El plan también debe contemplar cuentas de empresa B2B, catálogos compartidos, alcance de las tiendas, relaciones entre Products configurables, atributos y conjuntos de atributos, Content Staging, integraciones, módulos personalizados y responsabilidad sobre la validación.
Una buena migración a Adobe Commerce no es la transferencia más amplia posible. Es un traslado controlado a un entorno empresarial de comercio electrónico en el que los registros migrados, la configuración de destino, el alcance de migración aceptado y la validación del negocio permiten mantener el mismo modelo comercial después del lanzamiento.
Preguntas frecuentes
¿En qué se diferencia Adobe Commerce de Magento Open Source al planificar una migración?
Adobe Commerce comparte la base tecnológica de la familia Magento, pero su planificación suele requerir más atención a funciones empresariales como cuentas de empresa B2B, catálogos compartidos, procesos de cotización y órdenes de compra, Content Staging, gobernanza e integraciones.
¿Todas las migraciones a Adobe Commerce requieren planificación B2B?
No. Algunas tiendas Adobe Commerce son principalmente B2C o están centradas en contenido. La planificación B2B adquiere importancia cuando el negocio de origen utiliza cuentas de empresa, compradores mayoristas, precios para distribuidores, compra asistida por ventas, procesos de cotización o acceso al catálogo específico por cuenta.
¿Por qué es importante el alcance de las tiendas en una migración a Adobe Commerce?
El alcance por website, store y store view puede afectar la asignación del catálogo, el contenido localizado, las URLs, la moneda, la configuración y el contexto del comprador. Migrar datos al alcance equivocado puede hacer que la tienda parezca completa, pero funcione de forma incorrecta.
¿Cómo deben tratarse los datos personalizados de Adobe Commerce?
El mapeo compatible o los ajustes de configuración pueden resolver necesidades acotadas de filtrado, mapeo o configuración. Los datos de extensiones no compatibles, campos personalizados, identificadores de sistemas externos, transformaciones específicas y lógica B2B o de integración compleja requieren revisión de alcance no estándar.
¿Qué conviene validar primero después de una prueba representativa en Adobe Commerce?
Empiece por ejemplos representativos de catálogo, alcance, Customers, empresas, catálogos compartidos, URLs y elementos sensibles a integraciones. El objetivo es demostrar que los registros respaldan el funcionamiento esperado de Adobe Commerce, no solo que coinciden los recuentos.