Elegir el enfoque de migración adecuado para Adobe Commerce requiere una decisión basada en el modelo operativo, no solo en el número de registros. Adobe Commerce puede combinar Products configurables, varios websites, stores y store views, cuentas Company B2B, catálogos compartidos, precios específicos por empresa, grupos de Customers, contenido programado, atributos personalizados, integraciones y registros gestionados por extensiones. El servicio elegido debe reflejar qué estructuras son datos ordinarios compatibles, cuáles requieren configuración en destino, cuáles pueden resolverse mediante Add-ons acotados y cuáles necesitan una revisión a medida mediante Custom Service.
Un proyecto grande de Adobe Commerce no requiere automáticamente el servicio más complejo. Standard Service puede seguir siendo adecuado cuando la ruta de migración es compatible, los registros de origen utilizan estructuras reconocibles y el cliente puede operar y validar el servicio de forma independiente. Managed Service aporta valor cuando la coordinación y la carga de validación son elevadas. Los Add-ons resuelven necesidades específicas y compatibles de filtrado de registros, transformación de valores o remapeo de campos. Custom Service es la vía correcta cuando el resultado depende de registros no compatibles, módulos personalizados, transformaciones específicas, estructuras B2B no estándar, identificadores de sistemas externos o lógica de migración personalizada.
Dentro de los Next-Cart Migration Services, estas evidencias permiten distinguir alcance compatible, responsabilidad de ejecución, necesidades acotadas de Add-ons y requisitos de Adobe Commerce que requieren tratamiento a medida.
Empezar por el modelo operativo de Adobe Commerce
Los proyectos de Adobe Commerce deben clasificarse según el modelo operativo que la plataforma de destino tendrá que respaldar. Una tienda B2C de una sola marca, con un website y Products convencionales, plantea una decisión diferente a una implementación empresarial con varios websites, store views regionales, cuentas Company, catálogos compartidos, precios específicos por comprador y sistemas ERP o PIM estrechamente conectados.
Adobe Commerce utiliza una jerarquía website, store y store view. Los websites pueden tener dominios y alcance de proceso de compra distintos. Los stores pueden usar Categories raíz y catálogos separados. Los store views suelen admitir diferencias de idioma o presentación. Los catálogos compartidos B2B pueden controlar qué Products y precios son visibles para empresas asignadas. Estas estructuras forman parte de la arquitectura de destino, no son simples etiquetas añadidas a los registros migrados.
| Pregunta sobre el modelo operativo | Señal de menor complejidad | Señal de mayor complejidad |
|---|---|---|
| Alcance de websites y stores | Un website, un store y pocos store views | Varios websites, stores regionales, Categories raíz distintas, dominios separados o configuración específica por alcance |
| Estructura de catálogo | Products simples y configurables con atributos reconocibles | Bundles, Products grouped, tipos personalizados, conjuntos de atributos complejos, contenido programado o relaciones creadas por extensiones |
| Modelo de Customers | Customers y grupos de Customers ordinarios | Companies, usuarios Company, catálogos compartidos, precios negociados, permisos, crédito o procesos de aprobación |
| Propiedad de integraciones | Pocas referencias externas | ERP, PIM, OMS, WMS, CRM, marketplaces, sistemas fiscales, pagos o procesamiento de pedidos que controlan valores críticos |
| Personalización | Campos estándar y registros compatibles | Módulos personalizados, columnas de base de datos, tablas de extensiones, APIs personalizadas, procesos específicos o identificadores de sistemas externos |
El enfoque debe seleccionarse después de documentar este modelo. De lo contrario, un proyecto puede definirse como una transferencia estándar de catálogo cuando el negocio en realidad espera que estructuras empresariales B2B y multi-sitio queden operativas automáticamente.
Cuándo Standard Service puede ser la opción adecuada
Standard Service es adecuado cuando la ruta entre la plataforma de origen y Adobe Commerce es compatible, los datos son accesibles mediante el método de conexión admitido y el resultado esperado encaja en el funcionamiento estándar de la migración. Con este servicio de Next-Cart, el cliente sigue siendo responsable de preparación, datos de conexión, decisiones de configuración, ejecución y validación.
Un buen candidato para Standard Service suele tener:
- un alcance claro de Products, Customers, Orders y contenido;
- tipos de Product y relaciones de variantes reconocibles;
- SKU e identificadores de Products consistentes;
- Categories, atributos y valores de atributos comprensibles;
- Customers y direcciones ordinarios;
- Orders históricos que no dependan de contexto oculto de sistemas externos;
- un destino definido por website, store y store view;
- ninguna expectativa de que extensiones, módulos B2B o integraciones se reconstruyan mediante la migración estándar de registros;
- un equipo capaz de revisar en detalle los resultados de Demo Migration y Full Migration.
Standard Service no debe descartarse solo porque el catálogo sea grande. El volumen se gestiona mediante el Entity Points Plan seleccionado. La pregunta más importante es si los registros permanecen dentro de estructuras compatibles y si el cliente puede validar el resultado de forma independiente.
El servicio pierde adecuación cuando Products dependen de tipos personalizados, los precios de empresa se almacenan fuera de estructuras B2B reconocibles, identificadores externos controlan el procesamiento de pedidos o la empresa espera que configuración y módulos de destino se implementen automáticamente a partir de la transferencia de datos.
Cuándo Managed Service resulta más seguro
Managed Service es apropiado cuando la migración sigue estando en gran medida dentro del funcionamiento compatible, pero el cliente necesita que especialistas de Next-Cart se encarguen de la ejecución y aporten coordinación estructurada. Esto puede reducir presión operativa en proyectos con catálogos grandes, múltiples equipos, ventanas de lanzamiento estrictas o una responsabilidad de validación considerable.
Managed Service suele ser más seguro cuando:
- el volumen de catálogo, Customers y Orders genera una carga elevada de revisión;
- varios websites, stores o store views deben ser validados por distintos responsables;
- los equipos necesitan un calendario de migración coordinado;
- partes interesadas B2B, regionales o de canales deben aprobar muestras representativas;
- los datos de origen son comprensibles, pero tienen inconsistencias que requieren una revisión operativa cuidadosa;
- la empresa no puede gestionar con seguridad configuración y ejecución por sí sola;
- la ventana de lanzamiento exige seguimiento controlado de incidencias y escalado.
Managed Service no amplía automáticamente el soporte estándar de la plataforma. Cambia quién gestiona ejecución y coordinación. Si el resultado requiere estructuras Company no compatibles, datos de módulos personalizados, transformaciones específicas o relaciones externas no estándar, puede seguir siendo necesario Custom Service para esas necesidades.
Una regla útil es separar carga de ejecución de carga de personalización. Managed Service aborda la primera. Custom Service aborda la segunda. Algunos proyectos empresariales necesitan ejecución gestionada y, por separado, personalizaciones definidas en alcance.
Dónde encajan los Add-ons
Los Add-ons son adecuados cuando la migración principal sigue siendo estándar, pero una necesidad compatible y acotada cambia el resultado deseado. En Adobe Commerce, los controles relevantes son filtrado de registros mediante condiciones sobre campos de cada tipo de datos, transformación de valores mediante expresiones y remapeo de campos de origen.
Algunos ejemplos en Adobe Commerce son:
- aplicar condiciones sobre campos de Products para excluir Products inactivos u obsoletos;
- aplicar condiciones sobre campos de Customers u Orders para excluir Customers de prueba u Orders históricos irrelevantes;
- utilizar expresiones para transformar valores de campos compatibles durante la migración;
- remapear campos estándar compatibles de Products, Categories, Customers u Orders hacia campos compatibles de destino manteniendo el valor sin cambios;
- conservar información seleccionada de contenido o SEO cuando la ruta de migración lo admita;
- utilizar Data Filter, Advanced Data Mapping o Data Transformation para una necesidad compatible y definida.
Los Add-ons no deben utilizarse como una etiqueta general para cualquier requisito complejo de Adobe Commerce. Remapear un campo compatible es distinto de extraer registros desde un módulo B2B personalizado. Filtrar Orders antiguos con una condición sobre un campo de Order es distinto de reconstruir un proceso de aprobación de empresa. El primer caso puede encajar en un Add-on; el segundo requiere revisión mediante Custom Service o una implementación separada en destino.
El límite correcto es si la necesidad permanece dentro del funcionamiento compatible de la migración. Si es así, un Add-on puede ser suficiente. Si requiere extracción, transformación, lógica o interpretación de propiedad no estándar, corresponde revisarla dentro de Custom Service.
Cuándo debe considerarse Custom Service
Custom Service debe considerarse cuando el resultado requerido no puede obtenerse únicamente con registros compatibles estándar y Add-ons acotados. En Adobe Commerce, esta presión suele aparecer por su ecosistema de extensiones, estructuras B2B, alcance multi-sitio y dependencias de sistemas externos.
Señales habituales de escalado:
- tipos de Product o relaciones personalizadas creadas por módulos;
- atributos personalizados que necesitan una transformación específica en destino;
- cuentas Company, usuarios Company, catálogos compartidos o precios negociados almacenados en estructuras no estándar;
- campos personalizados del proceso de compra o datos de Orders guardados en tablas de extensiones;
- identificadores de ERP, PIM, OMS, WMS, CRM, sistemas fiscales o procesamiento de pedidos que deben conservarse en un campo específico de destino;
- reglas personalizadas de asignación website/store/store view;
- registros no compatibles de módulos de marketplace, suscripciones, fidelización, cotizaciones, aprobaciones o devoluciones;
- columnas de base de datos personalizadas, APIs o tablas de integración;
- una Custom Platform en cualquiera de los dos extremos de la ruta de migración;
- requisitos que cambian la lógica estándar de migración.
Custom Service no incluye automáticamente desarrollo de módulos para Adobe Commerce, instalación de extensiones, configuración B2B, creación de catálogos compartidos, construcción de websites o store views, implementación de temas, configuración de pagos o envíos, despliegue de integraciones ni reconstrucción completa de la tienda de destino. Estas responsabilidades solo se incluyen cuando se acuerdan explícitamente dentro del alcance del servicio.
Entity Points y planificación del alcance empresarial
Entity Points proporcionan un marco de capacidad para los registros elegibles que se migran. En actividades posteriores sobre Adobe Commerce, los registros elegibles ya contabilizados siguen contando una sola vez dentro de la misma ruta de migración; la complejidad de websites, store views, B2B y extensiones se evalúa por separado. Categories, atributos, empresas, catálogos compartidos, websites, store views, campos personalizados, módulos e identificadores externos pueden aumentar la complejidad sin convertirse en tipos de registro independientes de Entity Points.
Esta distinción es esencial. Dos proyectos pueden utilizar el mismo Entity Points Plan y necesitar enfoques de servicio muy diferentes. Un catálogo grande de Products ordinarios puede encajar en Standard Service. Un catálogo pequeño puede necesitar Custom Service si cada Product depende de atributos personalizados, precios específicos por empresa o identificadores controlados por integraciones.
En actividad posterior, los registros elegibles ya contabilizados siguen contando una sola vez en la misma ruta. Nuevos Products, Customers, Orders o Blog Posts elegibles pueden consumir Entity Points cuando se migran por primera vez.
La planificación debe responder:
| Pregunta de planificación | Por qué importa |
|---|---|
| ¿Qué registros elegibles están dentro del alcance aprobado? | Determina el Entity Points Plan apropiado. |
| ¿Qué registros están obsoletos, duplicados o fuera de las necesidades del lanzamiento? | Permite decidir filtrado y evitar uso innecesario de capacidad. |
| ¿Qué registros ya fueron contabilizados dentro de la migración comprada y la ruta fija? | Evita suposiciones incorrectas de doble consumo. |
| ¿Qué registros elegibles nuevos pueden crearse antes del lanzamiento? | Permite planificar capacidad para actividad posterior. |
| ¿Qué estructuras complejas no son tipos de Entity Points independientes? | Mantiene separadas la evaluación de complejidad y la de volumen. |
Entity Points ayuda a dimensionar la migración. No demuestra que requisitos B2B, multi-sitio, de extensiones o de integraciones estén soportados.
Qué debe demostrar Demo Migration
Demo Migration debe poner a prueba la decisión de servicio mediante registros representativos y difíciles. Seleccionar únicamente Products simples puede generar una falsa sensación de seguridad en un proyecto de Adobe Commerce.
La muestra debería incluir, cuando sea relevante:
- Products simples, configurables, bundle, grouped, virtuales o descargables;
- Products con atributos complejos y valores específicos de store view;
- Categories utilizadas por distintos stores o catálogos raíz;
- Customers de grupos importantes o contextos Company;
- Orders con descuentos, impuestos, reembolsos, estados poco habituales o identificadores externos;
- CMS Pages, Blog Posts y registros sensibles a URLs prioritarios;
- registros afectados por extensiones o integraciones;
- ejemplos de cada website, store o store view importante para el lanzamiento.
Demo Migration debe responder cuatro preguntas:
- ¿Los registros estándar están representados correctamente?
- ¿Las relaciones de alcance de tienda y B2B siguen conservando su significado?
- ¿Qué carencias pueden resolverse mediante configuración compatible o Add-ons?
- ¿Qué carencias requieren Custom Service o implementación separada en destino?
Una Demo Migration satisfactoria no es solo una comparación de recuentos. Proporciona evidencia de que el enfoque de servicio elegido es suficiente antes de Full Migration. Si la muestra revela estructuras no compatibles o una propiedad oculta de los datos, el enfoque debe cambiar antes de ejecutar todo el alcance.
Additional Migration Options para Adobe Commerce
Las Additional Migration Options permiten actividad posterior cuando el origen sigue activo, cambia la configuración de destino o la empresa necesita un resultado de migración diferente. La acción elegida debe reflejar si la configuración previamente aceptada sigue siendo válida.
| Acción actual | Situación apropiada | En qué volver a validar Adobe Commerce |
|---|---|---|
| Continue the Migration with the Last Used Configuration | El mapeo y alcance aceptados siguen siendo válidos y la actividad posterior del origen debe procesarse con la misma configuración. | Nuevos Products, Customers, Orders, Blog Posts, valores por alcance de tienda, URLs e identificadores vinculados con integraciones. |
| Continue the Migration with a New Configuration | La ruta de migración no cambia, pero deben modificarse filtrado, mapeo, asignación de tienda u otra configuración compatible. | Cambios en estructuras de Products, distribución website/store/store view, mapeo de atributos, alcance B2B, contenido y comportamiento de URLs. |
| Perform a New Migration | La empresa necesita un resultado de migración distinto en lugar de continuar la configuración anterior. | Todo el alcance de destino, jerarquía B2B y de tiendas, modelo de Products, propiedad de integraciones, SEO y criterios de aceptación. |
Estas acciones no implementan automáticamente módulos de Adobe Commerce, catálogos compartidos, permisos Company, integraciones externas, temas ni configuración de destino. Funcionan dentro del alcance acordado del Migration Service y mantienen sin cambios la ruta comprada entre Source Platform y Target Platform. Cambiar Source Platform o Target Platform requiere comprar otra migración.
Decisión final sobre el enfoque de servicio
El enfoque más sólido para Adobe Commerce es la ruta de servicio más ligera que pueda conservar el significado empresarial requerido y producir un resultado que la empresa pueda validar con seguridad.
| Evidencia | Enfoque probable |
|---|---|
| Registros compatibles, estructuras ordinarias, alcance claro y ejecución/validación lideradas por el cliente | Standard Service |
| Alcance compatible pero coordinación, validación o calendario de lanzamiento exigentes | Managed Service |
| Migración estándar con necesidades acotadas de filtrado de registros, transformación de valores o remapeo de campos compatibles | Standard Service o Managed Service con Add-ons |
| Registros no compatibles, módulos personalizados, transformación específica o complejidad B2B/de integración fuera del funcionamiento estándar | Custom Service, potencialmente con Expert Handle y Add-ons acordados |
La decisión debe documentarse antes de Full Migration y confirmarse mediante evidencia de Demo Migration. Un proyecto no debería escalarse solo porque Adobe Commerce sea una plataforma empresarial, ni mantenerse en una ruta ligera cuando el resultado aceptado depende de estructuras empresariales no compatibles.
Conclusión
Elegir el enfoque de migración para Adobe Commerce depende de la relación entre alcance de registros, estructura operativa empresarial, responsabilidad de ejecución y personalización. Standard Service puede cubrir rutas compatibles y limpias. Managed Service ayuda cuando coordinación y validación son exigentes. Los Add-ons resuelven necesidades compatibles y acotadas. Custom Service cubre requisitos a medida y no estándar.
La decisión final debe considerar la jerarquía de websites, stores y store views, tipos de Product, contexto de Companies B2B y catálogos compartidos, sistemas externos, Entity Points y evidencias de Demo Migration. Las Additional Migration Options deben seleccionarse después según si la configuración aceptada sigue siendo válida, necesita ajustes o debe sustituirse por un resultado de migración nuevo.
Preguntas frecuentes
¿Puede un catálogo grande de Adobe Commerce utilizar Standard Service?
Sí. El volumen por sí solo no determina la ruta de servicio. Un catálogo grande puede usar Standard Service cuando la ruta es compatible, las estructuras de Products son reconocibles y el cliente puede ejecutar y validar el servicio. Entity Points cubre la capacidad de registros elegibles; la complejidad estructural se evalúa aparte.
¿Cuándo resulta más apropiado Managed Service para Adobe Commerce?
Cuando la migración sigue dentro del funcionamiento compatible, pero ejecución, coordinación o validación son exigentes. Es especialmente útil en proyectos con varios equipos, múltiples alcances de tienda, grandes cargas de revisión y calendarios de lanzamiento estrictos.
¿Los Add-ons cubren módulos personalizados de Adobe Commerce?
Por lo general, no. Los Add-ons cubren necesidades acotadas dentro del funcionamiento compatible. Los datos almacenados en módulos personalizados, tablas de extensiones, estructuras B2B específicas o sistemas externos suelen requerir revisión mediante Custom Service.
¿Qué debe demostrar Demo Migration en Adobe Commerce?
Debe demostrar que Products, Customers, Orders, contenido, alcances de tienda, relaciones B2B, URLs y campos vinculados con integraciones siguen conservando su significado. También debe revelar si las carencias corresponden a configuración, Add-ons, Custom Service o implementación separada en destino.
¿Qué Additional Migration Option debe seleccionarse?
Use Continue the Migration with the Last Used Configuration cuando la configuración aceptada siga siendo válida, Continue the Migration with a New Configuration cuando deban cambiar ajustes compatibles y Perform a New Migration cuando se necesite un resultado distinto con revalidación completa.