Elegir el enfoque de migración adecuado para Jumpseller depende de lo claramente que la tienda de origen pueda representarse dentro de la estructura de comercio alojada de Jumpseller. Una tienda pequeña puede requerir un tratamiento cuidadoso si las opciones de Product determinan inventario o precios. Una tienda más grande puede seguir siendo relativamente directa si Products, Categories, Customers, Orders, páginas y redirecciones siguen estructuras previsibles. El enfoque correcto se determina por la evidencia, no solo por el nombre de la plataforma o el volumen de datos.
La planificación de una migración hacia Jumpseller debe separar el movimiento de datos compatible de la interpretación operativa. Products, Categories, Customers, Orders, CMS Pages, Blog Posts y otros datos compatibles pueden seguir una ruta estándar cuando los datos de origen están preparados y las expectativas del lado de destino son claras. Los Add-ons pueden ayudar cuando el requisito consiste en filtrar registros, transformar valores de campos o redirigir campos de origen hacia otros campos de destino. Custom Service pasa a ser relevante cuando el proyecto incluye datos de aplicaciones no compatibles, campos personalizados cuyo tratamiento necesario supera el alcance de asignación de campos compatible e incorpora lógica de negocio, identificadores externos, funcionamiento de una plataforma personalizada o ajustes personalizados en la lógica de migración.
El enfoque más seguro se selecciona después de que la preparación y Demo Migration revelen cómo funciona realmente la tienda de origen. El objetivo no es elegir el servicio más amplio posible, sino evitar un enfoque demasiado limitado para requisitos que necesitan interpretación, configuración o tratamiento personalizado.
Dentro de los servicios de migración de Next-Cart, la evidencia específica de Jumpseller debe determinar si el proyecto encaja en una ejecución compatible dirigida por el cliente o por especialistas, necesita un Add-on bien delimitado o requiere un tratamiento adaptado.
Empezar por el modelo de responsabilidad de la migración
La primera decisión es quién debe dirigir la ejecución y cuánto acompañamiento operativo necesita el proyecto. Una migración dirigida por el cliente puede funcionar cuando los datos de origen son previsibles, el equipo entiende los pasos de migración y la tienda de destino ya está preparada. Una migración dirigida por Next-Cart puede ser más segura cuando el equipo busca apoyo en la ejecución, una revisión más disciplinada o un proceso gestionado, incluso si los datos siguen dentro de un alcance estándar.
| Enfoque | Mejor encaje | Precaución |
|---|---|---|
| Standard Service | Datos de origen compatibles, configuración de Jumpseller preparada, estructura clara de Products/Categories/Customers/Orders y un equipo listo para ejecutar por sí mismo el proceso de migración | No es la mejor opción si el equipo espera que Next-Cart interprete lógica de negocio compleja o gestione todas las decisiones de ejecución |
| Managed Service | Capacidad de migración estándar, pero el cliente quiere una ejecución dirigida por Next-Cart y menos intervención directa en la operación | Sigue dependiendo de capacidades estándar salvo que se acuerde trabajo personalizado adicional |
| Add-ons | Condiciones por tipo de datos, cambios de valores mediante expresiones o campos de origen que deben dirigirse a otros destinos | Data Filter, Advanced Data Mapping y Data Transformation no sustituyen a Custom Service cuando existen datos de aplicaciones no compatibles o interpretación específica |
| Custom Service | Tratamiento de plataforma personalizada, datos no compatibles, registros propiedad de aplicaciones, campos personalizados cuyo tratamiento necesario supera el alcance de asignación de campos compatible e incorpora funcionamiento de negocio, identificadores externos o ajustes personalizados en la lógica de migración | El alcance debe definirse a partir de evidencia concreta, no de una petición vaga de personalización |
Una migración hacia Jumpseller también puede combinar enfoques. Un proyecto puede usar Managed Service para la ejecución, Advanced Data Mapping para dirigir un campo de origen concreto hacia otro campo y Custom Service para un área específica de datos no compatibles. La clave es indicar el motivo de cada componente en lugar de tratar toda la migración como una única elección indiferenciada de servicio.
Ajustar el enfoque a la complejidad de Products y del catálogo
La estructura de Products suele ser una de las señales más importantes para elegir el enfoque adecuado en Jumpseller. Un catálogo limpio con SKU, Categories, imágenes, precios, stock y campos SEO convencionales puede encajar en una ruta estándar. En cambio, un catálogo con muchas variantes, campos personalizados, constructores de Products basados en aplicaciones, paquetes, cumplimiento digital o funcionamiento de opciones específico de la plataforma de origen requiere una revisión más profunda.
Las opciones y variantes de Jumpseller deben comprobarse con muestras representativas. Si la tienda de origen usa opciones únicamente como atributos de presentación, el tratamiento puede ser más simple. Si las opciones generan combinaciones vendibles con SKU, precio, stock, imagen o peso propios, el enfoque debe demostrar que esos significados siguen siendo utilizables después de la migración.
| Perfil de Product | Ruta de servicio probable | Motivo |
|---|---|---|
| Products simples con Categories, imágenes, precios, stock y campos SEO convencionales | Standard Service o Managed Service | El significado de los datos probablemente sea previsible si la plataforma de origen es compatible y la tienda de destino está preparada |
| Products con variantes vendibles que afectan SKU, precio, imagen o stock | Standard Service o Managed Service después de comprobarlo mediante Demo Migration | El enfoque solo es adecuado si el funcionamiento de las variantes sigue siendo operativo en los resultados de muestra |
| Products con matrices de opciones amplias o poco habituales | Data Transformation o Advanced Data Mapping solo para una necesidad compatible y bien definida de valor o destino de campo; en caso contrario, revisión de Custom Service | Las estructuras densas pueden exponer límites del destino o necesidades de interpretación específica |
| Products con campos personalizados utilizados como especificaciones cuyo tratamiento requerido supera el alcance de asignación de campos compatible | Advanced Data Mapping puede ayudar cuando campos de origen compatibles deben dirigirse a otros campos compatibles de Jumpseller | Custom Service puede ser necesario si esos campos controlan la compra o flujos de trabajo externos |
| Paquetes, kits, suscripciones, constructores de Products, personalización o lógica de Product propiedad de aplicaciones | Revisión de Custom Service | Este funcionamiento suele depender de datos de aplicaciones, lógica personalizada o reglas externas, no de registros estándar de Product |
El enfoque debe ajustarse si Demo Migration demuestra que se subestimó el funcionamiento de Products. Un catálogo que parece sencillo puede requerir Custom Service cuando la información decisiva vive fuera de los campos habituales de Product y variante.
Ajustar el enfoque a Customers, Orders y al significado histórico
Los datos de Customers y Orders deben evaluarse por su significado, no solo por su volumen. Una migración estándar puede ser suficiente cuando los registros de Customer contienen información convencional de perfil y dirección, y los Orders conservan líneas, totales, estado de pago, estado de procesamiento de pedidos, impuestos, descuentos y datos de envío comprensibles. Se necesita un tratamiento más cuidadoso cuando la tienda de origen utiliza estados personalizados, reglas por grupo, referencias de pago, identificadores fiscales, suscripciones, segmentación de Customers, notas internas o identificadores externos de Order.
Migrar Orders históricos no es lo mismo que configurar el proceso de compra futuro. Un Order migrado puede conservar evidencia de lo que ocurrió, pero los pagos, envíos, impuestos y el funcionamiento del proceso de compra futuro deben configurarse dentro de Jumpseller. La ruta de servicio no debe tratar el historial de Orders y el proceso de compra operativo como si fueran el mismo problema.
| Área de datos | Señal de ruta estándar | Señal de ampliación |
|---|---|---|
| Registros de Customer | Nombre, correo electrónico, teléfono, dirección, estado de cuenta y campos de perfil convencionales | Los grupos de Customer controlan precios, acceso, impuestos, pagos, envíos o funcionamiento externo del CRM |
| Cuentas de Customer | La identidad del Customer puede seguir siendo legible y la comunicación con clientes está planificada | No están claras las expectativas sobre contraseñas, activación de cuentas o reglas de acceso |
| Orders | El historial contiene líneas habituales, totales, estado de pago, estado de procesamiento, descuentos e impuestos | Estados personalizados, datos propiedad de aplicaciones, identificadores externos, reglas de procesamiento parcial o reembolsos complejos requieren interpretación |
| Pagos históricos | Deben mantenerse legibles el método y el estado de pago | Las referencias de transacción deben alimentar contabilidad, ERP u otros procesos externos de conciliación |
| Procesamiento de pedidos | El método de envío y el estado de procesamiento son suficientes para el historial | Almacenes, proveedores, marketplaces, dropshipping, recogida o funcionamiento con varias ubicaciones afectan las operaciones |
Una ruta adecuada para los datos del catálogo puede no ser suficiente para mantener la continuidad de Customers y Orders. Si el equipo necesita el historial de Orders para atención al cliente, impuestos, garantías, devoluciones o conciliación, las muestras de Order deben revisarse antes de confirmar el enfoque.
Ajustar el enfoque a contenido, SEO, idiomas y redirecciones
Una migración hacia Jumpseller puede incluir CMS Pages, Blog Posts, páginas de Product, páginas de Category, metadatos, imágenes, enlaces internos, versiones por idioma y redirecciones de URL. El enfoque adecuado depende de si ese contenido puede representarse limpiamente en Jumpseller o si la tienda de origen utiliza page builders personalizados, contenido incrustado por aplicaciones, patrones de URL inusuales o estructuras multilingües que necesitan interpretación.
El contenido no debe tratarse como secundario cuando la tienda anterior depende de él para visibilidad orgánica, educación sobre Products, guías de compra, confianza en políticas o páginas de destino de campañas. Una migración que conserva Products pero rompe rutas de contenido importantes puede crear fricción y pérdida de SEO.
| Perfil de contenido | Enfoque probable | Foco de revisión |
|---|---|---|
| Páginas, publicaciones, metadatos e imágenes convencionales | Standard Service o Managed Service | Confirmar legibilidad, formato, enlaces internos y calidad del destino |
| URL de Products/Categories de alto valor | Alcance estándar de migración con un plan de redirecciones gestionado por separado | Confirmar inventario de URL de origen y calidad de los destinos |
| Contenido multilingüe en Products, Categories, páginas y campos SEO | Comprobación mediante Demo Migration antes de la ejecución completa | Confirmar la configuración de idiomas y la ubicación del contenido traducido antes del lanzamiento |
| Contenido propiedad de page builders o aplicaciones | Puede requerir revisión de Custom Service | Determinar si el contenido puede trasladarse como contenido utilizable o debe reconstruirse |
| Enlaces internos complejos o páginas de destino de campañas | Revisión de contenido y redirecciones; Custom Service solo cuando se necesita tratamiento personalizado de datos migrados | Los enlaces rotos y las redirecciones débiles pueden perjudicar la usabilidad y la continuidad SEO |
La ruta de servicio debe conservar el contenido valioso donde resulte necesario y evitar trasladar contenido obsoleto solo porque exista. El alcance del contenido debe ser una decisión editorial y operativa, no únicamente una decisión de base de datos.
Usar Add-ons para controles de datos bien delimitados
Los Add-ons deben utilizarse cuando el requisito de migración encaja en una necesidad compatible y acotada. Para Jumpseller, esto significa filtrar registros mediante condiciones basadas en campos para cada tipo de datos, transformar valores mediante expresiones o redirigir campos de origen hacia campos de destino compatibles.
Los Add-ons no deben usarse como una solución genérica para cualquier requisito difícil. Si la necesidad depende de datos de aplicaciones no compatibles, campos personalizados cuyo tratamiento necesario supera el alcance de asignación de campos compatible e incorpora funcionamiento de negocio, identificadores externos o ajustes personalizados de lógica de migración, la ruta correcta es una revisión de Custom Service.
| Caso de uso del Add-on | Apropiado cuando | No apropiado cuando |
|---|---|---|
| Data Filter | Products, Customers, Orders o contenido compatibles deben cumplir condiciones definidas sobre campos de origen para migrarse | El filtro depende de lógica de aplicaciones no compatibles o de significado de origen no definido |
| Data Transformation | Los valores de campos compatibles deben transformarse mediante expresiones definidas durante la migración | La lógica necesaria depende de sistemas externos o reglas de negocio específicas |
| Advanced Data Mapping | Campos de origen compatibles deben dirigirse a campos de destino compatibles de Jumpseller | El destino requiere funcionamiento o estructura no compatibles |
Una prueba útil consiste en comprobar si el requisito puede describirse como una condición sobre un campo de registro, una expresión de transformación del valor de destino o un mapeo entre campo de origen y campo de destino. La interpretación personalizada debe pasar por revisión de Custom Service.
Usar Custom Service para requisitos no compatibles o específicos
Custom Service es apropiado cuando la migración requiere personalización, modificación, tratamiento de plataforma personalizada, datos de aplicaciones no compatibles, Tailored Add-ons, Custom Add-ons, identificadores externos, campos personalizados cuyo tratamiento necesario supera el alcance de asignación de campos compatible y tiene significado operativo, o ajustes personalizados de lógica de migración. No es una etiqueta premium para cualquier complejidad ordinaria; es la ruta adecuada cuando la capacidad estándar no es suficiente.
Para Jumpseller, Custom Service debe revisarse cuando el funcionamiento de Products, Customers, Orders, stock, contenido o integraciones no puede representarse mediante el comportamiento estándar de migración o mediante Add-ons compatibles.
| Motivo para Custom Service | Ejemplo | Por qué importa |
|---|---|---|
| Origen plataforma personalizada | La tienda de origen utiliza una estructura de catálogo o proceso de compra desarrollada a medida | Los datos necesitan interpretación antes de convertirse en registros utilizables en Jumpseller |
| Datos de aplicaciones no compatibles | Reviews, suscripciones, paquetes, programas de fidelización, fuentes de datos de Products o datos personalizados de proceso de compra viven en tablas de aplicaciones | Los datos propiedad de aplicaciones pueden no estar disponibles a través de rutas estándar |
| Identificadores externos | Los identificadores de ERP, almacén, contabilidad, marketplace o procesamiento de pedidos deben seguir siendo utilizables | Puede ser necesario conservarlos, transformarlos o mapearlos de una forma específica |
| Campos personalizados con comportamiento | Un campo controla precios, elegibilidad, stock, presentación de Product o procesamiento de pedidos | El campo representa lógica de negocio, no solo contenido informativo |
| Ajuste personalizado de lógica de migración | El proyecto necesita reglas de transformación específicas | Los ajustes estándar y Add-ons no bastan para expresar el tratamiento necesario |
Custom Service debe definirse con ejemplos. La mejor petición no es “personalizar la migración”, sino algo concreto como conservar identificadores de Products del ERP como referencias utilizables, transformar opciones de un constructor de Products de origen en campos interpretables por Jumpseller o conservar metadatos personalizados de Orders para revisión del equipo.
Cómo influyen Entity Points en la planificación del alcance para Jumpseller
Entity Points dimensionan la capacidad de migración contabilizada; no determinan si Jumpseller puede representar correctamente el negocio de origen. Products, Customers, Orders y Blog Posts se contabilizan según las reglas de Entity Points cuando se migran por primera vez. Categories, imágenes, CMS Pages, URL, configuración de aplicaciones, código del tema y configuración de integraciones pueden seguir requiriendo una revisión considerable aunque no formen parte de la misma capa de capacidad contabilizada.
| Área contabilizada | Pregunta de planificación en Jumpseller | Por qué el volumen no es suficiente |
|---|---|---|
| Products | ¿Qué Products, variantes, estructuras de opciones, artículos digitales, paquetes o registros influidos por aplicaciones deben entrar en el catálogo de destino? | Un Product puede contener varias combinaciones comprables y dependencias. |
| Customers | ¿Qué cuentas registradas, registros relacionados con invitados, direcciones, campos de consentimiento y perfiles duplicados siguen siendo útiles? | La usabilidad de la cuenta y el consentimiento de marketing no se demuestran con el número de Customers. |
| Orders | ¿Cuánto historial se necesita para soporte, finanzas, procesamiento de pedidos, devoluciones y referencias de sistemas externos? | El significado histórico depende de líneas, estados, totales, impuestos, reembolsos e identificadores externos. |
| Blog Posts | ¿Qué contenido debe seguir formando parte del sitio de Jumpseller y del plan de URL? | El valor del contenido depende de enlaces, metadatos, presentación del tema y decisiones de redirección. |
Los registros ya contabilizados dentro de la migración comprada y de su ruta fija no vuelven a consumir Entity Points simplemente porque se realice otra acción de migración. Los registros nuevos y elegibles pueden consumir Entity Points cuando se migran por primera vez. Esto importa cuando la tienda de origen sigue activa y aparecen nuevos Orders o Customers después de la primera ejecución aceptada.
Entity Points debe revisarse junto con el filtrado y la calidad de los datos. Registros de prueba, Products obsoletos, Customers duplicados e historial innecesario solo deben excluirse mediante reglas deliberadas de alcance. La planificación de capacidad no sustituye el análisis de estructura de Products, datos de aplicaciones, SEO o integraciones.
Usar Demo Migration como punto de decisión
Demo Migration debe decidir si el enfoque elegido encaja con la tienda real. No debe tratarse como una pequeña vista previa de registros sencillos. La muestra debe incluir registros que demuestren el funcionamiento ordinario y otros que expongan los casos difíciles.
| Muestra de Demo Migration | Qué debe comprobar | Resultado de decisión |
|---|---|---|
| Product simple | Identidad de Product, precio, imagen, stock, Category y campos SEO | Confirma el tratamiento básico del catálogo |
| Product con variantes | Nombres y valores de opciones, SKU, precio, imagen, peso, stock y disponibilidad | Confirma que las opciones comprables siguen siendo operativas |
| Product complejo | Campos personalizados, funcionamiento digital, datos de fabricación bajo pedido, paquetes o lógica propiedad de aplicaciones | Revela necesidades de Add-on o Custom Service |
| Muestra de Customer | Direcciones, idioma, consentimiento de marketing, etiquetas de grupo y expectativas de cuenta | Confirma que los registros son utilizables sin exagerar la continuidad de acceso |
| Muestra de Order | Estado de pago, estado de procesamiento, reembolsos, impuestos, descuentos, estados personalizados e identificadores externos | Confirma que el significado histórico sigue siendo legible |
| Muestra de contenido y URL | CMS Pages, Blog Posts, metadatos, enlaces internos y redirecciones | Confirma que la continuidad de contenido y SEO es realista |
| Muestra de integración | Registros conectados a ERP, procesamiento de pedidos, almacén, marketplace o procesos de generación de informes | Identifica dependencias de sistemas externos antes de Full Migration |
Un buen resultado de Demo Migration debe llevar a una de tres decisiones: continuar con el enfoque elegido, añadir un control definido mediante Data Filter, Advanced Data Mapping o Data Transformation, o trasladar requisitos concretos a revisión de Custom Service.
Cómo afectan las Additional Migration Options a la planificación del lanzamiento de Jumpseller
Las Additional Migration Options resultan útiles cuando la tienda de origen continúa cambiando después del resultado de migración aceptado o cuando el comerciante necesita revisar cómo se tratan los registros posteriores. La opción elegida debe reflejar si siguen siendo válidas las suposiciones aceptadas sobre Products, Customers, Orders, contenido, URL e integraciones.
| Opción actual | Uso específico para Jumpseller | Revalidación requerida |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Úsela cuando nuevos Products, Customers, Orders o Blog Posts elegibles puedan seguir los mismos filtros, asignaciones de campos, tratamiento de variantes, idiomas y reglas de URL ya aceptados. | Revisar nuevas variantes, registros de Customer, Orders excepcionales, contenido y cualquier identificador relacionado con integraciones que se vea afectado. |
| Continue the Migration with a New Configuration | Úsela cuando deban cambiar filtros, asignaciones de campos, interpretación de campos de Product, tratamiento de Customers, alcance del contenido, idiomas, redirecciones o reglas de identificadores externos. | Revalidar las reglas modificadas y compararlas con registros representativos previamente aceptados bajo la configuración anterior. |
| Perform a New Migration | Úsela cuando se necesite un resultado migrado distinto y el resultado anterior ya no deba ser la referencia del proyecto, manteniendo sin cambios la ruta fija plataforma de origen→plataforma de destino comprada. | Repetir el conjunto completo de aceptación para catálogo, Customers, Orders, contenido, URL, aplicaciones e integraciones. |
Estas acciones no recrean temas de Jumpseller, scripts de proceso de compra, aplicaciones, configuración de pagos o envíos, configuración de canales de venta ni procesos de sistemas externos. Los cambios en esas áreas requieren implementación independiente en el destino y su propia revalidación.
Elegir el enfoque más seguro para Jumpseller
Después de la preparación y Demo Migration, elija el enfoque más ligero que pueda conservar de forma fiable el significado del negocio. No elija una ruta más pesada únicamente porque la tienda de origen sea grande. Tampoco elija una ruta más ligera únicamente porque la tienda parezca sencilla a primera vista.
| Evidencia del proyecto | Dirección recomendada | Motivo |
|---|---|---|
| Datos de origen compatibles, catálogo limpio, Customers y Orders convencionales, configuración de Jumpseller preparada y equipo listo para una ejecución dirigida por el cliente | Standard Service | El proyecto encaja en una ruta de migración compatible y previsible |
| Datos de origen compatibles y complejidad estándar, pero el cliente prefiere ejecución dirigida por Next-Cart | Managed Service | Se necesita apoyo de ejecución aunque no haya lógica de migración personalizada |
| Datos compatibles con necesidades acotadas de filtrado de registros, transformación de valores o remapeo de campos | Standard Service o Managed Service con Add-ons | Los Add-ons pueden cubrir ajustes compatibles de alcance o asignación de campos |
| Datos compatibles más registros concretos de aplicaciones no compatibles, identificadores externos o campos personalizados con funcionamiento propio | Custom Service para esos requisitos, definiendo aparte la ruta de ejecución general | El requisito personalizado debe delimitarse en lugar de quedar oculto dentro de una elección general de servicio |
| Origen plataforma personalizada o requisito de transformación específico | Custom Service | La estructura de origen necesita interpretación personalizada o ajuste de lógica de migración |
| Inicio estándar, pero Demo Migration expone funcionamiento difícil en Products, Customers, Orders, contenido o integraciones | Ajustar la ruta de servicio antes de Full Migration | La evidencia debe cambiar el plan antes de que la ejecución genere retrabajo |
El enfoque más seguro se basa en evidencia. Una migración puede empezar con una hipótesis estándar, pero esa hipótesis debe seguir siendo provisional hasta revisar las muestras difíciles.
Conclusión
Elegir el enfoque adecuado para migrar a Jumpseller significa ajustar la ruta de servicio a la estructura real de la tienda de origen y a los requisitos operativos de la tienda de destino. Standard Service puede encajar en migraciones limpias y compatibles cuando el cliente está preparado para ejecutar por sí mismo el proceso. Managed Service puede encajar cuando la migración sigue siendo estándar pero se prefiere una ejecución dirigida por Next-Cart. Los Add-ons pueden cubrir filtrado de registros, transformación de valores y remapeo de campos cuando el requisito permanece dentro de un funcionamiento compatible. Custom Service es la ruta correcta para datos no compatibles, tratamiento de plataforma personalizada, identificadores externos, campos personalizados cuyo tratamiento necesario supera el alcance de asignación de campos compatible y conserva significado de negocio, Tailored Add-ons, Custom Add-ons o ajustes personalizados de lógica de migración.
La decisión debe tomarse a partir de la evidencia obtenida en la preparación y Demo Migration. Si las muestras difíciles conservan el significado de Products, Customers, Orders, contenido, SEO e integraciones, el enfoque elegido puede continuar. Si esas muestras revelan funcionamiento no compatible, la ruta de servicio debe ajustarse antes de Full Migration.
Preguntas frecuentes
¿Standard Service es suficiente para una migración hacia Jumpseller?
Standard Service puede ser suficiente cuando la ruta de origen es compatible, los datos están preparados, Jumpseller puede representar la estructura necesaria de Products, Customers, Orders, contenido y SEO, y el cliente está listo para ejecutar por sí mismo el proceso de migración. Demo Migration debe confirmar esa hipótesis antes de Full Migration.
¿Cuándo conviene seleccionar Managed Service para una migración hacia Jumpseller?
Managed Service resulta útil cuando la migración permanece dentro de capacidades estándar pero el cliente quiere que Next-Cart dirija la ejecución. Suele ser adecuado cuando los datos no son personalizados, pero el equipo prefiere un proceso gestionado y apoyo durante la ejecución y revisión.
¿Cuándo son relevantes los Add-ons para Jumpseller?
Los Add-ons son relevantes cuando el requisito consiste en filtrado acotado de registros, transformación de valores o remapeo de campos dentro de un funcionamiento de migración compatible. Algunos ejemplos son mover solo determinados datos, transformar valores o usar opciones compatibles que ayuden a que los datos migrados encajen mejor en la tienda de destino.
¿Cuándo requiere Custom Service una migración hacia Jumpseller?
Custom Service es apropiado cuando el proyecto incluye tratamiento de plataforma personalizada, datos de aplicaciones no compatibles, identificadores externos, campos personalizados cuyo tratamiento necesario supera el alcance de asignación de campos compatible y tiene significado operativo, Tailored Add-ons, Custom Add-ons, transformación específica o ajustes personalizados de lógica de migración.
¿Puede un proyecto combinar Managed Service, Add-ons y Custom Service?
Sí. Un proyecto puede usar Managed Service para la ejecución, Data Filter o Advanced Data Mapping para un requisito compatible y bien delimitado, y Custom Service para requisitos concretos no compatibles. Cada componente debe tener un motivo y un alcance claros.
¿Qué debe demostrar Demo Migration antes de confirmar el enfoque final?
Demo Migration debe demostrar que tanto las muestras ordinarias como las difíciles siguen siendo utilizables en Jumpseller. Debe comprobar Products, variantes, Categories, Customers, Orders, contenido, URL y registros vinculados a dependencias para que la elección del servicio se base en evidencia y no en suposiciones.
¿Qué Additional Migration Option encaja con una acción posterior en Jumpseller?
Use Continue the Migration with the Last Used Configuration cuando las reglas aceptadas sigan siendo válidas para nuevos registros. Use Continue the Migration with a New Configuration cuando cambien filtros, asignaciones de campos, tratamiento de Products, Customers, contenido, idiomas, redirecciones o reglas de identificadores externos. Use Perform a New Migration cuando se necesite un resultado distinto y el resultado anterior ya no deba gobernar la validación, manteniendo la misma ruta fija de migración comprada