Preparación de un sistema SAP ERP para la migración a SAP S/4HANA: guía técnica de referencia
Esta guía técnica describe cómo preparar un sistema SAP ERP (SAP ECC) para su transición a SAP S/4HANA, con foco en los escenarios de migración, los requisitos
· 13 min de lectura
Esta guía técnica describe cómo preparar un sistema SAP ERP (SAP ECC) para su transición a SAP S/4HANA, con foco en los escenarios de migración, los requisitos técnicos previos, las herramientas de evaluación y las decisiones de gobierno que determinan el esfuerzo real de un proyecto. Está dirigida a arquitectos, líderes SAP Basis, responsables funcionales y decisores de utilities, oil & gas y empresas de tecnología en América Latina que operan SAP ECC y necesitan un criterio claro para planificar la conversión con base defendible y no sobre supuestos. El enfoque es de referencia: separa el concepto de los escenarios de su aplicación regional y de los anti-patrones que encarecen o ponen en riesgo la transición.
Fundamento conceptual
Por qué se migra y bajo qué calendario
SAP anunció hace tiempo el fin del soporte para SAP ERP y concentra las nuevas funcionalidades e innovaciones únicamente en SAP S/4HANA; por eso cada vez más empresas evalúan o ya están migrando su sistema [1]. Conviene precisar el matiz: la mayoría no convierte por el fin de soporte en sí, sino para incorporar nuevas capacidades; el calendario es el detonante, no el único motivo [1]. En la práctica regional, sin embargo, el calendario opera como una línea presupuestal. Para SAP ERP 6.0 (Business Suite 7) con Enhancement Packages 6 a 8, el mantenimiento mainstream finaliza el 31 de diciembre de 2027, con una fase opcional de mantenimiento extendido hasta el 31 de diciembre de 2030 que implica un recargo aproximado de dos puntos porcentuales sobre la base de mantenimiento; los Enhancement Packages 0 a 5 ya salieron de mainstream a fines de 2025 [2]. Ese horizonte define ventanas de planificación reales, dado que un programa ERP rara vez se diseña y ejecuta en pocos meses.
La base tecnológica del destino es SAP HANA, disponible desde 2011 y adoptada por el primer release de SAP S/4HANA en 2015, con un modelo de datos simplificado, analítica en tiempo real y mejoras de rendimiento [3]. Sobre esa base, SAP S/4HANA se posiciona como ERP inteligente cuyos pilares incluyen SAP HANA, la experiencia de usuario SAP Fiori, las tecnologías inteligentes y el valor del dato en tiempo real [4]. La línea de producto vigente documentada por SAP es SAP S/4HANA 2025, con una estrategia de mantenimiento que desde el release 2023 amplió la ventana mainstream y adoptó una cadencia de releases mayor cada dos años [2].
Los escenarios de transición
SAP define tres caminos para llegar a SAP S/4HANA. La nueva implementación (greenfield) reingenieriza los procesos sobre el estándar con migración de datos, y es aplicable tanto on-premise como en la nube [1]. La conversión de sistema (brownfield) convierte un sistema SAP ERP existente y solo aplica a sistemas on-premise [1]. La transformación de landscape con transición selectiva de datos (selective data transition) permite trasladar subconjuntos de datos y consolidar o dividir sistemas. La elección no es de preferencia estética: depende de cuánta funcionalidad actual tiene un sucesor compatible en el estándar y de cuánto se desea reingenierizar.
La conversión de sistema es el escenario idóneo para migrar un SAP ERP existente, en especial para empresas ya sobre las versiones más recientes de SAP ERP [1]. Su ventaja central es que se preservan la configuración, los datos transaccionales, el customizing y el código propio; en lugar de un proyecto big bang, es un proyecto técnico de conversión con algunas innovaciones seleccionadas, y más innovaciones pueden introducirse por fases después de la conversión [1]. Un punto que se subestima: aunque la conversión se perciba como mayormente técnica, requiere consultores funcionales y usuarios de negocio con conocimiento de las aplicaciones SAP en uso [1].
Requisitos técnicos previos
No todo sistema puede convertirse en un paso; existen múltiples prerrequisitos técnicos [1]. El release fuente mínimo soportado es SAP ERP 6.0; los sistemas por debajo de ese nivel, o que aún no son Unicode, requieren un enfoque de dos fases: primero se actualiza a un release fuente soportado y se convierte a Unicode, y luego se convierte a SAP S/4HANA en una segunda fase [1]. En la documentación vigente, el sistema debe ser Unicode y los sistemas de doble stack (dual-stack) no están soportados [5]. Además, todos los add-ons y business functions —incluidos los de terceros— deben verificarse por compatibilidad antes de convertir [1].
flowchart TD
A([Sistema SAP ERP a convertir]) --> B{¿Release fuente ERP 6.0 y Unicode?}
B -->|Sí| C[Conversión en un paso con SUM]
C --> D([SAP S/4HANA])
B -->|No| E[Fase 1 actualizar a release soportado y convertir a Unicode]
E --> F[Fase 2 conversión a SAP S/4HANA]
F --> D
class A inicio
class B decision
class C,E,F proceso
class D bueno
classDef inicio fill:#30274d,stroke:#8b5cf6,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff
La conversión técnica se ejecuta con la herramienta Software Update Manager (SUM); si el sistema aún no está sobre SAP HANA, el propio SUM se encarga de la migración de base de datos [5]. La Database Migration Option (DMO) del SUM combina en un procedimiento de un solo paso la migración de base de datos, la actualización de software y la conversión de datos, y la variante System Move añade el traslado a un nuevo centro de datos o hyperscaler [6]. El Maintenance Planner calcula la ruta de actualización y valida que los componentes tengan un camino válido [6].
Aplicación práctica
En utilities, oil & gas y tecnología en América Latina, la preparación se aterriza sobre prioridades regionales: continuidad operativa, recaudación, control de pérdidas no técnicas, cumplimiento regulatorio y modernización con presupuesto acotado. La disciplina de preparación no es un gasto opcional: es lo que convierte un proyecto con sorpresas en uno con alcance defendible. La secuencia de evaluación, expresada como flujo, suele ser la siguiente:
- Ejecutar el SAP Readiness Check sobre el sistema productivo, que analiza configuración, datos y uso para identificar los Simplification Items relevantes, la compatibilidad de add-ons y business functions, el impacto en el código propio y el dimensionamiento [7].
- Correr el Simplification Item Check (SI-Check) para evaluar la relevancia y consistencia de cada item contra los datos del propio sistema, complementado con los custom-code checks [7].
- Consultar el Simplification Item Catalog para el detalle de cada cambio disruptivo entre SAP ERP y SAP S/4HANA; el catálogo es completo, por lo que conviene partir del Readiness Check, que aísla automáticamente los items aplicables y enlaza a las SAP Notes más recientes [7].
- Dimensionar y planificar el hardware o la infraestructura destino, dado que la base de datos corre en memoria [6].
- Cuantificar la remediación de código y las actividades manuales específicas de aplicación que señalan los checks, y recién entonces presupuestar.
El Readiness Check y el SI-Check son complementarios: el primero da la vista amplia de preparación en la fase inicial; el segundo aporta el detalle de los cambios específicos en la fase de planificación [7]. Para una utility LATAM, este orden importa: dimensionar y presupuestar antes de correr estas herramientas equivale a estimar a ciegas, algo especialmente riesgoso cuando el presupuesto es acotado y el margen de error, mínimo.
Migración de datos cuando el escenario lo requiere
En nuevas implementaciones o transiciones selectivas, la carga de datos se realiza con el SAP S/4HANA Migration Cockpit, incluido en la licencia de SAP S/4HANA. La herramienta ofrece transferencia directa desde sistemas fuente SAP, un migration object modeler para requisitos propios —introducido con la versión 1909—, validación automatizada de resultados, guía paso a paso, archivos plantilla por objeto y capacidades de depuración e integración con SAP Master Data Governance [8]. Conviene anticipar restricciones: la grabación de transacciones no es posible con las nuevas pantallas SAP Fiori, hay interfaces que cambian —como el Business Partner (CVI)— y ciertos programas estándar de Batch Input pueden dejar de funcionar porque la funcionalidad cambió o fue removida [9]. La alternativa histórica de SAP Rapid Data Migration con SAP Data Services sigue disponible, pero SAP ya no añade objetos de migración a esa herramienta y concentra la inversión en el Migration Cockpit, según la SAP Note 2287723 [9].
Extensibilidad y arquitectura destino
La conversión es también la oportunidad de repensar la arquitectura hacia un modelo listo para el futuro, con extensibilidad amplia sobre una plataforma de nube [10]. En el estado vigente, ese enfoque se materializa mediante extensiones side-by-side sobre SAP Business Technology Platform, que permiten cubrir requisitos propios sin recargar el núcleo. La regla de diseño regional es preferir el estándar y las capacidades predefinidas, y reservar la extensión para lo que el estándar genuinamente no resuelve.
Mejores prácticas y consideraciones
La primera consideración es de clean core. Durante la conversión, las modificaciones a objetos estándar de SAP deben revisarse y devolverse al estándar siempre que sea posible, y la conversión es una oportunidad para limpiar código propio obsoleto y reducir la huella de datos mediante archiving [1]. Los custom-code checks contra los Simplification Items relevantes permiten consolidar una vista del código usado productivamente y eliminar lo que ya no se utiliza. Construir sobre lo que el estándar volvió innecesario, en lugar de remediarlo, es un anti-patrón que se paga en cada actualización posterior.
La segunda es evitar el sobrecosto por fraccionar el proyecto. Migrar primero a SAP HANA y luego, en un proyecto separado, a SAP S/4HANA reduce la complejidad de diagnóstico, pero implica dos proyectos, dobles ciclos de prueba y dos ventanas de indisponibilidad, con el consiguiente incremento de costo; convertir en un paso es preferible [1]. La conversión brownfield se parece a un upgrade de release, pero es bastante más involucrada porque SAP ERP y SAP S/4HANA pertenecen a familias de producto distintas [1]; subestimar esa diferencia es una fuente frecuente de desvíos.
La tercera es la gestión de las Compatibility Packages. Estas aseguran que puedan seguir usándose funcionalidades de SAP ERP que aún no existen en SAP S/4HANA [1], pero su derecho de uso es transitorio y está acotado en el tiempo según la SAP Note 2269324. Tratar esas funciones como permanentes es un riesgo: deben inventariarse y verificarse contra la nota vigente para confirmar hasta cuándo pueden usarse y qué exige su reemplazo.
La cuarta es de gobierno y continuidad, crítica en el contexto regulado de la región. La conversión no es solo un ejercicio de SAP Basis: requiere involucrar a las áreas funcionales y de negocio, planificar las ventanas de indisponibilidad para no comprometer procesos sensibles —facturación, recaudación, corte y reconexión— e incorporar tempranamente los requisitos de reporting regulatorio y de residencia de datos. La modernización con presupuesto acotado, norma en LATAM, no se logra recortando la preparación, sino ejecutándola primero y difiriendo la innovación a fases posteriores a la conversión [1]. El inventario de qué sobrevive al estándar, qué debe remediarse y qué requiere extensión es el primer entregable de un proyecto serio, no una nota al pie.
Referencias
- SAP S4HANA System Conversion Guide
- SAP Maintenance and Support Strategy (Business Suite 7 / SAP ERP 6.0) | SAP Support Portal — https://support.sap.com/en/offerings-programs/strategy.html
- Authorizations in SAP S4HANA and SAP Fiori
- SAP S4HANA Embedded Analytics
- Getting Started with SAP S/4HANA 2025 | SAP Help Portal — https://help.sap.com/doc/819cdef021e44d7aad27b31c8bb1ebfc/2025/en-US/START_OP2025.pdf
- Analyzing System Conversion | SAP Learning — https://learning.sap.com/courses/discovering-sap-activate-implementation-tools-and-methodology/analyzing-system-conversion
- Conversion Guide for SAP S/4HANA 2025 | SAP Help Portal — https://help.sap.com/doc/2b87656c4eee4284a5eb8976c0fe88fc/2025/en-US/CONV_OP2025.pdf
- SAP S/4HANA Migration Cockpit
- Migrating Data with the SAP S4HANA Migration Cockpit
- Customizing SAP S4HANA with SAP Cloud Platform
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
