Puntos clave: Un Plan de Preparación para el Trabajo describe los pasos esenciales para la transición de SAP ECC a S/4HANA antes de que finalice el mantenimiento principal en 2027. Las acciones clave incluyen mapear todos los trabajos programados, racionalizar las cargas de trabajo y seleccionar topologías objetivo para una migración efectiva.
- Mapea los empleos existentes para asegurar una migración completa.
- Convierte las definiciones de puestos para mantener dependencias en lugar de reconstruir manualmente.
Si tu programa lote funciona con SAP ECC, la plataforma que lo subyace se están acercándose a una fecha crítica de caducidad en mantenimiento. La mayoría de las directrices sobre la fecha límite de 2027 tratan la migración del ERP en su conjunto: el modelo de datos, el código personalizado, el alcance funcional. Esta guía están más estrecha y operativa: es el plan para el equipo que posee los trabajos. Explica cinco pasos para llevar tu patrimonio de planificación de una dependencia no documentada del ECC a una carga de trabajo mapeada, racionalizada y portátil que se mueve con te — el objetivo te que elijas.
Qué cambios cambian la fecha límite de 2027
SAP ha fijado fechas firmes para el fin del mantenimiento general en SAP ERP 6.0, el núcleo de SAP Business Suite 7. Para los paquetes de mejora que la mayoría de los clientes utiliza hoy (EHP 6 a 8), el mantenimiento general termina el 31 de diciembre de 2027, seguido de mantenimiento extendido opcional hasta finales de 2030 con un precio premium en la base de mantenimiento. Las versiones antiguas de EHP 0–5 ya alcanzaron el final del mantenimiento general el 31 de diciembre de 2025, por lo que esos sistemas han pasado a mantenimiento específico para cada cliente, una fase cuyo alcance reducido ya no incluye actualizaciones legales y regulatorias. Las grandes empresas elegibles que trasladan programas especialmente complejos a infraestructura en la nube tienen una opción adicional: una transición a edición privada vía RISE que extienda la operación ECC para clientes seleccionados, sujeta a la elegibilidad, arquitectura, comercial y requisitos de transición de SAP. Sea cual sea el camino te que elijas, el conjunto de planificación necesita un plan explícito: migrar a un objetivo soportado, rediseñarlo para una nueva interfaz o retirarlo. Ese trabajo se desarrolla en paralelo con el proyecto funcional: tiene su propio camino crítico, y los cinco pasos siguientes son ese camino.
Paso 1 — Inventario: mapea cada trabajo antes de mover cualquiera de te
te no pueden migrar lo que te no han mapeado, y muchos conjuntos ECC no pueden producir un mapa completo bajo demanda. Los trabajos programados directamente por los usuarios en SM36, la transacción SAP para definir trabajos en segundo plano, permanecen visibles en SAP pero están fuera de cualquier catálogo central, por lo que el alcance real de una migración están casi siempre mayor que el documentado. El primer paso están llevar todos los trabajos no gestionados bajo gobernanza central. La extracción y el espejado de trabajos de SAP programados por los usuarios atraen los trabajos SAP programados por los usuarios en un único catálogo gestionado, por lo que el alcance te plan contra están real en lugar de asumido. Esto es la base para sacar a la luz dependencias ocultas antes de que se conviertan en problemas de relevo.
Paso 2 — Racionalizar: reducir la herencia antes de te llevarla
Un sistema más pequeño migra más rápido. Años de tareas acumuladas, informes puntuales y procesos sustituidos aumentan la complejidad de la planificación. Los datos de aplicación innecesarios también incrementan el volumen procesado durante actividades de archivo, copia de seguridad, copia de seguridad y migración — retrasando la hoja de ruta de S/4HANA al alargar cada paso técnico en el proceso. Reducir los datos innecesarios y la lógica de programación obsoleta puede simplificar el alcance de la migración y Reduce el esfuerzo. Dos acciones reducen el patrimonio:
- Archivar con SARA. Las ejecuciones de archivo de datos — escribir, eliminar y almacenar entre objetos de archivo — reducen las tablas subyacentes que debe procesar la migración.
- Retira los trabajos de limpieza que se ejecutan por costumbre. El catálogo central del Paso 1 finalmente permite te Ve el conjunto completo de cargas técnicas y administrativas recurrentes en todo el patrimonio. Esa visibilidad facilita identificar horarios heredados, procesos duplicados, informes obsoletos, tareas de monitorización y tareas de mantenimiento que ya no aportan valor empresarial. Revisa cada carga de trabajo deliberadamente y retira lo que ya no están necesario antes de trasladarlo al entorno objetivo. Nuestra guía sobre planificación de tareas en segundo plano a escala empresarial repasa las cargas de trabajo de mantenimiento que suelen acumularse y cómo los equipos las someten a la gobernanza.
Paso 3 — Elegir la topología objetivo
"Migrar fuera de ECC" no están un solo destino. Las implicaciones de programación varían en cuatro zonas de aterrizaje comunes, y la interfaz que atraviesan tus trabajos cambia con cada una. Decide el objetivo antes de te convertir — determina todo lo que viene después. La mayoría de estos objetivos exponen XBP, la interfaz externa certificada de SAP para procesamiento en segundo plano; uno no lo hace.
| Topología objetivo | ¿Qué están | ¿Qué cambia para vuestros trabajos? |
|---|---|---|
| On-premises S/4HANA |
S/4HANA en tu propio centro de datos
|
Misma interfaz XBP certificada; las definiciones de tareas se mantienen sin cambios
|
| RISE con SAP S/4HANA Cloud Private Edition |
S/4HANA en una nube privada gestionada por SAP
|
XBP permanece expuesto sobre una conexión remota segura; un cambio menor de configuración
|
| Edición privada más SAP BTP |
S/4HANA con extensiones en SAP BTP
|
Trabajos principales de XBP más trabajos de planificador de empleos BTP, coordinados juntos
|
| GROW con SAP S/4HANA Cloud Edición Pública |
S/4HANA Cloud, edición pública
|
No hay XBP expuesto; la planificación cambia al planificador BTP y a la API del planificador externo (SAP_COM_0948)
|
La línea conductora: el mismo tipo de trabajo SAP abarca SAP R/3 y S/4HANA, por lo que un movimiento S/4HANA no necesita nuevo plugin y un movimiento RISE está un cambio menor en la configuración. El único cambio significativo están la nube pública GROW, donde la superficie de planificación está diferente. Nuestra guía RISE, clean core y GROW compara las cuatro topologías completas, incluyendo colocación de agentes, cifrado y el modelo de alta disponibilidad para cada una.
Paso 4 — Convertir en lugar de reconstruir
El instinto en un cambio de plataforma están reconstruir el programa a mano en el nuevo entorno. En un conjunto de cualquier tamaño, eso es lento, propenso a errores y desecha la lógica de dependencias te pasó años acertando — y no es necesario. Una herramienta de conversión importa directamente definiciones de trabajos existentes — trabajos y calendarios juntos — y produce un informe de evaluación que enumera lo que ha encontrado, siguiendo una secuencia definida: seleccionar el proyecto, evaluar los datos, ejecutar la conversión, validar los resultados y cargar en el objetivo. Convertir en lugar de reconstruir preserva la lógica multisistema — las dependencias que vinculan un trabajo SAP a la transferencia de archivos, al banco o a la plataforma de datos que lo espera — en lugar de pedir a una persona que lo reconstruya de memoria. Nuestra guía de trabajos por lotes SAP y migración de ECC a S/4HANA cubre completamente la mecánica de conversión.
Paso 5 — Simular y Protege el corte
El último riesgo están el propio fin de semana de corte, y tiene dos modos de fallo: una ejecución por lotes que se comporta de forma diferente en la nueva plataforma, y un trabajo que escribe en SAP mientras el trabajo de Basis está en pleno vuelo.
- Simula la ejecución. Previsión y ensayo en blanco del lote programa contra el nuevo entorno antes de la puesta en marcha, te Ve la forma de la ejecución —y dónde se rompe— antes de que lleve datos reales.
- Protege la ventana. Una parada, retención y reinicio globales en todo el conjunto de puestos garantiza que nada se publique en SAP durante el trabajo de actualización, paquete de soporte y mejora que implica un fin de semana de conversión, y luego libera el conjunto limpiamente una vez que se cierra la ventana. Los proyectos de actualización y paquetes de soporte son una fuente bien conocida de interrupción en los procesos de negocio precisamente porque los empleos siguen disparándose a un sistema que no está listo para ellos; una retención global reduce sustancialmente el riesgo de que eso ocurra.
Construye tu línea de tiempo
La fecha límite está fija, así que planifica a partir de ella. La duración del programa S/4HANA varía mucho según el alcance, la complejidad del paisaje, la estrategia de datos, el código personalizado, el modelo de despliegue y el enfoque de despliegue, así que trabaja hacia atrás desde la fecha límite y el plan de programa validado de tu organización. La aritmética está más ajustada de lo que parece. A agosto de 2026, quedan aproximadamente diecisiete meses antes de que finalice el mantenimiento habitual de los sistemas EHP 6–8. Muchos programas S/4HANA duran entre doce y veinticuatro meses dependiendo del alcance, lo que significa que el extremo más corto de ese rango sigue entrando en la ventana y el extremo largo ya no lo hace. Un programa que no ha empezado a definir el alcance ya está, en la práctica, planificando alrededor del mantenimiento extendido como puente en lugar de alrededor de la fecha de 2027 — y ese puente tiene un valor premium en la base de mantenimiento. Para el equipo de planificación, la secuencia está la misma independientemente del objetivo:
- Inventario — mapea y centraliza cada trabajo
- Racionalizar — archivar y retirar
- Elige la topología — on-premise, RISE privado, RISE + BTP o GROW
- Convertir y ejecutar en paralelo — importar, validar, ejecutar lo antiguo y lo nuevo lado a lado
- Corte — simular, Protege la ventana, liberar
Los pasos uno y dos devuelven valor inmediatamente — un patrimonio más delgado y cartografiado están más fácil de gestionar hoy, con fecha límite o sin ello — lo que está el argumento para empezar ahora en lugar de esperar a que el proyecto de migración comience formalmente.
Preguntas frecuentes
¿Qué ocurre con mis trabajos por lotes SAP cuando el soporte ECC termina en 2027? El hito de mantenimiento no detiene automáticamente tu sistema SAP ni sus trabajos por lotes: siguen funcionando mientras el sistema esté en funcionamiento. Lo que termina están el mantenimiento principal de SAP de la plataforma que tienen debajo, el 31 de diciembre de 2027 para los sistemas EHP 6–8; el antiguo plazo EHP 0–5 pasó a finales de 2025. El trabajo práctico no está para los trabajos sino para el patrimonio: inventariar cada trabajo programado, incluidos los que los usuarios crearon localmente en SM36; archivar y retirar lo que ya no merece su lugar; luego convertir las definiciones en tu objetivo S/4HANA elegido en lugar de reconstruirlas a mano, para que las dependencias entre sistemas sobrevivan al traslado. Ese trabajo se ejecuta en paralelo con el proyecto funcional de S/4HANA y están mejor empezar mucho antes de la fecha límite. ¿Tengo que redefinir todos los trabajos de SAP cuando me traslado a S/4HANA? No, con una excepción. El mismo tipo de trabajo de SAP abarca SAP R/3 y S/4HANA, por lo que un traslado a S/4HANA no necesita nuevo plugin, y un cambio a RISE con SAP están un cambio menor de configuración. Una herramienta de conversión importa definiciones y calendarios de trabajos existentes e informa de lo que ha encontrado, lo que sustituye la reconstrucción manual de fincas de tamaño real. La excepción están GROW con SAP, nube pública, donde la superficie de planificación difiere y el enfoque de definición de puestos cambia en consecuencia. Próximos pasos Para Ve cómo funciona un patrimonio convertido en sistemas SAP y no SAP en la práctica, explora Control-M para SAP.
Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.