Los requisitos de migración no estándar son difíciles por una razón que los recuentos de registros no pueden mostrar: los datos suelen contener un significado que no se ve únicamente en el nombre del campo. Un valor personalizado de Product puede determinar la búsqueda, el precio o el procesamiento de pedidos. Un identificador externo de Order puede conectar la tienda con contabilidad. Un registro gestionado por una aplicación puede representar una suscripción, un saldo de fidelización, un vendedor de marketplace o un proceso operativo.
Mover el valor sin comprender esa función puede producir una tienda de destino que parezca completa, pero que ya no respalde el negocio. Dentro de Next-Cart Migration Services, Custom Service cubre esta brecha convirtiendo un requisito no estándar en un resultado de migración acordado, con información definida del origen, representación prevista en el destino, trabajo adaptado y criterios de aceptación.
El objetivo no es etiquetar todo el proyecto como personalizado. Es identificar las áreas concretas en las que el comportamiento compatible y los Standard Add-ons no son suficientes y definir qué debe significar un resultado migrado viable.
Identifique por qué el requisito es no estándar
Un requisito puede necesitar Custom Service debido a su origen, estructura, lógica, relación o destino.
| Fuente de dificultad | Pregunta subyacente |
|---|---|
| Custom Platform | ¿Cómo pueden comprenderse y accederse los modelos de datos de origen o destino? |
| Campos o tablas personalizadas | ¿Qué significado empresarial contienen los valores y qué registros son sus propietarios? |
| Datos de aplicaciones, plugins, módulos o extensiones | ¿Los datos son autoritativos y qué proceso futuro los necesita? |
| Identificadores externos | ¿Qué relación con otro sistema debe seguir conectada después de la migración? |
| Transformación a medida | ¿Cómo deben combinarse, dividirse, normalizarse o reestructurarse valores o registros? |
| Relaciones no estándar | ¿Cómo deben representarse la propiedad y las referencias en la plataforma de destino? |
| Comportamiento de Add-on modificado o nuevo | ¿Por qué el Standard Add-on disponible no puede producir el resultado requerido? |
| Limitación del destino | ¿Cuál es la representación viable más cercana y qué implementación queda separada? |
Estas preguntas hacen que el alcance personalizado pueda explicarse. «Migrar todos los datos personalizados» no lo hace. Un requisito útil identifica los registros afectados, el propósito empresarial que debe continuar, el resultado previsto en la tienda de destino y la información que demostrará el éxito.
El trabajo con una Custom Platform empieza por el modelo de datos
Una Custom Platform puede ser la plataforma de origen, la plataforma de destino o ambas. El reto no consiste solo en establecer acceso. La migración debe determinar cómo representa la tienda Products, Customers, Orders, contenido, relaciones y estructuras de apoyo.
Entre la información útil del origen pueden estar:
- descripciones de esquema o exportación;
- Products, Customers, Orders y contenido representativos;
- claves primarias y foráneas;
- relaciones de Categories y navegación;
- valores personalizados de estado o tipo;
- referencias de medios y archivos;
- información sobre sistemas externos;
- ejemplos de los resultados empresariales que deben continuar.
La revisión debe comparar después ese significado del origen con la capacidad de la plataforma de destino. Algunos registros pueden tener un equivalente directo. Otros pueden necesitar transformación, mapeo de campos, una estructura personalizada en el destino o exclusión con una alternativa documentada.
Custom Service no hace posible cualquier representación en el destino. Crea una forma disciplinada de determinar qué puede migrarse, qué debe cambiar y qué debe esperar el cliente.
Trate los datos de terceros como un problema de propiedad
Las tiendas suelen depender de datos creados por aplicaciones, plugins, módulos, extensiones o servicios conectados. La presencia de una tabla o un campo no demuestra que deba migrarse. Algunos registros son autoritativos. Otros son cachés, registros, valores derivados o restos de funciones abandonadas.
La revisión personalizada debe establecer:
- qué sistema es propietario de los datos;
- qué proceso empresarial los utiliza;
- si siguen siendo autoritativos;
- a qué registro migrado pertenecen;
- qué debe hacer con ellos la tienda de destino o el sistema conectado;
- cómo se validará el resultado.
Esta prueba de propiedad es más fiable que copiar todos los campos no estándar. Los datos sin un propietario futuro pueden crear desorden o conflictos. Los datos con una función operativa continua pueden ser críticos aunque ocupen un solo campo.
Algunos ejemplos son:
- identificadores de suscripciones conectados con Products o Customers;
- saldos de fidelización conectados con la identidad de Customers;
- propiedad de vendedores de marketplace conectada con Products y Orders;
- referencias de procesamiento de pedidos conectadas con líneas de Orders;
- identificadores de PIM conectados con registros de Products;
- clasificaciones de informes conectadas con Products, Customers u Orders.
Conserve los identificadores externos a través de sus relaciones
Un identificador externo solo es útil si sobrevive su relación. Copiar un ID de Product de ERP a un campo de texto arbitrario puede conservar los caracteres mientras rompe el proceso que depende de ellos.
El alcance personalizado debe definir:
- el sistema propietario del identificador;
- el registro migrado al que hace referencia;
- requisitos de unicidad y formato;
- si el valor puede cambiar;
- el destino compatible en la plataforma de destino;
- el proceso de integración o informes que lo utilizará;
- la información necesaria para confirmar la relación.
Por ejemplo, conservar una referencia de Order puede requerir algo más que migrar el valor de cabecera. Atención al cliente, procesamiento de pedidos o contabilidad pueden necesitar que la referencia siga conectada al Order correcto, sus líneas y su contexto histórico.
El despliegue de integraciones permanece separado salvo que esté expresamente incluido. Custom Service puede conservar los datos y relaciones del lado de la migración definidos en el alcance aceptado. No construye ni opera automáticamente todos los sistemas que posteriormente consumirán esos datos.
Defina las transformaciones a medida por su significado
Puede ser necesaria lógica de migración personalizada cuando el comportamiento estándar no puede producir el resultado previsto. Entre los patrones habituales se incluyen:
- combinar varios campos del origen en un campo del destino;
- dividir un valor del origen entre varios campos del destino;
- normalizar valores inconsistentes;
- convertir estados del origen en estados del destino;
- reestructurar registros gestionados por aplicaciones;
- conservar relaciones no estándar;
- emparejar registros mediante identificadores específicos del proyecto;
- aplicar reglas que no están disponibles mediante Standard Add-ons.
La transformación debe describirse como una regla con ejemplos y excepciones.
Requisito débil:
Corregir los estados de Orders.
Requisito más sólido:
Convertir cada estado aprobado de Order del origen al estado definido en el destino, conservar el estado original del origen para auditoría cuando se haya acordado y validar ejemplos de Orders completados, cancelados, reembolsados y parcialmente procesados.
El requisito más sólido explica la condición del origen, el resultado en el destino y la prueba. Puede delimitarse, cotizarse, implementarse y aceptarse.
Sepa cuándo un Add-on pasa a ser personalizado
Los Standard Add-ons resuelven requisitos compatibles y acotados:
- Data Filter elige qué registros migrar aplicando condiciones basadas en campos a cada tipo de datos;
- Advanced Data Mapping redirige campos compatibles del origen a campos compatibles del destino;
- Advanced Database Mapping mapea campos compatibles y columnas subyacentes de base de datos a campos o columnas compatibles del destino únicamente cuando tanto la plataforma de origen como la plataforma de destino son Open-Source;
- Data Transformation transforma valores de campos seleccionados en el destino durante la migración.
Custom Service cobra relevancia cuando:
- un Standard Add-on debe modificarse, creando un Tailored Add-on;
- ningún Standard Add-on encaja, generando la necesidad de un Custom Add-on;
- los registros o relaciones subyacentes no son compatibles;
- el requisito necesita lógica a medida más allá del comportamiento disponible del Add-on.
Un Add-on puede seguir formando parte de un proyecto de Custom Service. El Add-on resuelve una capacidad concreta, mientras Custom Service define el resultado no estándar más amplio.
Construya el alcance a partir de información comprobable
Una solicitud de Custom Service debe aportar suficiente información para definir tanto viabilidad como aceptación.
| Información | Por qué importa |
|---|---|
| Detalles de plataforma de origen y destino | Establece la ruta de migración y el contexto de plataforma |
| Registros representativos del origen | Muestra valores, estructuras y relaciones reales |
| Propietario de los datos y propósito empresarial | Explica por qué deben sobrevivir los datos no estándar |
| Resultado previsto en la tienda de destino | Define la representación requerida |
| Reglas de transformación o emparejamiento | Hace comprobable la lógica adaptada |
| Aplicaciones o sistemas externos relacionados | Revela dependencias fuera de los registros estándar de plataforma |
| Excepciones y casos de fallo | Evita que el alcance cubra solo registros ideales |
| Muestras de validación y responsable | Define cómo se decidirá la aceptación |
| Entity Points Plan y Add-ons adquiridos | Separa capacidad y mejoras ya existentes del nuevo trabajo personalizado |
La información debe incluir casos difíciles, no solo ejemplos limpios. Una regla personalizada que funciona con Products ordinarios puede fallar en Products con identificadores ausentes, valores duplicados o relaciones poco habituales.
El alcance aceptado debe indicar qué se extraerá, transformará, relacionará o entregará. También debe indicar qué se excluye, qué depende de la capacidad de la plataforma de destino y qué responsabilidades de implementación permanecen separadas.
Separe el tratamiento de migración de la implementación en el destino
Custom Service puede definir un tratamiento de migración adaptado. No incluye automáticamente:
- diseño del tema o de la tienda online;
- instalación de aplicaciones o extensiones;
- desarrollo y despliegue de integraciones;
- configuración de pagos, envíos, impuestos o correo electrónico;
- reconstrucción completa de procesos;
- configuración operativa;
- cualquier funcionamiento del origen que la plataforma de destino no pueda admitir.
Esta separación no es únicamente contractual. Protege la decisión de migración. Un registro puede migrarse correctamente mientras el proceso del destino que lo utilizará todavía no está implementado. A la inversa, una aplicación de destino puede estar instalada mientras la migración no haya conservado los datos que necesita.
El alcance debe mostrar el punto de traspaso. Por ejemplo, un identificador externo puede migrarse a un campo de destino acordado mientras un trabajo de integración separado conecta ese campo con el ERP.
Establezca expectativas realistas sobre las diferencias entre plataformas
Custom Service no puede obligar a dos plataformas a comportarse de forma idéntica. Las opciones de Products, grupos de Customers, estados de Orders, jerarquías de contenido, URL y datos de aplicaciones pueden no tener un equivalente directo en el destino.
El resultado viable puede ser:
- conservación directa;
- transformación a una estructura compatible en el destino;
- mapeo a nivel de campo;
- conservación parcial del significado empresarial;
- exportación para uso separado;
- exclusión con un plan documentado de sustitución.
El resultado adecuado depende del propósito empresarial y de la capacidad de la plataforma de destino. La imitación exacta no siempre es el mejor objetivo. Una representación más sencilla en el destino puede ser mejor cuando conserva el resultado necesario sin arrastrar lógica obsoleta del origen.
Comprenda por separado alcance, ejecución y precio
Custom Service define el trabajo adaptado. Expert Handle define si también se incluye ejecución dirigida por especialistas de las acciones de migración acordadas.
Por tanto, un proyecto de Custom Service puede ser:
- dirigido por el cliente, con el trabajo adaptado incluido y el cliente realizando las acciones de migración; o
- dirigido por especialistas, con Expert Handle incluido en el alcance aceptado.
El importe mostrado de Custom Service comienza por el precio de Standard Service correspondiente al Entity Points Plan seleccionado. Ese importe establece el mínimo de capacidad. El total final añade la cotización acordada del trabajo de personalización, los Add-ons adquiridos cuando correspondan, Expert Handle cuando esté incluido y otros costes específicos del alcance aceptados.
Cuando se añade trabajo personalizado a una migración ya adquirida, la cotización aceptada modifica el valor total de la migración. Se sigue reconociendo el importe ya pagado y solo se cobra la diferencia adicional. El mismo principio se aplica a Tailored y Custom Add-ons.
El precio final no puede establecerse de forma responsable hasta que el resultado no estándar esté suficientemente claro para definir su alcance. Aceptar y adquirir el upgrade cotizado integra el trabajo en la misma migración; no crea una ruta nueva ni amplía la duración de un año del servicio.
Valide el resultado adaptado
El trabajo personalizado necesita información de aceptación personalizada. Las comprobaciones genéricas de recuentos no son suficientes cuando el requisito depende de significado, transformación o relaciones.
La validación debe comparar:
- ejemplo del origen;
- regla acordada de transformación o tratamiento;
- representación en la tienda de destino;
- registros relacionados o identificadores externos;
- funcionamiento empresarial esperado;
- tratamiento de excepciones;
- decisión Aprobado, En observación o Bloqueante.
El cliente sigue siendo responsable de la verificación final. Es especialmente importante en el trabajo personalizado porque el criterio de aceptación suele depender de conocimiento empresarial que no puede deducirse únicamente del esquema de origen.
Una decisión En observación debe identificar la incertidumbre restante, su consecuencia empresarial, la información todavía necesaria y la persona responsable de resolverla. Sin esa interpretación, la validación personalizada se convierte en una lista de observaciones en lugar de una decisión de aceptación defendible.
Conclusión
Next-Cart Custom Service cubre las partes de una migración que requieren interpretación individual, lógica adaptada, Add-ons modificados, análisis de Custom Platform, relaciones no estándar o una representación diseñada para el destino.
El alcance personalizado más sólido empieza por el significado y la información disponible. Identifica quién es propietario de los datos, qué propósito empresarial continúa, cómo debe representar la tienda de destino el resultado, qué trabajo de migración es necesario, qué implementación permanece separada y cómo se demostrará la aceptación.
Custom Service no es una promesa de recrear todo el funcionamiento del origen. Es una forma estructurada de alcanzar el resultado viable y comprobable más cercano cuando el comportamiento compatible y los Standard Add-ons no son suficientes.
Preguntas frecuentes
¿Custom Service solo se utiliza para Custom Platforms?
No. También se aplica a campos personalizados, datos de terceros, identificadores externos, lógica a medida, Tailored Add-ons, Custom Add-ons y otros requisitos no estándar.
¿Todo campo personalizado requiere Custom Service?
No automáticamente. La decisión depende de si el campo está soportado, qué significado empresarial contiene, dónde debe representarse y si el comportamiento de mapeo disponible es suficiente.
¿En qué se diferencia Custom Service de un Standard Add-on?
Un Standard Add-on resuelve una necesidad compatible y acotada de filtrado, transformación o mapeo de campos. Custom Service cubre requisitos modificados, no compatibles o a medida que necesitan un alcance adaptado.
¿Custom Service siempre incluye Expert Handle?
No. El proyecto puede seguir siendo dirigido por el cliente. Expert Handle solo se incluye cuando la ejecución dirigida por especialistas forma parte del alcance personalizado aceptado.
¿Custom Service puede reproducir exactamente todo el funcionamiento del origen?
No. El resultado depende del estado de los datos de origen, la capacidad de la plataforma de destino, el alcance aceptado y la información necesaria para que el cliente apruebe el resultado.
¿Qué información se necesita para una solicitud de Custom Service?
Se necesitan registros representativos, propiedad y propósito empresarial, representación prevista en el destino, reglas de transformación o relaciones, excepciones, sistemas relacionados y ejemplos de validación.
¿La implementación en la plataforma de destino está incluida automáticamente?
No. El diseño, la instalación de aplicaciones, el despliegue de integraciones y la configuración operativa permanecen separados salvo que se incluyan expresamente en el alcance aceptado.
¿Por qué el importe de Custom Service es un precio inicial?
Establece el mínimo de capacidad de Standard Service correspondiente al Entity Points Plan seleccionado. El total final depende del trabajo personalizado acordado, los Add-ons, Expert Handle cuando esté incluido y otros costes específicos del alcance aceptados. Para trabajo posterior aceptado, el importe ya pagado sigue reconociéndose y solo se cobra la diferencia adicional.