Las migraciones a Adobe Commerce fallan con mayor frecuencia cuando los registros transferidos quedan separados de las relaciones empresariales que determinan quién puede comprar, qué puede ver, qué precio se aplica, desde dónde se procesa el pedido y cuándo se activa el contenido. Un Product puede existir en Admin y seguir siendo comercialmente incorrecto porque pertenece al website equivocado, carece de sus Products configurables secundarios, está excluido del catálogo compartido correspondiente o no conserva una relación utilizable entre source y stock.
Por eso, los errores más dañinos no son simples omisiones de registros. Son fallos de relaciones que parecen completos durante una revisión superficial. La prevención exige que cada regla empresarial tenga un propietario claro en Adobe Commerce, un escenario representativo y una condición de aprobación concreta.
Error 1: convertir cuentas Company en registros de Customers sin relación
Qué sale mal
Las cuentas Company B2B de Adobe Commerce pueden contener administradores, equipos, usuarios, roles, permisos, direcciones, expectativas de pago y relaciones de compra. Una migración que importa solo Customers individuales conserva datos de contacto, pero elimina la organización que gobierna a esos compradores.
La tienda puede mostrar todas las direcciones de email esperadas mientras los administradores Company no pueden gestionar usuarios, compradores asistentes reciben permisos excesivos y Orders dejan de estar asociados con la cuenta empresarial correcta.
Señales tempranas
| Señal temprana | Qué indica |
|---|---|
| Empresas, divisiones, equipos y usuarios se exportan como una única lista de Customers. | La jerarquía B2B se está aplanando en cuentas individuales sin relación. |
| Roles de administradores y compradores solo existen como etiquetas de texto libre. | Permisos y responsabilidad de aprobación no podrán reconstruirse con fiabilidad. |
| Varios compradores comparten precios o direcciones de empresa, pero no existe un identificador Company estable. | El contexto comercial compartido se fragmentará entre Customers. |
| El origen depende de aprobaciones, crédito o restricciones de pago fuera del registro de Customer. | Un funcionamiento B2B crítico carece de propietario en destino. |
Prevención
Modele Company como la entidad empresarial principal. Conserve identificador Company, administrador, usuarios subordinados, equipos, asignaciones de roles, direcciones, relación con grupo de Customers y la clave externa utilizada por CRM o ERP. No deduzca la pertenencia a empresa únicamente por dominio de email o similitud de direcciones.
Ejemplo de recomendación
Use como patrón una empresa con administrador, comprador sénior y comprador restringido. Represente por separado la pertenencia y rol de cada usuario y conserve la cuenta compartida y el identificador externo de Company.
Condición de aprobación
La empresa representativa aparece una sola vez, contiene usuarios y equipos correctos, asigna permisos previstos a cada rol y sigue vinculada al grupo de Customers, direcciones y clave externa correctos.
Error 2: asignar catálogos compartidos sin conservar precios específicos por empresa
Qué sale mal
Los catálogos compartidos pueden controlar selección de Products y precios personalizados para cuentas Company. Importar Products y empresas sin conservar esa relación puede exponer Products restringidos públicamente, ocultar Products contratados a compradores autorizados o sustituir precios negociados por precios generales.
El error se detecta con dificultad porque el catálogo principal puede parecer completo en Admin mientras la visibilidad pública cambia según Company.
Señales tempranas
- El mismo SKU tiene precios distintos para diferentes Companies o grupos de Customers.
- Products privados están incluidos en la exportación general.
- Contratos o registros ERP definen precios que no están almacenados en el Product de origen.
- Asignación de Company y asignación de catálogo se mantienen en sistemas de origen diferentes.
Prevención
Cree una relación explícita entre Company, catálogo compartido, selección de Products, precio personalizado, alcance de website y grupo de Customers. Mantenga separado el catálogo público de los catálogos específicos por empresa y conserve cualquier identificador externo de contrato que explique la fuente del precio.
Ejemplo de recomendación
Use un SKU público, un SKU restringido y uno con precio contractual. Represente cómo aparece cada uno para un invitado, un Customer general y dos Companies con catálogos compartidos diferentes.
Condición de aprobación
Cada comprador representativo ve únicamente los Products y precios previstos, mientras usuarios fuera de la Company asignada no pueden acceder a Products restringidos ni valores negociados mediante Categories, búsqueda, URLs directas, carrito o proceso de compra.
Error 3: recrear compradores y perder cotizaciones, órdenes de compra y relaciones de aprobación
Qué sale mal
Las compras B2B en Adobe Commerce pueden incluir negotiable quotes, órdenes de compra, reglas de aprobación, requisition lists y acceso por roles. Estos registros no son Orders ordinarios ni wish lists. Aplanarlos como notas genéricas elimina estado, propietario, recorrido de aprobación, historial de líneas y relación con Company.
Un comprador puede conservar historial de Orders y perder al mismo tiempo una cotización abierta, una orden de compra pendiente o la requisition list usada para compras recurrentes.
Señales tempranas
| Señal temprana | Qué indica |
|---|---|
| Cotizaciones y órdenes de compra se exportan junto con Orders pero usan IDs o estados distintos. | Procesos de compra diferentes se están mezclando con historial de Orders completados. |
| Límites de aprobación existen en políticas o un sistema externo de compras. | Las reglas de control están fuera del conjunto de registros migrados. |
| Requisition lists contienen conjuntos recurrentes de SKU pero se tratan como wish lists. | Una necesidad operativa de compra se está confundiendo con una preferencia de merchandising. |
| Comentarios, revisiones, vencimiento o descuentos negociados de cotizaciones no tienen propietario previsto. | El historial de negociación comercial quedará incompleto. |
Prevención
Clasifique cada proceso B2B por separado. Conserve Company, creador, aprobador, estado, líneas, cantidades, ajustes negociados, comentarios, fechas y referencias externas cuando el proceso de destino necesite continuidad. Los registros históricos que no puedan seguir activos deben conservar suficiente contexto para que personal y compradores entiendan su estado.
Ejemplo de recomendación
Seleccione una cotización negociable abierta, una orden de compra aprobada, una pendiente de aprobación y una requisition list. Defina propietario en destino e historial conservado para cada tipo.
Condición de aprobación
El destino distingue cotizaciones, órdenes de compra, relaciones de aprobación, requisition lists y Orders completados; cada registro representativo sigue vinculado a Company y usuario correctos con estado e historial de líneas comprensibles.
Error 4: aplanar el alcance entre websites, stores y store views
Qué sale mal
Adobe Commerce utiliza una jerarquía de websites, stores y store views. El alcance puede afectar asignación de Products, Categories raíz, texto localizado, URLs, configuración, monedas y contexto comercial B2B. Una importación global puede sobrescribir valores regionales o por idioma y colocar Products o contenido en la tienda equivocada.
El store view predeterminado puede verse correcto mientras otro idioma, marca o región muestra texto de fallback, Products ausentes o rutas equivocadas.
Señales tempranas
- Products o Categories varían por website o marca.
- Nombres, descripciones, metadatos y URL keys cambian por store view.
- Cada store usa una Category raíz o menú diferente.
- Customers, catálogos compartidos, monedas o contenido están ligados a websites concretos.
Prevención
Mapee la jerarquía de tiendas de origen a la propiedad website, store y store view de Adobe Commerce antes de asignar valores. Separe atributos globales de precios por website y contenido por store view. Conserve códigos de alcance del origen cuando integraciones o importaciones dependan de ellos.
Ejemplo de recomendación
Use un Product configurable y una CMS Page con texto, URL keys y visibilidad diferentes en dos store views y dos websites. Documente qué valores son globales y cuáles tienen alcance.
Condición de aprobación
Cada website, store y store view representativo muestra la asignación de Product, Category raíz, contenido localizado, URLs y contexto comercial previstos sin filtrar valores de otro alcance.
Error 5: reducir tipos de Product complejos a Products planos
Qué sale mal
Adobe Commerce admite Products simples, configurables, grouped, virtuales, bundle, descargables y gift card. Estos tipos utilizan relaciones diferentes de principal-secundario, inventario, precio, peso, archivos y carrito. Aplanarlos como Products ordinarios puede duplicar SKU, eliminar combinaciones seleccionables, romper composición de bundles o desvincular archivos descargables.
Un Product puede parecer completo y dejar de funcionar como la oferta que los clientes compraban en el origen.
Señales tempranas
- SKU principales y secundarios no están identificados por separado.
- Componentes de bundles o grouped Products aparecen como texto en descripciones.
- Enlaces de descarga y límites de acceso se gestionan fuera de la exportación de Products.
- Custom options se mezclan con atributos configurables.
Prevención
Clasifique el tipo de Product antes de mapear campos. Conserve asociaciones principal-secundario configurables, atributos de variación, opciones de bundle, enlaces grouped, archivos descargables, significado de envío de Products virtuales e interpretación de líneas de Order. No cree variantes a partir de atributos descriptivos que no identifican unidades vendibles independientes.
Ejemplo de recomendación
Use un Product configurable con stock diferente entre secundarios, un bundle con precio dinámico, un Product grouped y un Product descargable. Conserve la composición y el significado de procesamiento del pedido propios de cada uno.
Condición de aprobación
Cada Product representativo conserva estructura principal-secundario o componentes, valores seleccionables, identidad de SKU, fuente de precio, funcionamiento de stock, media y significado en líneas de Order.
Error 6: importar contenido de campañas sin su calendario de Staging
Qué sale mal
Content Staging de Adobe Commerce puede programar actualizaciones de Products, Categories, reglas de precio de catálogo y carrito y CMS Pages mediante campañas. Importar solo los valores visibles actualmente puede eliminar campañas futuras, contenido base, agrupación de campañas, ventanas de tiempo y reversión automática tras la fecha de fin.
Una promoción futura puede no aparecer nunca o el contenido de campaña puede permanecer activo de forma permanente porque su calendario se redujo a campos estáticos.
Señales tempranas
| Señal temprana | Qué indica |
|---|---|
| El origen contiene cambios programados de Products, precios, Categories, reglas o CMS. | Los valores actuales no representan todo el plan de campaña. |
| Marketing depende de un calendario de Staging o nombres de campañas. | El momento y la activación coordinada forman parte del significado empresarial. |
| Varias entidades cambian juntas en el mismo lanzamiento. | Importar un solo registro no puede conservar la relación de campaña. |
| El contenido activo difiere de la versión base almacenada. | La migración puede capturar el estado temporal equivocado. |
Prevención
Inventarie valores base, actualizaciones programadas, pertenencia a campañas, horas de inicio y fin, supuestos de zona horaria y store views afectados. Decida qué campañas siguen siendo relevantes y cuáles deben reconstruirse como registros actuales de Content Staging en lugar de importarse como contenido estático.
Ejemplo de recomendación
Use una campaña que cambie al mismo tiempo precio de Product, contenido de Category y una landing CMS. Conserve por separado valores base y ventana de campaña.
Condición de aprobación
La campaña representativa tiene entidades, contenido base, calendario, contexto de store view y comportamiento de reversión correctos; ninguna actualización futura se convierte silenciosamente en datos activos permanentes.
Error 7: copiar cantidades sin reconstruir sources, stocks y relaciones con canales de venta
Qué sale mal
El inventario de Adobe Commerce separa sources físicas de stocks que agregan sources para canales de venta. Una cantidad sin source, stock, website, estado y contexto vendible puede situar inventario en el almacén incorrecto o hacer que un Product no esté disponible pese a tener una cantidad positiva.
Las tiendas multi-source son especialmente vulnerables cuando todas las ubicaciones se suman en Default Source.
Señales tempranas
- Cantidades de almacén, tienda, proveedor drop-ship o punto de recogida existen por separado.
- El origen utiliza asignaciones, reservas o disponibilidad específica por canal.
- Products importados terminan en una sola source aunque varias ubicaciones procesan Orders.
- Products secundarios configurables tienen cobertura distinta por ubicación.
Prevención
Conserve identidad de source, source code, cantidad por source, asignación a stock, relación con website, estado y clave externa de almacén. Distinga cantidad disponible físicamente del valor que puede venderse a través de un canal determinado. Defina qué sistema seguirá siendo la autoridad después de migrar.
Ejemplo de recomendación
Use un SKU presente en dos almacenes y un Product configurable cuyos secundarios están disponibles desde sources diferentes. Asigne cada source al stock que sirve al website previsto.
Condición de aprobación
Los Products representativos muestran cantidades por source, asignaciones de stock y website, disponibilidad vendible y propiedad de procesamiento del pedido correctas sin combinar ubicaciones distintas en un total sin explicación.
Error 8: tratar reescrituras de URLs y contenido con alcance como slugs simples
Qué sale mal
Adobe Commerce puede mantener reescrituras de URL para Products, Categories y CMS Pages. Las rutas pueden variar por website o store view, y el contenido puede contener enlaces internos, rutas de media, estructuras de Page Builder o referencias de campañas. Copiar solo el slug actual puede eliminar historial de redirecciones y romper recorridos de alto valor.
Señales tempranas
- El origen contiene varias URLs históricas para una entidad.
- URL keys de Products o Categories varían por store view.
- El contenido CMS contiene URLs o rutas de media del origen escritas directamente.
- Campañas, medios de pago o enlaces de partners dependen de rutas antiguas.
Prevención
Trate cada ruta de origen como una relación entre ruta anterior, entidad de destino, alcance, tipo de redirección y ruta canónica prevista. Reescriba enlaces internos y referencias de media de acuerdo con el propietario de destino. Mantenga separados contenido CMS, layout de Page Builder e historial de URLs.
Ejemplo de recomendación
Use un Product cuya URL se haya renombrado, una Category que haya cambiado de jerarquía y una CMS Page localizada. Conserve el destino canónico y todas las rutas de origen críticas para el negocio.
Condición de aprobación
Cada ruta heredada representativa llega al destino previsto dentro del alcance correcto, enlaces internos y media resuelven correctamente y ningún contenido restringido o localizado redirige al website o store view equivocados.
Error 9: conservar totales de Orders y perder contexto de empresa y procesamiento del pedido
Qué sale mal
Los Orders históricos pueden conservar totales y perder propiedad Company, rol del comprador, contexto de catálogo compartido, procedencia de cotización u orden de compra, elementos de origen, envíos, facturas, reembolsos e identificadores externos de transacciones. El personal termina viendo un registro financiero sin suficiente evidencia para atender al comprador o conciliar la operación.
Señales tempranas
- Orders B2B se vinculan solo con Customers individuales.
- Las líneas de Order no pueden identificar el Product secundario configurable o componente de bundle original.
- Envíos y reembolsos se almacenan por separado de la exportación de Orders.
- Referencias ERP o de pagos solo existen en tablas de extensiones.
Prevención
Conserve encabezado de Order, identidad Company y comprador, direcciones, snapshots de líneas, opciones seleccionadas, precios, descuentos, impuestos, referencia de catálogo compartido o cotización, facturas, envíos, reembolsos, comentarios e IDs externos. Mantenga los snapshots históricos independientes de la configuración actual de Products y Companies.
Ejemplo de recomendación
Use un Order Company creado a partir de una cotización, uno parcialmente enviado y uno reembolsado que contenga un Product configurable. Rastree cada registro relacionado hasta su Order.
Condición de aprobación
Cada Order representativo sigue siendo comprensible para atención a Customers, finanzas y operaciones, conservando contexto de Company, comprador, Product, pago, envío, reembolso y sistema externo.
Error 10: copiar campos de extensiones e integraciones sin la lógica que los gobierna
Qué sale mal
Las instalaciones de Adobe Commerce suelen contener módulos, atributos personalizados, tablas personalizadas, APIs, event observers, identificadores ERP/PIM, registros de marketplaces, integraciones fiscales, datos de procesamiento de pedidos y campos específicos del proceso de compra. Copiar valores a campos genéricos no conserva el proceso que los crea, actualiza o consume.
El destino puede contener los datos mientras todos los sistemas conectados los consideran ausentes u obsoletos.
Señales tempranas
| Señal temprana | Qué indica |
|---|---|
| Valores importantes tienen prefijos de módulos o viven en tablas personalizadas. | Probablemente pertenecen a lógica de extensión y no a una entidad estándar. |
| Sistemas externos identifican Products, Companies, Customers u Orders mediante claves no estándar. | La continuidad entre sistemas depende de identificadores fuera de campos predeterminados. |
| Los valores válidos de un campo se imponen mediante código y no mediante estructura de base de datos. | Copiar solo el valor no conserva sus reglas. |
| El personal no puede explicar qué sistema gobierna el campo. | Un conflicto de propiedad puede hacer que el valor se sobrescriba o ignore. |
Prevención
Cree un registro de propiedad para cada registro de extensión e integración. Identifique entidad principal, tabla o API de origen, clave externa, sistema de referencia, dirección de actualización y propietario en destino. Excluya residuos técnicos obsoletos en lugar de convertirlos en campos personalizados permanentes.
Ejemplo de recomendación
Rastree un Product desde PIM a Adobe Commerce, una Company desde CRM y un Order hacia ERP y procesamiento del pedido. Registre los identificadores y límites de propiedad necesarios en cada paso.
Condición de aprobación
Cada valor personalizado o de integración conservado tiene propietario de destino, relación principal estable, sistema de referencia e identificador entre sistemas utilizable; ningún proceso esencial depende de un campo huérfano.
Prioridades de prevención comunes a varios errores
La prevención en Adobe Commerce debe conservar cinco capas conectadas: identidad Company, reglas comerciales específicas por comprador, datos con alcance de tienda, relaciones de Products e inventario y propiedad de sistemas externos. Corregir una capa no debe romper silenciosamente otra. Por ejemplo, reconstruir un catálogo compartido también afecta asignación Company, permisos de Categories, indexación de precios y acceso desde la tienda.
| Capa de prevención | Control requerido |
|---|---|
| Identidad de Company y comprador | Mantener conectadas relaciones Company, ubicación, rol, aprobación y Customer. |
| Asignación comercial | Conservar juntos catálogo compartido, asignación Company, precio de variante y contexto de reglas de compra. |
| Datos con alcance de tienda | Mantener propiedad website, store y store view para Products, contenido, URLs y Customers. |
| Contenido temporal | Separar estado activo de versiones de campañas programadas y cambios coordinados. |
| Propiedad externa | Asignar campos de extensiones, tablas personalizadas e identificadores externos a un sistema de referencia. |
Conclusión
Las migraciones a Adobe Commerce dejan de ser fiables cuando las relaciones empresariales se reducen a campos ordinarios de comercio electrónico. Companies, roles, catálogos compartidos, cotizaciones, órdenes de compra, valores con alcance, campañas de contenido, sources de inventario, Orders históricos, reescrituras de URLs e identificadores de integraciones necesitan un propietario claro.
El modelo más seguro trata cada error como una relación rota y no como una fila ausente. Cuando entidades principales, reglas comerciales, alcances, historiales y claves externas permanecen conectados, la tienda migrada puede respaldar los procesos empresariales para los que esos registros fueron creados.
Preguntas frecuentes
¿Por qué los usuarios Company de Adobe Commerce no equivalen a Customers ordinarios?
Porque heredan contexto empresarial de la cuenta Company, incluidos roles, permisos, catálogos compartidos y procesos de compra. Un registro individual de Customer no conserva estas relaciones organizativas.
¿Pueden migrarse precios de catálogos compartidos como precios ordinarios de Products?
No de forma segura. Estos precios pertenecen a relaciones concretas entre catálogo y Company. Moverlos a precios generales puede exponer valores negociados a compradores no previstos o eliminarlos de las Companies que deberían recibirlos.
¿Por qué deben conservarse por separado website, store y store view?
La jerarquía puede controlar asignación de Products, Categories raíz, valores localizados, URLs, configuración y contexto comercial. Un valor global puede sobrescribir o exponer información que estaba intencionadamente limitada a un alcance.
¿Qué diferencia Content Staging del contenido CMS normal?
Content Staging conserva valores base, actualizaciones programadas, agrupación de campañas, calendario y comportamiento de reversión. El valor visible en un momento concreto representa solo un punto de esa línea temporal.
¿Por qué una cantidad de source no basta para describir el inventario de Adobe Commerce?
El significado del inventario depende de la source física, el stock que agrega sources, el canal de venta o website, el estado y el sistema que seguirá siendo la autoridad. Una cantidad por sí sola no indica dónde ni cómo puede procesarse el pedido.
¿Cómo deben tratarse los datos de Adobe Commerce gobernados por extensiones?
Identifique el módulo o sistema externo, la entidad principal que amplía, el identificador estable y el proceso que consume el valor. Conserve solo registros con propietario de destino y uso empresarial continuo definidos.