Se pide al responsable financiero que aplace una transición desde ECC porque «el soporte de SAP dura lo suficiente». Antes de aceptar esa propuesta, el CIO debe determinar qué versiones instaladas están cubiertas, bajo qué contrato y si la vía de migración prevista sigue siendo viable. Una fecha de mantenimiento, por sí sola, no responde a ninguna de esas cuestiones.
El resultado defendible de la planificación del mantenimiento de SAP ECC es un registro de cobertura de soporte y un hito de aprobación de financiación con fecha definida. Trata la cobertura del proveedor, la viabilidad operativa, las obligaciones de seguridad y la preparación para la migración como aprobaciones independientes. Aplazar es creíble solo cuando esas aprobaciones lo respaldan; iniciar la migración lo es solo cuando el programa tiene un alcance y un calendario ejecutables.
Determina la cobertura por versión, no te quedes con la fecha general
El resumen comercial del mantenimiento extendido de SAP distingue entre versiones de SAP ERP 6.0: el soporte estándar de los sistemas anteriores al enhancement package 6 finaliza el 31 de diciembre de 2025, mientras que los enhancement packages 6–8 tienen soporte estándar hasta el 31 de diciembre de 2027. No apliques la fecha más tardía a todas las instalaciones de ECC.
Empieza con un inventario de productos instalados bajo la responsabilidad del equipo de aplicaciones SAP. Registra la versión exacta del producto y el enhancement package y, después, comprueba el registro de mantenimiento correspondiente. SAP señala la Product Availability Matrix, o PAM, como el lugar donde verificar los plazos de mantenimiento de cada producto y versión. Conserva el registro consultado, su versión documental cuando esté disponible y la fecha de comprobación.
Utiliza la siguiente plantilla para cada producto o dependencia instalada. Mantén visibles las entradas pendientes de resolver, en lugar de asignar una supuesta fecha de vencimiento común a todo el entorno.
| Campo del registro | Evidencia que debe conservarse | Responsable |
|---|---|---|
| Alcance instalado | Producto, versión, enhancement package, instalación y procesos de negocio a los que da servicio | Responsable de aplicaciones SAP |
| Estado del mantenimiento | Registro de PAM correspondiente, fechas de cobertura confirmadas y fecha de verificación | Responsable de la plataforma SAP |
| Cobertura contractual | Contrato de soporte aplicable, anexo, alcance cubierto y condiciones comerciales | Compras y asesoría jurídica |
| Situación operativa y de seguridad | Cobertura de dependencias, requisitos de control, evidencias de recuperación y excepciones aceptadas | Responsables de operaciones y seguridad |
| Dependencias sin resolver | Bloqueo, evidencia necesaria, responsable de resolverlo y fecha límite | Responsable de la migración |
| Calendario de decisiones | Última fecha que permite decidir con un margen responsable, hito de financiación y supuestos de ambos | CIO y responsable financiero |
La evidencia específica de cada versión también debe regir cualquier propuesta de mejorar ECC mientras se aplaza la migración. El marco de inversión para mejorar o sustituir el ERP exige pruebas sobre la versión instalada y las condiciones comerciales pertinentes, en lugar de aceptar una afirmación general de que el producto admite un flujo de trabajo. Aplica ese mismo rigor a las afirmaciones de que el entorno actual puede seguir en servicio de forma segura.
Distingue entre cobertura contratable y una extensión supuesta
El resumen publicado por SAP describe un mantenimiento extendido opcional desde el 1 de enero de 2028 hasta el 31 de diciembre de 2030. Para clientes con instalaciones locales, requiere un anexo independiente a un contrato de soporte SAP activo y se aplica al conjunto del entorno comercial de aplicaciones principales de Business Suite 7. Que exista una opción no demuestra que tu empresa la haya contratado.
La distinción en el precio importa al justificar la financiación. SAP describe dos puntos porcentuales adicionales sobre la base de mantenimiento de las aplicaciones principales y los complementos cubiertos, no simplemente un aumento del dos por ciento en la factura de soporte existente. Pide a compras que concilie la base cotizada y el alcance cubierto con el registro. Una «provisión para soporte extendido» sin explicar no es un supuesto presupuestario suficiente.
Mantén separados los acuerdos de transición posteriores. En sus orientaciones para planificar más allá del mantenimiento extendido, SAP describe Transition Option for SAP ERP como una suscripción sujeta a condiciones para clientes grandes y complejos que cumplan los requisitos y cuya transformación esté en marcha, concebida para cubrir el periodo 2031–2033. Los sistemas deben trasladarse a SAP ERP, private edition sobre SAP HANA antes del 31 de diciembre de 2030; se aplican requisitos adicionales de elegibilidad y quedan excluidas las capacidades que dependen de Java.
No se trata de una extensión incondicional para un entorno ECC local sin cambios. Si una propuesta de aplazamiento depende de esta opción, exige confirmar la elegibilidad, la disponibilidad para contratarla, el precio, las capacidades cubiertas y las condiciones vinculantes antes de incorporarla al calendario aprobado.
Obtén después decisiones independientes de operaciones y seguridad. Pide a operaciones que demuestre la capacidad de recuperación y quién se responsabiliza de las dependencias críticas. Pide a seguridad que identifique las correcciones y los controles necesarios, y que determine si el acuerdo de soporte propuesto proporciona lo que exigen esas obligaciones. No permitas que el derecho al mantenimiento sustituya ninguna de esas aprobaciones.
Planifica hacia atrás desde las restricciones de tu vía de migración
La última fecha responsable para aprobar la financiación debe calcularse a partir del trabajo y las restricciones, no restando una duración genérica de migración al vencimiento del mantenimiento. Primero determina la vía de transición prevista y el entorno de destino. Después exige al equipo de ejecución que identifique los prerrequisitos, las estimaciones, la secuencia y la incertidumbre de ese entorno concreto.
Una restricción de la vía de migración puede ser decisiva con independencia del derecho al soporte. SAP indica que las herramientas de conversión para sistemas Business Suite 7 sobre bases de datos de terceros solo estarán disponibles antes de que finalicen los acuerdos pertinentes de reventa y soporte en 2030. Después, solo se admitirán escenarios de transición greenfield, es decir, nuevas implantaciones. Para un entorno afectado, una propuesta de aplazamiento debe explicar, por tanto, si la conversión prevista sigue siendo ejecutable dentro de ese límite.
Pide al equipo un calendario basado en dependencias que contemple:
- Comprobaciones de compatibilidad de versiones y del destino, incluidos los complementos instalados y las aplicaciones conectadas.
- Evaluación del código personalizado y decisión sobre su tratamiento, con responsables asignados a las decisiones de negocio pendientes.
- Preparación de datos, cambios en interfaces y evidencias de aceptación de extremo a extremo.
- Infraestructura, aprobaciones comerciales, capacidad del personal interno y compromisos de ejecución.
- Ensayos de migración, ventanas permitidas para la puesta en producción, planificación de la recuperación y estabilización.
Son requisitos de evaluación, no afirmaciones de que todos los programas necesiten el mismo trabajo. Para las capacidades personalizadas que se conserven, utiliza una evaluación de ubicación de extensiones SAP independiente para resolver dónde deben ejecutarse. Incorpora sus bloqueos pendientes y sus estimaciones al calendario, sin convertir la planificación del mantenimiento en un diseño detallado de arquitectura.
Planifica hacia atrás a través de las dependencias críticas y reserva un margen de contingencia aprobado explícitamente para el trabajo sin resolver. Registra cuándo deben liberarse los fondos, no solo cuándo debería finalizar el programa. Si un prerrequisito no tiene responsable o una estimación creíble, la fecha de decisión resultante sigue siendo provisional.
Elige entre empezar ahora y aplazar con un plazo definido
Empezar ahora es la opción más sólida cuando la cobertura verificada o las restricciones de la vía de migración no dejan margen suficiente para el plan basado en dependencias, o cuando los requisitos para continuar operando no pueden satisfacerse en condiciones aceptables. «Empezar» no tiene por qué significar autorizar de inmediato toda la implantación. Cuando una incertidumbre relevante pueda cambiar la vía elegida, financia una evaluación acotada con un resultado definido y un hito de decisión.
Un aplazamiento con plazo definido es defendible cuando la cobertura contractual está confirmada, los responsables de operaciones y seguridad aceptan las obligaciones de continuidad y un calendario inverso creíble preserva la vía de transición prevista. Su aprobación debe identificar qué gana el negocio al esperar, qué debe financiar durante el aplazamiento y qué acontecimientos obligarían a adelantar la decisión.
Contrasta ambas opciones con los mismos resultados de negocio requeridos y el mismo horizonte de planificación. Incluye en el caso de aplazamiento el trabajo intermedio, la continuidad operativa y la transición posterior. Para empezar ahora, exige supuestos explícitos sobre la capacidad interna y las dependencias de ejecución, en lugar de considerar que un inicio más temprano demuestra por sí solo una menor exposición.
En el próximo hito de financiación, revisa conjuntamente el registro y el calendario inverso. Aprueba la migración, aprueba un aplazamiento con fecha y condiciones, o encarga una evaluación acotada de la incertidumbre concreta que impide decidir. No apruebes una fecha de vencimiento sin respaldo.
Si necesitas convertir esa decisión en paquetes de trabajo funcionales y técnicos, habla sobre el entorno, las dependencias y los requisitos de migración con los especialistas SAP de Digiventi.
