Fin de vida, transición de versión y cese de la suscripción

10.1 Resumen y propósito

Este capítulo establece el marco integral que regula el ciclo de vida de fin de vida (EOL) de la Plataforma ProjectVIEW ERP, incluidas las transiciones de versión principal, los servicios de migración, las obligaciones de reentrenamiento, la adopción de integraciones y personalizaciones, los derechos de devolución de datos y los procedimientos de cese de la suscripción. Sustituye y amplía las disposiciones resumidas de Chapter 4, §4.7.4.

El marco de EOL del Proveedor se basa en las prácticas maduras de transición de versiones de los principales proveedores empresariales de SaaS y ERP, entre ellos SAP S/4HANA, Oracle Fusion Cloud, IFS Cloud y Infor CloudSuite, adaptado al modelo de despliegue soberano privado dedicado del Proveedor y al derecho del Cliente a la plena titularidad de los datos (Chapter 9, §9.9).

El principio de diseño fundamental es que ningún Cliente se quede atrás: cada Cliente recibirá un aviso suficiente, apoyo integral para la migración, reentrenamiento y servicios de devolución de datos, con independencia de que elija pasar a la versión sucesora o cancelar la suscripción.

10.2 Alcance

Este capítulo cubre:

• (a) Fases del ciclo de vida de la versión: Disponibilidad General (GA), Soporte Estándar, Soporte Ampliado, Fin de Ingeniería (EOE) y Fin de Vida (EOL) para cada versión principal de la Plataforma.
• (b) Servicios de migración: Migración de datos liderada por el Proveedor, transformación de esquema, aprovisionamiento de entornos y planificación del corte para los Clientes que pasen a una versión sucesora.
• (c) Reentrenamiento y gestión del cambio: Programas de formación obligatorios, recertificación de Champions, talleres de adopción por los usuarios y actualizaciones de la base de conocimiento necesarias para una transición de versión exitosa.
• (d) Adopción de integraciones y personalizaciones: Evaluación, rediseño y validación de las integraciones, personalizaciones y configuraciones específicas del Cliente en la versión sucesora.
• (e) Devolución de datos para Clientes que no actualizan: Obligaciones de exportación de datos, especificaciones de formato, plazos de entrega y documentación de cadena de custodia para los Clientes que decidan no realizar la transición.
• (f) Cese de la suscripción: Procedimientos formales de retirada del servicio, desmantelamiento del entorno y terminación contractual.
• (g) Funciones y responsabilidades: Asignación RACI para todas las actividades de EOL en las organizaciones del Proveedor y del Cliente. Este capítulo no cubre versiones/actualizaciones incrementales dentro de una versión principal (véase Chapter 4, §4.7.1) ni las actualizaciones de la plataforma COTS realizadas durante el Soporte Estándar (véase Chapter 4, §4.7.3).

10.3 Fases del ciclo de vida de la versión

Cada versión principal de la Plataforma (por ejemplo, v11, v12) avanza a través de un ciclo de vida definido. El modelo de ciclo de vida del Proveedor se basa en los marcos de soporte de versiones publicados por SAP (Maintenance Strategy), Oracle (Sustaining Support), IFS (Mainstream/Extended Maintenance) e Infor (Product Lifecycle Policy), adaptados al modelo de entrega solo SaaS del Proveedor:

Compromiso clave: El Proveedor garantiza un mínimo de doce (12) meses entre el Anuncio de EOL y la Fecha de EOL. Ningún Cliente estará obligado a realizar la transición en menos de 12 meses desde la fecha de la notificación formal por escrito. Esto se ajusta a las mejores prácticas observadas en las políticas de ciclo de vida de SAP, Oracle, IFS e Infor.

10.4 Anuncio de EOL y comunicación al Cliente

El Proveedor comunicará el ciclo de vida de EOL a cada Cliente mediante el siguiente programa estructurado:

10.5 Servicios de migración

El Proveedor prestará un programa estructurado de migración para cada Cliente que pase a la versión sucesora. Los servicios de migración están incluidos en la suscripción sin coste adicional para el alcance estándar de migración definido a continuación. Los servicios de migración ampliados, por ejemplo, ingesta de datos de sistemas heredados, transformaciones ETL complejas, operación en paralelo más allá del período estándar, están disponibles como encargos con alcance independiente.

10.5.1 Alcance estándar de migración

• (a) Aprovisionamiento del entorno: El Proveedor aprovisionará un entorno de versión sucesora dentro del tenant soberano privado Azure dedicado del Cliente, configurado con los mismos controles de seguridad, red y cumplimiento que el entorno de producción existente.
• (b) Migración de datos: Migración completa de todos los Datos del Cliente desde la base de datos de la versión heredada a la base de datos de la versión sucesora, incluidos los datos maestros, los datos transaccionales, los datos de configuración y los registros de auditoría. El Proveedor utilizará scripts automatizados de transformación de esquema validados contra el perfil de datos del Cliente.
• (c) Asesoramiento sobre depuración de datos: En consonancia con las mejores prácticas de Oracle Fusion e Infor CloudSuite, el Proveedor asesorará al Cliente sobre oportunidades de depuración de datos antes de la migración. El enfoque recomendado es migrar no más de tres (3) años de datos transaccionales activos, dejando los datos históricos archivados en formato de solo lectura y accesibles para informes y cumplimiento.
• (d) Migración de configuración: Todas las configuraciones específicas del Cliente (roles, flujos de trabajo, cadenas de aprobación, reglas de notificación, plantillas de informes, paneles de control) se migran a la versión sucesora mediante las herramientas de exportación/importación de configuración del Proveedor.
• (e) Pruebas de migración: Se ejecutarán como mínimo dos (2) simulacros completos de migración en el Entorno de Staging antes del corte a producción. Cada simulacro incluye verificación de integridad de datos, tanto referencial como computacional y temporal, pruebas rápidas de la capa de aplicación y pruebas comparativas de rendimiento.
• (f) Ejecución del corte: Corte a producción a la versión sucesora durante una ventana de mantenimiento previamente acordada, incluida la transición de DNS/red, el cambio de base de datos, la verificación posterior al corte y la preparación para reversión.
• (g) Periodo de hypercare: Un mínimo de treinta (30) días naturales de soporte hypercare dedicado posterior a la migración, durante los cuales el Proveedor asignará un Migration Lead y recursos de soporte dedicados para la resolución prioritaria de incidencias y la estabilización.

10.5.2 Garantía de integridad de la migración de datos

El Proveedor aplicará los siguientes controles de integridad de datos durante todo el proceso de migración, alineados con el marco de pruebas potenciado por IA definido en Chapter 5 (Software Quality & Testing):

• (a) Línea base previa a la migración: Se captura inmediatamente antes del inicio de la migración un hash criptográfico (SHA-256) de la base de datos completa y del inventario de recuento de filas, estableciendo la línea base de integridad de los datos.
• (b) Conciliación posterior a la migración: Se ejecutan sobre la base de datos de la versión sucesora conciliaciones de recuento de filas, aserciones de integridad referencial y comprobaciones de integridad computacional. El hash posterior a la migración se compara con la línea base previa a la migración.
• (c) Validación mediante agente de IA (opcional): Cuando el Cliente haya contratado el servicio de Pruebas Potenciadas por IA (Chapter 5), el Proveedor desplegará agentes de IA en el entorno de la versión sucesora para ejecutar escenarios de simulación de extremo a extremo, validando flujos de datos, reglas de negocio y puntos de integración.
• (d) Aprobación de la migración: El Cliente realizará UAT en el entorno de la versión sucesora. Se requiere la aprobación por escrito del Cliente antes del corte a producción, en consonancia con los requisitos de UAT definidos en Chapter 5, §5.8.

10.6 Adopción de integraciones y personalizaciones

Las transiciones de versión principal pueden afectar a las integraciones, personalizaciones y extensiones de terceros específicas del Cliente. El Proveedor gestionará esta transición mediante un programa estructurado de adopción:

10.6.1 Evaluación del impacto de las integraciones

Dentro de los treinta (30) días naturales posteriores al Anuncio de EOL, el Proveedor entregará al Cliente una Evaluación del Impacto de las Integraciones que cubra:

• (a) Análisis de compatibilidad de API: Mapeo de todas las API orientadas al Cliente utilizadas en la versión heredada a sus equivalentes en la versión sucesora, identificando cambios incompatibles, endpoints obsoletos y nuevas capacidades.
• (b) Inventario de integraciones de terceros: Catálogo de todas las integraciones activas (middleware, conectores B2G, APIs de envíos, interfaces bancarias, herramientas de reporting de terceros) con el estado de compatibilidad para la versión sucesora.
• (c) Registro de personalizaciones: Inventario completo de las personalizaciones específicas del Customer (DLL compiladas, funciones SQL personalizadas, informes a medida, extensiones de workflow) con clasificación de ruta de migración: (i) compatible con versiones futuras, (ii) requiere reingeniería, (iii) obsoleta / existe sustituto disponible.
• (d) Estimación de esfuerzo y cronograma: Esfuerzo indicativo (persona-días) y cronograma para reingenierizar las integraciones y personalizaciones no compatibles, distinguiendo entre alcance estándar (incluido) y alcance ampliado (cotizado por separado).

10.6.2 Rediseño y validación

Para las integraciones y personalizaciones clasificadas como “requiere rediseño”:

• (a) Rediseño gestionado por el Proveedor: Cuando la personalización haya sido desarrollada originalmente por el Proveedor (registrada en el repositorio Git bajo la Client Branch del Cliente), el Proveedor rediseñará y probará el componente sin coste adicional como parte del alcance estándar de migración.
• (b) Integraciones gestionadas por el Cliente o por terceros: Cuando la integración haya sido desarrollada por el Cliente o por un tercero, el Proveedor deberá (i) proporcionar documentación técnica de la superficie API de la versión sucesora, (ii) poner a disposición el Entorno de Staging para pruebas y (iii) ofrecer asistencia opcional de servicios profesionales bajo modalidad de tiempo y materiales.
• (c) Pruebas de regresión de integraciones: Todas las integraciones migradas estarán sujetas a pruebas automatizadas de regresión en el Entorno de Staging antes del corte a producción, utilizando el marco de agentes de IA (Chapter 5) o scripts de prueba manuales, según se acuerde.

10.7 Reentrenamiento y gestión del cambio

Una transición de versión principal constituye un Cambio Significativo de la Plataforma y activa obligaciones obligatorias de reentrenamiento en virtud de Chapter 6 (Training & Knowledge Transfer). El Proveedor impartirá un programa de formación de transición adaptado que abarque:

10.7.1 Reevaluación de las necesidades de formación

Dentro de los sesenta (60) días naturales posteriores al Anuncio de EOL, el Proveedor llevará a cabo una Reevaluación de las Necesidades de Formación (TNRA) para identificar:

• (a) Nuevos elementos de la interfaz de usuario, flujos de trabajo y patrones de navegación, o cambios en ellos, en la versión sucesora.
• (b) Funcionalidades obsoletas y sus sustituciones.
• (c) Nuevas capacidades habilitadas por la versión sucesora (incluidas las funciones impulsadas por IA cuando corresponda).
• (d) Requisitos de formación específicos por rol basados en la configuración de módulos activos del Customer y en su estructura organizativa. El resultado de la TNRA es un Plan de Formación para la Transición, anexo al Plan de Migración, en el que se especifican las sesiones, duraciones, métodos de impartición y públicos objetivo.

10.7.2 Programa de formación de transición

Todas las sesiones de formación de transición se grabarán y se transcribirán mediante IA de conformidad con Chapter 6, §6.4.4. Las grabaciones y las transcripciones se publicarán en la Per-Client Training Wiki del Cliente (https://docs.projectview.wiki/[client]) dentro de los cinco (5) Días Hábiles siguientes a cada sesión.

10.7.3 Actualizaciones de la base de conocimiento

El Proveedor actualizará los siguientes recursos de conocimiento antes del corte a producción en la versión sucesora:

• (a) Wiki de formación por cliente: Todas las páginas específicas de módulo, guías de proceso y artículos de preguntas frecuentes actualizados para reflejar la interfaz de usuario, los flujos de trabajo y la terminología de la versión sucesora.
• (b) Centro de versiones de la plataforma: Notas de versión, guías de despliegue y referencias de configuración de la versión sucesora publicadas en.
• (c) Orientación en la aplicación: Indicadores de ayuda contextuales, enlaces de ayuda y sugerencias asistidas por IA actualizados para hacer referencia a la funcionalidad de la versión sucesora.

10.8 Decisión del Cliente: transición o cese

A más tardar seis (6) meses antes de la Fecha de EOL (es decir, T−6 meses), el Cliente notificará formalmente al Proveedor su elección de:

• (a) Opción A — Transición: Proceder con la migración a la versión sucesora. El Proveedor presta los Servicios de Migración (10.5), la Adopción de Integraciones (10.6) y el Reentrenamiento (10.7). La suscripción continúa sin interrupción en la versión sucesora bajo las condiciones comerciales existentes, salvo modificación por acuerdo mutuo por escrito.
• (b) Opción B — Cese de la suscripción: Optar por no realizar la transición. El Proveedor inicia el proceso de Cese de la Suscripción (10.9), incluida la devolución de datos (10.10), el desmantelamiento del entorno (10.11) y la terminación contractual (10.12). La suscripción finaliza en la Fecha de EOL o en la fecha de expiración del Soporte Ampliado, si se hubiera elegido. Si el Cliente no proporciona notificación por escrito dentro del plazo T−6, el Proveedor emitirá un recordatorio. Si no se recibe respuesta dentro de otros treinta (30) días naturales, el Proveedor considerará que el Cliente ha elegido la Opción A (Transición), y los Servicios de Migración continuarán.

10.9 Proceso de cese de la suscripción

Cuando el Cliente elija la Opción B (Cese de la suscripción), se aplicará el siguiente proceso:

10.10 Devolución de datos

El Cliente conserva en todo momento la titularidad exclusiva y excluyente de todos los Datos del Cliente (Chapter 9, §9.9). Tras el Cese de la Suscripción, las obligaciones de devolución de datos del Proveedor son las siguientes:

10.10.1 Formatos y entrega de exportación

• (a) Formatos de exportación estándar: archivo de copia de seguridad de SQL Server (.bak), CSV, JSON y/o XML. El Cliente puede solicitar cualquier combinación de formatos.
• (b) Plazo de entrega: Dentro de los dos (2) Días Hábiles siguientes a la recepción de una solicitud escrita válida del Cliente.
• (c) Método de entrega: Transferencia segura cifrada a través del endpoint SFTP designado por el Customer, un token SAS de Azure Blob Storage o soporte físico cifrado (entregado por mensajería con documentación de cadena de custodia).
• (d) Alcance de la exportación: Todos los Datos del Customer, incluidos: datos maestros, datos transaccionales, datos de configuración, pistas de auditoría, registros de seguimiento de cambios, adjuntos de documentos (blob storage) e informes generados por la aplicación.
• (e) Exportaciones múltiples: El Customer puede solicitar exportaciones múltiples durante el período de cese. Cada solicitud se atenderá en un plazo de 2 Business Days.

10.10.2 Validación de la devolución de datos

Tras cada exportación de datos:

• (a) Hash de integridad: El Proveedor entregará un hash criptográfico SHA-256 de cada conjunto de datos exportado, permitiendo al Cliente verificar la integridad de los datos al recibirlos.
• (b) Certificado de recuento de filas: El Proveedor entregará un certificado de recuento de filas que enumere el número de registros de cada tabla/entidad en la exportación, cruzado con la base de datos de producción en el momento puntual de la exportación.
• (c) Plazo de validación: El Customer dispone de catorce (14) días naturales desde la recepción para plantear una objeción relativa a la integridad o completitud de los datos. El Provider subsanará y volverá a exportar en un plazo de dos (2) Business Days a partir de cualquier objeción válida.
• (d) Aceptación tácita: Si el Customer no plantea una objeción dentro del plazo de validación de 14 días, la exportación se considerará aceptada.

10.10.3 Coste de la devolución de datos

La devolución de datos dentro del alcance estándar (exportación en formatos estándar mediante transferencia digital segura) está incluida en la suscripción sin coste adicional. Los siguientes servicios están disponibles con coste adicional, sobre una base de tiempo y materiales:

• (a) Transformación de los datos exportados a formatos no estándar (por ejemplo, transformaciones de esquemas específicos del sistema destino para su ingestión en un ERP sucesor).
• (b) Preparación de soporte físico y entrega por mensajería.
• (c) Ampliación de la ventana de exportación de datos más allá del plazo estándar de cese.
• (d) Asesoramiento técnico sobre mapeo de datos, scripting de migración o diseño de ETL para el sistema sucesor del Cliente.

10.11 Desmantelamiento del entorno

Una vez completada la devolución de datos y vencida la ventana de validación del Cliente, el Proveedor procederá a desmantelar el entorno soberano privado dedicado del Cliente:

• (a) Apagado de máquinas virtuales: Todas las VM del Cliente (producción y pruebas) se detienen, se eliminan las imágenes de disco y se liberan los recursos de cómputo.
• (b) Destrucción de bases de datos: Todas las bases de datos de SQL Server (producción, pruebas, copias de seguridad) se eliminan de forma permanente. Los registros de transacciones y los archivos de copia de seguridad en Azure Backup Vault se purgan.
• (c) Purgado de la cuenta de almacenamiento: Todos los contenedores de Azure Blob Storage, los file shares y el table storage asociados al Cliente se eliminan de forma permanente, incluidas las copias replicadas con GRS en la región secundaria.
• (d) Destrucción de claves de cifrado: Todas las claves, secretos y certificados de cifrado específicos del Cliente en Azure Key Vault se purgan (la anulación de la protección contra purga está autorizada por el CTO).
• (e) Limpieza de red: Las redes virtuales, los NSG, las direcciones IP públicas, los registros DNS y los certificados SSL/TLS asociados al Cliente se aprovisionan para su baja.
• (f) Actualización del CMDB: Todos los elementos de configuración relacionados con el Cliente se marcan como desmantelados en el CMDB del Proveedor.
• (g) Destrucción segura de datos: Toda la destrucción de datos se realiza de conformidad con NIST SP 800-88 (Directrices para la sanitización de soportes). El borrado criptográfico de Azure garantiza que los datos en el almacenamiento desmantelado sean irrecuperables.

NIST SP 800-88 Rev. 1: Directrices para la sanitización de soportes Destrucción de datos de Azure

10.12 Obligaciones subsistentes

Las siguientes obligaciones subsisten tras la terminación o expiración del Marco y continuarán en pleno vigor y efecto:

• (a) Confidencialidad: Las obligaciones mutuas de confidencialidad subsisten durante cinco (5) años a partir de la fecha de terminación (Capítulo 8, §8.11).
• (b) Propiedad intelectual: Todos los derechos de propiedad intelectual y las restricciones de licencia subsisten indefinidamente.
• (c) Obligaciones residuales de protección de datos: Las obligaciones de privacidad conforme al Capítulo 7 subsisten respecto de cualquier Datos Personales retenidos por el Proveedor en virtud de una obligación legal o regulatoria (Capítulo 7, §7.13).
• (d) Limitación de responsabilidad: Los topes y exclusiones de responsabilidad continúan aplicándose a las reclamaciones derivadas de hechos ocurridos durante el Plazo de Suscripción.
• (e) Resolución de controversias: La ley aplicable y las disposiciones de resolución de controversias continúan aplicándose a toda reclamación que surja de o en relación con el Marco.
• (f) Derechos de auditoría: El derecho del Cliente a auditar el cumplimiento de la destrucción de datos subsiste durante doce (12) meses a partir de la fecha del Certificado de Desmantelamiento.

10.13 Opción de Soporte Ampliado

En consonancia con los modelos de Soporte Ampliado ofrecidos por SAP (Mantenimiento Ampliado), Oracle (Sustaining Support), IFS (Mantenimiento Ampliado) e Infor (Mantenimiento Ampliado), el Proveedor ofrece un período opcional de Soporte Ampliado para los Clientes que requieran tiempo adicional para completar su transición:

(a) Disponibilidad: La Asistencia Extendida deberá solicitarse por escrito a más tardar sesenta (60) días naturales antes de la Fecha de Fin de Vida Útil. (b) Duración: Hasta doce (12) meses posteriores a la Fecha de Fin de Vida Útil, en incrementos trimestrales. (c) Alcance: Solo resolución de Incidentes P1 y P2 y parches críticos de seguridad. Sin desarrollo de funcionalidades, sin nuevas Solicitudes de Cambio, sin nuevas activaciones de módulos. (d) Precio: La Asistencia Extendida se factura con una prima del veinte por ciento (20 %) sobre el ARR vigente en ese momento, pagadera trimestralmente por adelantado. (e) Terminación: La Asistencia Extendida termina automáticamente al finalizar el período elegido. Todas las disposiciones de Cese de la Suscripción (§10.9–§10.12) aplican al vencimiento de la Asistencia Extendida.

10.14 Roles y responsabilidades (matriz RACI)

La siguiente matriz RACI asigna responsabilidades para las principales actividades de fin de vida entre los roles del Proveedor y del Cliente:

Leyenda: R = Responsable · A = Accountable · C = Consultado · I = Informado.

10.15 Registro de procesos

El siguiente registro de procesos cataloga todos los procesos formales definidos en este capítulo.

10.16 Esquema del flujo de procesos

El siguiente ciclo de vida en nueve etapas ilustra el flujo integral de la transición de versión y del cese de suscripción:

① Anuncio y comunicación de fin de vida → ② Preparación y evaluación de impacto → ③ Decisión del Cliente

(Transición / Cese)

↓

VÍA DE TRANSICIÓN: ④ Migración y reingeniería → ⑤ Reentrenamiento y gestión del cambio → ⑥

UAT y corte a producción

↓

VÍA DE CESE: ⑦ Exportación y devolución de datos → ⑧ Desmantelamiento del entorno → ⑨ Terminación

contractual

Etapa ① Anuncio y comunicación de fin de vida: El Proveedor emite el Anuncio formal de fin de vida ≥12 meses antes de la Fecha de fin de vida, iniciando el programa de comunicación estructurado (§10.4). Todos los Clientes reciben notificación por escrito, y el Account Manager programa la Evaluación de preparación para la migración (P-10.01).

Etapa ② Preparación y evaluación de impacto: El Proveedor entrega la Evaluación de preparación para la migración, la Evaluación de impacto en integraciones y la Reevaluación de necesidades de formación dentro de los 60 días posteriores al Anuncio de fin de vida (P-10.02, P-10.03, P-10.04).

Etapa ③ Decisión del Cliente: En T−6 meses, el Cliente elige formalmente Transicionar (Opción A) o Cese (Opción B). La opción predeterminada es Transición si no hay respuesta dentro de los 30 días siguientes al recordatorio (P-10.13).

Etapa ④ Migración y reingeniería (Vía de transición): La migración de datos, la migración de configuración y la reingeniería de integraciones se ejecutan en el entorno de pruebas con ≥2 simulacros (P-10.05, P-10.06, P-10.07).

Etapa ⑤ Reentrenamiento y gestión del cambio (Vía de transición): Se entrega el Programa de formación para la transición: sesiones informativas de Novedades, talleres prácticos, recertificación de Campeones y actualizaciones de la base de conocimiento (P-10.08, P-10.09).

Etapa ⑥ UAT y corte a producción (Vía de transición): El Cliente realiza UAT en la versión sucesora. La aprobación por escrito activa el corte a producción. A continuación, se aplica un período de Hypercare de 30 días (P-10.10, P-10.11, P-10.12).

Etapa ⑦ Exportación y devolución de datos (Vía de cese): El Proveedor exporta todos los Datos del Cliente dentro de los 2 Días hábiles de cada solicitud válida. Se permiten exportaciones múltiples. Con cada exportación se entrega un certificado de hash de integridad y recuento de filas (P-10.14, P-10.15).

Etapa ⑧ Desmantelamiento del entorno (Vía de cese): Tras el vencimiento de la ventana de validación y la llegada de la Fecha de fin de vida, el Proveedor destruye todos los recursos del Cliente conforme a NIST SP 800-88 y emite un Certificado de Desmantelamiento (P-10.16, P-10.17).

Etapa ⑨ Terminación contractual (Vía de cese): El Marco termina formalmente 30 días después del desmantelamiento. Las obligaciones subsistentes (confidencialidad, PI, protección de datos, responsabilidad, derechos de auditoría) continúan conforme al §10.12 (P-10.18 si el Soporte Ampliado estaba activo).