El Next-Cart Migration Service incorrecto rara vez se elige porque los nombres de los servicios no estén claros. Normalmente se elige porque la decisión se toma demasiado pronto. El tamaño de la tienda, el precio, la presión del calendario o un deseo general de recibir ayuda sustituyen a la información sobre los datos, la representación en el destino, la carga de ejecución y el estándar de aceptación.
Una elección defendible sigue otra secuencia. Primero hay que establecer qué debe conservar la migración. Después debe determinarse si el requisito encaja en el comportamiento compatible, si un Add-on acotado es suficiente y quién puede coordinar responsablemente la ejecución. El precio solo resulta útil cuando esas preguntas han producido una dirección de servicio creíble.
Este orden importa porque los tres Next-Cart Migration Services resuelven problemas diferentes. Standard Service admite ejecución dirigida por el cliente dentro del alcance compatible. Managed Service incluye ejecución dirigida por especialistas dentro del alcance compatible. Custom Service aborda requisitos adaptados y puede ser dirigido por el cliente o incluir Expert Handle.
Defina el resultado antes de comparar servicios
La idoneidad del servicio empieza por el resultado empresarial, no por la etiqueta del servicio. El proyecto debe identificar qué resultados deben seguir siendo ciertos después de la migración, por ejemplo:
- Products siguen siendo comprensibles y comprables;
- la identidad y segmentación de Customers siguen siendo útiles;
- el historial de Orders respalda las necesidades de servicio e informes;
- el contenido y las URL conservan su valor previsto;
- las relaciones críticas siguen conectadas;
- los identificadores externos siguen respaldando sistemas dependientes;
- la tienda de destino puede validarse frente a información acordada.
Estos resultados revelan qué debe examinarse en los datos de origen. Una ruta de migración compatible puede seguir conteniendo tablas personalizadas, registros gestionados por aplicaciones o limitaciones del destino que cambien la representación necesaria. Sin una definición del resultado, estas diferencias pueden descubrirse únicamente después de que la elección del servicio ya haya establecido expectativas.
La decisión también debe separar los datos migrados de la implementación en la plataforma de destino. Transferir un identificador es una cuestión de migración. Desplegar y operar la integración que lo consume es trabajo de implementación salvo que se incluya expresamente. Mezclar ambas cosas puede hacer que todos los proyectos parezcan personalizados o producir un alcance personalizado incompleto.
Mantenga la capacidad fuera de la decisión sobre idoneidad del servicio
Entity Points responde a cuánta capacidad contabilizada de Products, Customers, Orders y Blog Posts se necesita. No mide:
- complejidad estructural;
- lógica personalizada;
- dependencias de terceros;
- capacidad interna de ejecución;
- esfuerzo de implementación en el destino;
- carga de validación.
Una tienda con 200,000 registros previsibles puede encajar en Standard Service si el equipo puede dirigir la ejecución. Una tienda con 500 registros puede necesitar Custom Service si un pequeño conjunto contiene reglas propias de precios o procesamiento de pedidos. La capacidad y la idoneidad del servicio deben calcularse por separado y combinarse después en la decisión final de compra.
Esta distinción también evita que el precio determine el alcance. Elegir un plan de menor capacidad solo puede reducir el precio cuando el requisito contabilizado realmente cabe. No puede eliminar una dependencia de datos personalizados ni cambiar quién está preparado para ejecutar el trabajo.
Compruebe si el requisito es compatible
La primera pregunta para decidir el servicio es si el comportamiento de migración disponible puede producir el resultado previsto.
Es más probable que un requisito permanezca dentro del alcance compatible cuando:
- la ruta de migración es compatible;
- los registros importantes utilizan estructuras previsibles de la plataforma;
- el significado del origen puede representarse mediante campos y relaciones disponibles en el destino;
- la configuración estándar y Attribute Mapping cubren la alineación necesaria;
- cualquier filtrado adicional, transformación de valores o redirección de campos encaja en un Standard Add-on;
- puede definirse la información de aceptación sin lógica de migración a medida.
Debe considerarse Custom Service cuando el resultado esperado depende de:
- una Custom Platform;
- campos, tablas o estructuras de base de datos personalizadas cuyo tratamiento requerido supera el alcance de la migración compatible o de Standard Add-ons;
- datos gestionados por aplicaciones, plugins, módulos o extensiones;
- registros de terceros o identificadores de sistemas externos;
- transformaciones, reestructuraciones o lógica de relaciones a medida;
- un Standard Add-on que debe modificarse;
- un Add-on nuevo y específico del proyecto;
- una representación en el destino que deba diseñarse y acordarse individualmente.
La información más sólida es específica. «La tienda tiene datos personalizados» es demasiado vago. «Los precios contractuales se almacenan en una tabla personalizada vinculada por grupo de Customer y SKU de Product, y la tienda de destino debe conservar esa relación comercial» identifica los datos, la propiedad, la relación y el resultado previsto.
Decida si un Standard Add-on es suficiente
Un Add-on puede mantener un proyecto compatible dentro de Standard o Managed Service cuando el problema es acotado y el comportamiento disponible encaja.
| Control requerido | Dirección de Standard Add-on | Límite que debe verificarse |
|---|---|---|
| Filtrar qué registros se migran aplicando condiciones basadas en campos a un tipo de datos | Data Filter | El tipo de datos, campo de origen, condición y regla de inclusión o exclusión son compatibles |
| Redirigir un campo compatible del origen a un campo compatible del destino | Advanced Data Mapping | Los tipos de valor de origen y destino, relaciones y usos posteriores siguen siendo válidos; Tax está excluido |
| Mapear campos compatibles o columnas subyacentes de base de datos a campos o columnas compatibles del destino | Advanced Database Mapping | Tanto la plataforma de origen como la plataforma de destino son Open-Source y los requisitos de campo/columna, tipo de valor, relación y uso posterior siguen siendo compatibles; Tax está excluido |
| Transformar valores seleccionados de campos del destino durante la migración | Data Transformation | Se han definido la expresión, los valores de entrada y los resultados compatibles con el destino |
La prueba del Add-on debe preguntar si el resultado esperado puede describirse y producirse mediante la capacidad disponible. Si la propia capacidad necesita modificaciones, pasa a ser un Tailored Add-on dentro de Custom Service. Si ningún Standard Add-on cubre el requisito, puede ser necesario un Custom Add-on o un alcance personalizado más amplio.
Utilizar un Add-on no demuestra que el proyecto sea personalizado. La señal más clara aparece cuando hay que modificar el Add-on, interpretar datos no compatibles o crear comportamiento específico del proyecto. Se pueden combinar varios Standard Add-ons cuando un resultado requiere varias etapas compatibles; la combinación por sí sola no convierte el Migration Service en Custom.
Evalúe la carga real de ejecución
Una vez comprendido si el alcance es compatible o adaptado, el proyecto puede decidir quién debe realizar las acciones de migración acordadas.
La ejecución dirigida por el cliente exige algo más que poder iniciar una acción. El equipo debe poder:
- preparar los accesos y la información del origen necesarios;
- comprender las decisiones de configuración;
- seleccionar información representativa de Demo;
- coordinar la ventana de migración;
- responder a fallos o resultados inesperados;
- involucrar a revisores de negocio, SEO, técnicos y operativos;
- documentar la aceptación final.
Si la migración sigue siendo compatible y el equipo interno puede asumir esa carga, Standard Service puede encajar. Si el alcance compatible sigue siendo adecuado pero debe incluirse la ejecución, Managed Service puede encajar.
Si se necesita trabajo adaptado, se aplica Custom Service independientemente de quién ejecute. El proyecto puede seguir siendo dirigido por el cliente o incluir Expert Handle. Expert Handle debe elegirse porque la responsabilidad de ejecución necesita estar incluida, no porque se suponga que la palabra «custom» significa gestión completa.
Utilice Demo Migration para cuestionar los supuestos
Demo Migration aporta más valor cuando prueba los supuestos que podrían cambiar la decisión del servicio. Una muestra formada únicamente por Products sencillos y Orders rutinarios puede confirmar el comportamiento básico de transferencia mientras deja intacto el riesgo real.
La información representativa puede incluir:
- un Product con variantes complejas o atributos personalizados;
- un Customer cuyo grupo afecte a precios o visibilidad;
- un Order con reembolsos, historial de estado poco habitual o referencias externas;
- contenido con URL o valor SEO importantes;
- registros que probablemente revelen necesidades de filtrado, transformación o mapeo;
- un campo personalizado o registro de terceros cuyo tratamiento requerido deba compararse con los límites del mapeo compatible o del alcance adaptado.
Demo Migration no puede validar Add-ons configurados ni Customization porque esas capacidades no están disponibles dentro de la Demo. Aun así, puede revelar el requisito e indicar dónde se necesita más información.
La interpretación debe ser disciplinada:
- un resultado compatible y previsible refuerza Standard o Managed Service;
- un resultado compatible junto con una capacidad interna de ejecución insuficiente refuerza Managed Service;
- una estructura no compatible, una transformación a medida o una lógica de relaciones sin resolver refuerza Custom Service;
- una muestra poco representativa no justifica una decisión segura sobre ningún servicio.
Compare los servicios después de desarrollar la información necesaria
Solo después de examinar alcance y ejecución resulta útil una tabla comparativa.
| Patrón observado | Dirección probable | Razonamiento |
|---|---|---|
| Ruta y estructuras compatibles; Standard Add-ons suficientes; el equipo puede ejecutar y validar | Standard Service | Es creíble una migración compatible dirigida por el cliente |
| Ruta y estructuras compatibles; Standard Add-ons suficientes; se necesita ejecución dirigida por especialistas | Managed Service | La necesidad pendiente es la responsabilidad de ejecución |
| Se necesita tratamiento adaptado o no estándar; el equipo puede ejecutar y validar | Custom Service dirigido por el cliente | Se necesita capacidad personalizada sin Expert Handle |
| Se necesita tratamiento adaptado o no estándar; también se necesita ejecución dirigida por especialistas | Custom Service con Expert Handle | Deben incluirse tanto el alcance personalizado como la responsabilidad de ejecución |
Este es un marco de decisión, no un sistema automático de puntuación. Una sola dependencia personalizada crítica puede pesar más que muchos registros estándar. Un equipo interno sólido puede hacer que Standard Service sea adecuado para una migración compatible de gran tamaño. La calidad de la información importa más que el número de casillas que parezcan favorecer una opción.
Revise los precios solo después de establecer la idoneidad del servicio
El precio combina capacidad de Entity Points, Migration Service, Add-ons adquiridos y trabajo de alcance personalizado. Comparar importes mostrados antes de establecer la idoneidad del servicio puede crear una falsa economía.
Un orden útil es:
- calcular una capacidad realista de Entity Points;
- establecer si el resultado es compatible o personalizado;
- asignar responsabilidad de ejecución;
- identificar Standard, Tailored o Custom Add-ons;
- revisar el precio del plan aplicable y la cotización personalizada.
Custom Service muestra como precio inicial el precio de Standard Service correspondiente al Entity Points Plan seleccionado. El importe final depende del trabajo personalizado acordado, los Add-ons adquiridos cuando correspondan, Expert Handle cuando esté incluido y otros costes específicos del alcance acordados. El importe inicial no debe compararse con un precio fijo de Standard o Managed como si las tres cifras describieran el mismo trabajo incluido.
La ruta de upgrades también debe informar la elección sin sustituir la información. Standard puede pasar posteriormente a Managed o Custom y Managed puede pasar a Custom. Un Migration Service adquirido no puede hacerse downgrade. Un upgrade permitido pasa a formar parte de la misma migración y cobra la diferencia adicional, pero no cambia la ruta fija ni amplía la duración de un año.
Registre por qué la elección es defendible
Una decisión de servicio debe poder sostenerse ante una revisión posterior. La justificación debe registrar:
- los resultados empresariales requeridos;
- por qué se considera compatible o personalizado el recorrido de migración y las estructuras importantes;
- qué requisitos acotados encajan en Standard Add-ons;
- qué requisitos necesitan trabajo adaptado;
- quién realizará las acciones de migración;
- qué demostró Demo Migration y qué no pudo demostrar;
- qué implementación de la plataforma de destino queda separada;
- qué información respaldará la aceptación final.
Este registro resulta valioso cuando cambia el proyecto. Si nueva información revela datos personalizados o el equipo interno pierde capacidad de ejecución, el servicio puede reconsiderarse frente a la justificación original. La decisión cambia porque cambió la información, no porque el proyecto se deslizara hacia otra etiqueta.
Conclusión
El Next-Cart Migration Service adecuado es el resultado de la información obtenida, no un atajo basado en tamaño de tienda, precio o percepción de nivel de servicio. Defina el resultado previsto, separe capacidad de complejidad, compruebe el alcance compatible, determine si un Standard Add-on es suficiente y asigne la responsabilidad de ejecución.
Elija Standard Service para ejecución dirigida por el cliente dentro del alcance compatible. Elija Managed Service cuando el alcance compatible siga siendo adecuado y se necesite ejecución dirigida por especialistas. Elija Custom Service cuando el resultado esperado necesite tratamiento adaptado, e incluya Expert Handle únicamente cuando la responsabilidad de ejecución también deba formar parte del alcance personalizado aceptado.
Preguntas frecuentes
¿Una tienda grande puede utilizar Standard Service?
Sí. Una tienda grande puede encajar en Standard Service cuando la ruta y los requisitos siguen siendo compatibles y el cliente puede coordinar ejecución y validación.
¿Cuándo es Managed Service más adecuado que Standard Service?
Managed Service es más adecuado cuando la migración sigue dentro del alcance compatible pero se necesita ejecución dirigida por especialistas de las acciones de migración acordadas.
¿Cuál es la señal más clara de que se necesita Custom Service?
La señal más clara es un resultado requerido que no puede producirse mediante el comportamiento de migración compatible y los Standard Add-ons disponibles, por ejemplo lógica a medida, datos no compatibles o una representación de destino específica del proyecto.
¿Los Add-ons pueden sustituir Custom Service?
Solo cuando el requisito acotado encaja en el alcance disponible del Standard Add-on. Varios Standard Add-ons pueden trabajar juntos sin Custom Service si cada operación sigue siendo compatible. Add-ons modificados, comportamiento nuevo de Add-on, registros no compatibles y relaciones a medida requieren revisión de Custom Service.
¿Entity Points determina el Migration Service?
No. Entity Points determina la capacidad contabilizada. El Migration Service depende del alcance compatible, la responsabilidad de ejecución, las necesidades de Add-ons, los requisitos adaptados y la información de aceptación.
¿Debe compararse el precio antes de Demo Migration?
El precio puede estimarse antes, pero no debe determinar la elección del servicio hasta que información representativa haya puesto a prueba los supuestos que afectan al alcance compatible y a la responsabilidad de ejecución.
¿Se puede cambiar el Migration Service después de la compra?
Solo hacia arriba. Standard puede pasar a Managed o Custom y Managed puede pasar a Custom. El cliente paga la diferencia adicional, mientras la ruta y la duración original del servicio permanecen sin cambios.