ECC 2027: por qué convertir y no reimplementar en utilities

El reloj de SAP ECC no se detiene por decreto de un CIO: se detiene porque SAP lo definió así. Para las utilities y empresas de oil & gas de América Latina que aún operan sobre ECC con Enhancement Packages 6 a 8, el mantenimiento mainstream termina el 31 de diciembre de 2027 (SAP, 2026). No es una falla del sistema —muchas de estas plantillas siguen sosteniendo facturación, corte, reconexión y atención de reclamos sin sobresaltos—, es una fecha de vencimiento contractual que obliga a decidir con tiempo, porque un programa ERP de este tamaño rara vez cabe en una ventana corta.

La tentación, frente a un plazo así, es tratar la migración como una oportunidad para “empezar de cero”. Pero para una utility con procesos meter-to-cash maduros y años de histórico regulatorio, esa no es necesariamente la ruta más segura. Esta pieza abre una serie de seis artículos sobre cómo convertir sin poner en riesgo la continuidad operativa; aquí se resuelve la primera pregunta, la de negocio, antes de tocar cualquier plan técnico.

El plazo no es el problema real

Es fácil leer 2027 como una alarma de “sistema roto”. No lo es. El propio calendario de SAP contempla una fase de mantenimiento extendido hasta 2030 para quienes califican, y después una maintenance customer-specific con alcance reducido (SAP, 2026). El verdadero problema no es técnico: es de gobierno del proyecto. Cuanto más tarde arranca la decisión, menos margen queda para planificar, presupuestar y ejecutar sin comprometer la operación diaria de medición y facturación.

Para una utility latinoamericana, esa operación diaria no es un detalle menor. Los ciclos de lectura, la conciliación de consumo, el corte y la reconexión, y la atención de reclamos ante el ente regulador corren sobre el mismo ECC que ahora hay que transformar. La pregunta que antecede a cualquier cronograma técnico es simple: ¿qué camino de transición preserva esa continuidad mientras se moderniza la plataforma?

Reimplementar o convertir: dos caminos, un mismo destino distinto

---
config:
  theme: base
  fontFamily: 'Inter Variable, system-ui, sans-serif'
  themeVariables:
    darkMode: true
    fontFamily: 'Inter Variable, system-ui, sans-serif'
    fontSize: '15px'
    background: '#111113'
    primaryColor: '#1A1A1D'
    primaryTextColor: '#F4F5F8'
    primaryBorderColor: '#00C2FF'
    secondaryColor: '#242428'
    tertiaryColor: '#1A1A1D'
    mainBkg: '#1A1A1D'
    secondBkg: '#242428'
    tertiaryBkg: '#2E2E33'
    lineColor: '#00C2FF'
    textColor: '#F4F5F8'
    titleColor: '#F4F5F8'
    nodeBorder: '#00C2FF'
    clusterBkg: '#1A1A1D'
    clusterBorder: '#2E2E33'
    edgeLabelBackground: '#242428'
    pie1: '#00C2FF'
    pie2: '#f59e0b'
    pie3: '#22c55e'
    pie4: '#59d7ff'
    pie5: '#f97316'
    pie6: '#ef4444'
    pieTitleTextColor: '#F4F5F8'
    pieSectionTextColor: '#F4F5F8'
    pieLegendTextColor: '#F4F5F8'
    pieStrokeColor: '#111113'
    pieOuterStrokeColor: '#111113'
---
flowchart TD
  A([¿Cómo transicionar desde ECC?]) --> B{Camino de transición}
  B -->|Nuevo| C[Rediseño de procesos desde cero]
  C --> D([Histórico y configuraciones no viajan automáticamente])
  B -->|Conversión| E[Transformación técnica del ECC existente]
  E --> F([Configuraciones, desarrollos e histórico se preservan])
  class A inicio
  class B decision
  class C,E proceso
  class D,F bueno
classDef inicio fill:#113d4f,stroke:#00C2FF,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

SAP Activate documenta tres escenarios de transición hacia S/4HANA —New Implementation, System Conversion y Landscape Transformation— cada uno con su propio recorrido dentro de una misma metodología (SAP Community, 2026). No son variaciones de matiz: son decisiones con consecuencias distintas sobre lo que la organización conserva y lo que reconstruye.

New Implementation —el camino greenfield— tiene sentido cuando la prioridad es rediseñar procesos desde cero y dejar atrás deuda técnica acumulada. Pero para una utility con procesos de facturación regulados, históricos de consumo que sustentan reclamos y auditorías, y desarrollos propios ya validados contra la normativa local, reconstruir desde cero implica volver a probar y volver a certificar todo eso en paralelo al día a día operativo.

System Conversion —el camino brownfield— parte del ECC existente y lo transforma técnicamente en S/4HANA, conservando configuraciones, desarrollos y datos históricos en el proceso (SAP Community, 2026). No es una renuncia a modernizar: es modernizar sin desconectar el hilo que conecta el consumo medido hoy con el histórico regulatorio de ayer. Para el ángulo de esta serie —continuidad meter-to-cash sostenida durante toda la conversión— System Conversion es la ruta que menos expone esa continuidad al riesgo, porque no exige reconstruir de cero los procesos que hoy ya funcionan.

Qué cambia con RISE: la frontera de responsabilidad se mueve

La decisión entre convertir o reimplementar no ocurre en el vacío técnico de siempre: hoy convive con la opción de contratar RISE with SAP, el modelo donde SAP entrega la infraestructura, el sistema operativo y la base de datos como servicio gestionado. Bajo RISE, SAP opera esa capa de infraestructura, mientras el cliente conserva la responsabilidad de la seguridad y la operación a nivel de aplicación (SecurityBridge, 2026).

Esa frontera importa para una utility en LATAM porque redefine dónde vive el trabajo del equipo interno. Ya no se trata de administrar servidores y parches de sistema operativo: se trata de gobernar roles, autorizaciones, integraciones y la lógica de negocio de IS-U que sostiene medición, facturación y corte/reconexión. El presupuesto y el equipo de TI dejan de mirar hacia abajo (infraestructura) para mirar hacia arriba (aplicación y procesos regulados). Esto no cambia la elección entre convertir o reimplementar, pero sí cambia qué recursos internos quedan disponibles para acompañar cualquiera de los dos caminos.

La lente meter-to-cash: el criterio que debería decidir

En utilities y oil & gas, la conversión no ocurre en un sistema aislado: ocurre debajo de flujos que no pueden detenerse. Los eventos de medición inteligente, las lecturas que alimentan la facturación, los procesos de corte y reconexión, y el mantenimiento de activos de red siguen corriendo mientras el proyecto de conversión avanza. Cualquier decisión de ruta que ignore esa continuidad —eligiendo, por ejemplo, reimplementar sin un plan claro de migración de histórico de consumo— traslada el riesgo del proyecto de TI directamente a la relación con el regulador y con el usuario final.

Por eso, antes de fijar cronograma, presupuesto o alcance técnico, la pregunta de negocio que abre esta serie es la que debe resolverse primero: ¿el camino elegido preserva el histórico y los procesos que hoy sostienen meter-to-cash, o los pone en pausa mientras se reconstruyen? Para la mayoría de las utilities latinoamericanas que llegan a este punto con procesos ya maduros, System Conversion bajo un contrato RISE responde mejor a esa pregunta que empezar de cero.

Lo que sigue

Elegir la ruta es el primer paso, no el plan. La siguiente pieza de esta serie entra en el terreno donde muchos proyectos de conversión se desvían del presupuesto original: por qué ningún plan de conversión vale sin correr primero el SAP Readiness Check.

Fuentes

• SAP Community — SAP Activate Methodology, 2026: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/sap-activate-methodology-empowers-you-transition-to-sap-s4hana-and-sap-bw/ba-p/13313037
• SecurityBridge — RISE with SAP Security, 2026: https://securitybridge.com/blog/rise-with-sap-security/
• SAP — Maintenance Strategy, Business Suite 7 / ECC, 2026: https://support.sap.com/en/offerings-programs/strategy.html