Es fácil subestimar un Migration Service de Next-Cart si se interpreta como un único pago seguido de una única transferencia. El cliente adquiere una migración que se mantiene como unidad organizativa del servicio. Su ruta de migración fija, la duración de un año, la capacidad contabilizada, la responsabilidad de ejecución, las mejoras compatibles y cualquier requisito adaptado se combinan para definir el resultado.
Estas decisiones están relacionadas, pero no son intercambiables. Una tienda grande puede tener datos previsibles y encajar en una migración gestionada por el cliente. Una tienda más pequeña puede depender de campos personalizados o registros de terceros cuyo tratamiento necesario quede fuera del alcance compatible de la migración o de los Standard Add-ons. Un Add-on puede resolver una necesidad concreta de mapeo sin cambiar todo el Migration Service. Entity Points puede cubrir el volumen contabilizado de datos sin demostrar que la representación en destino será utilizable.
Por eso, la forma más útil de entender los Migration Services de Next-Cart es considerar la migración adquirida como un conjunto de capas coordinadas. Cada capa responde a una pregunta diferente del proyecto. Las mejoras posteriores pasan a formar parte de esa misma migración en lugar de crear servicios independientes, de modo que la migración sigue siendo el contexto estable para la planificación, la ejecución y la validación.
Empiece por el resultado que debe conseguir la migración
La ruta de migración define una dirección fija y unidireccional desde una plataforma de origen hasta una plataforma de destino. Esa dirección es más que un detalle de enrutamiento. Establece qué estructuras de plataforma deben interpretarse, qué requisitos de conexión deben prepararse y qué limitaciones del destino pueden afectar al resultado.
Antes de considerar capacidad o precio, el resultado previsto debe estar claro. El proyecto puede necesitar que los Products sigan pudiendo comprarse, que los historiales de Customers sigan siendo útiles, que los Orders conserven contexto para atención y operaciones, que el contenido mantenga su valor SEO o que los identificadores externos sigan conectados con otro sistema. Estos resultados determinan qué debe conservar la migración y qué evidencia será necesaria más adelante.
Una migración adquirida cubre una única ruta desde una plataforma de origen hasta una plataforma de destino. La ruta no puede cambiarse después de la compra. El servicio permanece disponible durante un año desde el momento de la compra inicial, sujeto a la capacidad seleccionada, el Migration Service, los Add-ons adquiridos, el alcance personalizado acordado y las responsabilidades de validación.
Mejorar uno de los componentes no crea una ruta nueva ni reinicia la duración de un año. La mejora modifica la migración existente, mientras que la fecha de compra inicial sigue definiendo el periodo del servicio. Una migración expirada debe ampliarse antes de continuar con cualquier actividad posterior que sea elegible.
Separe las decisiones que forman una misma migración adquirida
Una migración adquirida suele reunir varias decisiones de planificación. La siguiente tabla resulta más útil después de comprender el resultado y la ruta de migración, porque muestra qué pregunta responde cada componente.
| Componente | Pregunta del proyecto que responde | Lo que no decide |
|---|---|---|
| Ruta de migración | ¿Qué dirección fija desde plataforma de origen hasta plataforma de destino está cubierta? | Si el modelo de datos es sencillo o si el resultado es aceptable |
| Duración del servicio | ¿Durante cuánto tiempo permanece activa la migración adquirida desde la compra inicial? | Si una mejora cambia la ruta o reinicia la duración |
| Entity Points Plan | ¿Cuánta capacidad contabilizada para Product, Customer, Order y Blog Posts está disponible? | Si el proyecto necesita Managed Service o Custom Service |
| Migration Service | ¿Quién es responsable de la ejecución y el requisito sigue dentro del alcance compatible o necesita tratamiento adaptado? | Cuánta capacidad contabilizada hace falta |
| Add-ons | ¿Puede una necesidad concreta de filtrado, mapeo de campos o columnas de base de datos, o transformación de valores de destino resolverse mediante una mejora compatible? | Si están cubiertos trabajos más amplios, no compatibles o a medida |
| Alcance personalizado acordado | ¿Qué datos, lógica, relaciones o resultados no estándar requieren trabajo adaptado? | La implementación de la plataforma de destino, salvo que se incluya expresamente |
La confusión suele empezar cuando se utiliza una fila para responder a la pregunta de otra. El tamaño de la tienda se usa como sustituto del encaje del servicio. Una estimación baja de Entity Points se interpreta como prueba de simplicidad. Se espera que un Add-on resuelva un modelo de datos personalizado. Se asume que Managed Service incluye cualquier requisito no estándar. Ninguna de estas conclusiones se deriva del componente en cuestión.
La capacidad describe volumen, no complejidad
Entity Points convierte cuatro tipos de datos contabilizados en capacidad ponderada:
- Product;
- Customer;
- Order;
- Blog Posts.
El Entity Points Plan seleccionado debe aportar capacidad suficiente para el requisito contabilizado de forma realista. Esa es una decisión de volumen. Aun así, la complejidad puede venir de Products con estructuras de opciones inusuales, registros pertenecientes a aplicaciones, atributos personalizados de Customers, identificadores externos de Orders, relaciones multilingües o limitaciones del lado de destino.
Piense en dos tiendas con la misma estimación de Entity Points. La primera utiliza registros estándar de plataforma y relaciones previsibles. La segunda guarda precios contractuales en tablas personalizadas y depende de un identificador externo para conectar Orders con un ERP. La capacidad contabilizada puede ser igual, pero los requisitos de migración no lo son. Por eso, la planificación de capacidad debe completarse junto con el análisis estructural, no en su lugar.
El cálculo detallado de ponderaciones y las reglas de consumo corresponden a Entity Points. Las capacidades de los planes, los precios de mejora y los precios de ampliación corresponden a Entity Points Plan and Migration Pricing.
La responsabilidad y el alcance son ejes distintos
La selección del Migration Service combina dos preguntas diferentes:
- ¿El resultado esperado se mantiene dentro del funcionamiento compatible de la migración o requiere trabajo adaptado?
- ¿Quién debe ejecutar las acciones de migración acordadas?
Standard Service y Managed Service cubren requisitos de migración compatibles. Su principal diferencia es la responsabilidad de ejecución. Standard Service sigue un enfoque gestionado por el cliente. Managed Service incluye ejecución a cargo de especialistas de las acciones de migración acordadas dentro del alcance compatible.
Custom Service cubre requisitos adaptados o no estándar. Puede seguir siendo gestionado por el cliente, o puede incluir Expert Handle cuando la ejecución de las acciones acordadas también deba formar parte del alcance personalizado.
Esta distinción evita un error habitual: tratar Managed Service como respuesta a datos no compatibles. La ejecución a cargo de especialistas no convierte una estructura personalizada en estándar. Del mismo modo, tener un requisito personalizado no significa automáticamente que también se necesite ejecución a cargo de especialistas.
Standard, Managed, and Custom Migration Services desarrolla estas definiciones. Choose the Right Migration Service explica cómo tomar la decisión a partir de la evidencia del proyecto.
Trate la migración como el registro principal del servicio
La migración adquirida y los pagos relacionados responden a preguntas distintas. La migración representa el estado actual del servicio: su ruta fija, el Migration Service seleccionado, el Entity Points Plan, los Add-ons, el trabajo personalizado aceptado, la duración del servicio y el historial de la migración. Los pedidos ofrecen el registro comercial de cómo ese estado fue adquirido, mejorado o ampliado.
La compra inicial crea la migración. Una mejora posterior del plan, del servicio, de un Add-on o del trabajo personalizado pasa a formar parte de esa misma migración una vez adquirida. Esta distinción explica por qué una migración puede tener varios pedidos relacionados sin convertirse en varios servicios de migración independientes.
También aclara el precio posterior. Una mejora se calcula con respecto al valor ya pagado por la migración, por lo que el cliente paga la diferencia adicional en lugar de volver a comprar el paquete completo. Ampliar una migración expirada es distinto: la ampliación reactiva el servicio desde el último estado conservado de la migración, incluidos los componentes aplicables que ya estaban integrados.
Para la planificación del servicio, esta distinción importa porque la continuidad sigue a la migración adquirida, mientras que cada pago permanece asociado al cambio comercial que registra.
Utilice Add-ons para problemas acotados
Los Add-ons resultan especialmente útiles cuando la ruta de migración es compatible pero una parte bien definida del resultado necesita control adicional. Los cuatro Standard Add-ons responden a tipos distintos de requisitos acotados:
- Data Filter selecciona qué registros migran aplicando condiciones basadas en campos a cada tipo de datos.
- Advanced Data Mapping remapea campos de origen compatibles hacia campos de destino compatibles.
- Advanced Database Mapping mapea campos compatibles y columnas subyacentes de base de datos hacia campos o columnas compatibles en destino, incluidos campos específicos de plataforma y personalizados, únicamente cuando tanto la plataforma de origen como la plataforma de destino son Open-Source.
- Data Transformation transforma valores seleccionados de campos de destino mientras los registros se migran desde la tienda de origen hasta la tienda de destino.
El límite es importante. Los Standard Add-ons son compatibles con los tres Migration Services cuando un Add-on disponible ya encaja con el requisito. Si el propio Add-on debe modificarse, el requisito pasa a ser un Tailored Add-on dentro de Custom Service. Si ningún Standard Add-on encaja, puede ser necesario un Custom Add-on o una revisión más amplia de Custom Service.
La decisión debe comenzar por el resultado necesario, no por el nombre del Add-on. «Migrar solo Orders posteriores a una fecha aprobada» describe un resultado que puede resolverse mediante filtrado. «Conservar un motor de precios propietario» describe un problema personalizado más amplio cuyo significado, relaciones y funcionamiento en destino deben definirse primero.
Convierta los resultados iniciales en evidencia
Demo Migration puede aportar evidencia representativa antes de una actividad de migración más amplia. Su valor depende menos de ver aparecer registros y más de seleccionar muestras que revelen diferencias significativas.
Una buena muestra puede incluir un Product con variantes y atributos especiales, un Order con un historial de estado inusual, un Customer utilizado en un flujo de segmentación real o contenido con un valor importante de URL. Los registros sencillos pueden demostrar que una ruta básica funciona; los registros difíciles muestran si las suposiciones de migración son suficientemente sólidas.
Demo Migration tiene límites definidos, y los Add-ons y la Customization no están disponibles dentro de ella. El resultado puede revelar una necesidad probable de mejora compatible o trabajo adaptado, pero no puede demostrar cómo funcionará esa configuración posterior. Demo Migration explica cómo seleccionar la evidencia e interpretar sus límites.
Mantenga separadas la ejecución y la aceptación
La ejecución produce un resultado de migración. La validación determina si ese resultado es utilizable para el negocio.
La revisión final debe comprobar más que la presencia de registros. Debe confirmar que Products importantes conservan el significado necesario para la compra, que Customers y Orders siguen siendo útiles, que el contenido y las URL mantienen el recorrido previsto, que las relaciones siguen conectando los registros correctos y que cualquier resultado de Add-on o trabajo personalizado coincide con el alcance aceptado.
El cliente sigue siendo responsable de la verificación final en todos los Migration Services. Esto no significa devolver al cliente la responsabilidad de ejecución. Se trata de otro tipo de responsabilidad: solo el negocio puede confirmar que la tienda de destino permite los resultados comerciales, operativos, SEO y de cumplimiento previstos.
La configuración de la plataforma de destino, el trabajo de tema, la instalación de aplicaciones, la implantación de integraciones y otros trabajos de implementación deben identificarse por separado salvo que estén expresamente incluidos en el alcance acordado. Un registro migrado correctamente no configura por sí mismo el sistema que lo utilizará.
Utilice la sección como un sistema de decisión
Los artículos sobre servicios están diseñados para responder a preguntas distintas:
| Decisión que debe resolverse | Artículo |
|---|---|
| ¿Cómo pasa la migración desde la preparación hasta un resultado validado? | How the Migration Process Works |
| ¿Qué puede demostrar la evidencia representativa inicial? | Demo Migration |
| ¿Cómo se calcula y consume la capacidad contabilizada? | Entity Points |
| ¿Qué plan y precio se aplican? | Entity Points Plan and Migration Pricing |
| ¿Puede un requisito compatible y acotado resolverse con un Add-on? | Add-ons |
| ¿En qué se diferencian los tres Migration Services? | Standard, Managed, and Custom Migration Services |
| ¿Qué requisitos adaptados corresponden a Custom Service? | What Custom Service Handles |
| ¿Qué Migration Service encaja con la evidencia del proyecto? | Choose the Right Migration Service |
| ¿Qué acción posterior corresponde a continuidad, una configuración distinta o un resultado nuevo? | Additional Migration Options |
Esta ruta de lectura no es una secuencia obligatoria. Es una forma de aislar la decisión que sigue siendo incierta sin mezclar capacidad, responsabilidad del servicio, alcance personalizado y validación en una única pregunta.
Conclusión
Una migración de Next-Cart se entiende mejor como un servicio adquirido y duradero que como una sola transferencia o un único pago. Su ruta de migración fija y su duración de un año establecen el límite. Entity Points aporta la capacidad contabilizada. El Migration Service define el alcance compatible o adaptado y la responsabilidad de ejecución. Los Add-ons resuelven requisitos compatibles y acotados. Custom Service cubre necesidades no estándar. Los pedidos relacionados registran compras, mejoras y ampliaciones sin fragmentar la migración. La validación determina si el resultado es apto para el uso empresarial.
Mantener estas capas separadas permite estimaciones más claras, decisiones de servicio más defendibles y mejores evidencias de aceptación. También evita un error de planificación habitual: asumir que un único componente, como el tamaño de la tienda, el precio o un Add-on, puede explicar toda la migración.
Preguntas frecuentes
¿Qué define la ruta de migración?
Define la dirección fija y unidireccional desde la plataforma de origen hasta la plataforma de destino cubierta por la migración adquirida.
¿Una mejora crea una migración nueva o reinicia la duración del servicio?
No. Una mejora adquirida se integra en la misma migración. La ruta fija no cambia y la duración de un año sigue contando desde la compra inicial.
¿Por qué una migración puede tener varios pedidos relacionados?
El pedido inicial crea la migración. Los pedidos posteriores pueden registrar mejoras o una ampliación mientras la migración sigue siendo el servicio que se gestiona.
¿Un Entity Points Plan de mayor capacidad exige Managed Service o Custom Service?
No. Entity Points determina la capacidad contabilizada. La selección del Migration Service depende del alcance compatible, la responsabilidad de ejecución, las necesidades de Add-ons y los requisitos adaptados.
¿Se puede utilizar un Add-on con Standard Service?
Sí. Un Standard Add-on puede acompañar a Standard, Managed o Custom Service cuando su funcionamiento disponible encaja con el requisito acotado.
¿Custom Service incluye siempre Expert Handle?
No. Custom Service puede seguir siendo gestionado por el cliente. Expert Handle solo se incluye cuando la ejecución a cargo de especialistas de las acciones de migración acordadas forma parte del alcance personalizado aceptado.
¿Por qué se requiere la validación del cliente después de una ejecución a cargo de especialistas?
La ejecución confirma que la actividad de migración se realizó dentro del alcance acordado. La validación del cliente confirma que los Products, Customers, Orders, contenido, relaciones y resultados empresariales obtenidos son aceptables para la tienda de destino.