7 min. de lectura
La migración a S/4HANA domina la agenda de TI. Pero mientras las empresas invierten miles de millones en nuevos sistemas, los antiguos suelen seguir activos. Esto cuesta dinero, genera riesgos de cumplimiento normativo y consume recursos que escasean en otros frentes. La desactivación controlada de datos (Data Decommissioning) resuelve este problema, pero se olvida sistemáticamente en la mayoría de los proyectos de migración.
Lo más importante en breve
- Casi la mitad de los usuarios de SAP en países de habla alemana seguirán operando sus sistemas ECC más allá de 2027, a pesar de que el soporte estándar finaliza (encuesta DSAG, febrero de 2026).
- El mantenimiento de sistemas heredados suele consumir típicamente el 15 por ciento del presupuesto de TI destinado a sistemas que ya no se necesitan operativamente.
- En la región de habla alemana prácticamente no existe contenido editorial independiente sobre la desactivación de datos. El tema está poco tratado, aunque la presión para actuar aumenta.
- Las soluciones modernas de archivado histórico permiten un acceso seguro y conforme a auditorías a los datos heredados como SaaS, sin necesidad de mantener operativos los sistemas de origen.
SAP ECC: El soporte se acaba, pero los sistemas permanecen
SAP ha comunicado claramente la cronología. Para las versiones de ECC EHP 0 a 5, el soporte estándar ya finalizó a finales de 2025. Las versiones EHP 6 a 8 lo harán a finales de 2027. A partir de entonces, solo quedará el mantenimiento extendido, con un recargo del 9 por ciento sobre los costes de licencia anteriores.
La realidad, sin embargo, difiere de la hoja de ruta. Según una encuesta de la DSAG (Asociación Alemana de Usuarios de SAP) de febrero de 2026, casi la mitad de los usuarios de SAP en países de habla alemana planean seguir operando sus sistemas ECC más allá de 2027. Los motivos son comprensibles: las migraciones a S/4HANA tardan más de lo previsto, superan el presupuesto asignado y requieren la dedicación exclusiva de los mejores profesionales del equipo.
Lo que suele pasarse por alto: incluso las empresas que migran con éxito a S/4HANA a menudo mantienen activos los sistemas antiguos. La operativa diaria puede haberse trasladado, pero los datos históricos deben seguir siendo accesibles. Las normativas GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff – Principios para la gestión y conservación ordenada de libros, registros y documentos en formato electrónico, así como para el acceso a los datos) exigen hasta diez años de acceso auditado. Los plazos de eliminación bajo el RGPD también deben cumplirse. Y en transacciones de fusiones y adquisiciones, reclamaciones por garantías pueden exigir acceso a datos antiguos incluso años después.
Definición
Data Decommissioning (Desmantelamiento de datos) designa el proceso estructurado mediante el cual se desactivan de forma controlada los sistemas IT post-productivos. Los datos almacenados en ellos se transfieren a un sistema de historización independiente, que garantiza el acceso auditado sin necesidad de mantener operativo el sistema original.
El paso olvidado: qué ocurre después del Go-Live
Una migración a S/4HANA consta de dos mitades. La primera recibe toda la atención, el presupuesto y los equipos de proyecto: migración de datos, personalización, pruebas y puesta en producción. La segunda mitad se pospone: ¿qué pasa con los sistemas heredados?
En la práctica, esto significa que instancias ECC, sistemas Navision, aplicaciones AS/400 y entornos mainframe siguen activos en el centro de datos. Consumen licencias, recursos de servidor y capacidad administrativa. Se siguen aplicando parches, aunque ningún usuario trabaje ya productivamente con ellos. El conocimiento sobre estos sistemas se va perdiendo, mientras los costes permanecen constantes.
Los responsables de TI conocen este problema. Pero rara vez existe un presupuesto dedicado específicamente a “apagar sistemas antiguos”. El desmantelamiento no aparece en ninguna hoja de ruta, porque no aporta nuevas funcionalidades ni genera un caso de negocio que quepa en una diapositiva. Sin embargo, la cuenta es sencilla: cada euro que no se gasta en mantener sistemas obsoletos queda disponible para la innovación.
Tres escenarios típicos de desmantelamiento de datos
El desmantelamiento de datos aborda situaciones que los departamentos de TI en la región DACH (Alemania, Austria y Suiza) enfrentan con regularidad. Tres casos prácticos.
Escenario 1: Post-migración. Una empresa ha completado la transformación a S/4HANA y, al mismo tiempo, ha consolidado varios sistemas heredados. Los datos operativos de los últimos dos años ya han sido migrados. Sin embargo, los datos históricos procedentes de ECC y Navision deben seguir estando accesibles, ya que auditores externos, asesores fiscales y el departamento de auditoría interna necesitan consultarlos. En lugar de mantener ambos sistemas antiguos en funcionamiento, los datos se transfieren a un sistema de historización. El sistema fuente se apaga.
Escenario 2: Transacción de fusiones y adquisiciones. La empresa A vende una unidad de negocio a la empresa B. Los datos operativos se migran, pero ambas partes deben seguir teniendo acceso a los datos históricos, entre otras razones para gestionar reclamaciones por garantías y cumplir con la normativa GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff – principios para la gestión y conservación adecuada de libros, registros y documentos en formato electrónico, así como para el acceso a los datos). Una copia completa del sistema sería la solución costosa; una herramienta de historización que conserve los datos de forma auditada y mantenga el acceso lógico es la alternativa más ágil.
Escenario 3: Desalojo del centro de datos. Los servidores deben ser retirados del centro de datos antes de fin de año. En un sistema AS/400 y un mainframe reposan datos históricos críticos para el negocio que, por motivos regulatorios, no pueden eliminarse. Las aplicaciones no son compatibles con la nube. La solución: exportar los datos, almacenarlos en una herramienta de historización basada en la nube y apagar el hardware antiguo.
Cómo funciona la desactivación moderna
El enfoque ha cambiado en los últimos años. Anteriormente, el estándar era el archivado nativo de SAP mediante ILM (Information Lifecycle Management) o el funcionamiento de copias de solo lectura. Ambos enfoques tienen límites: ILM es complejo, requiere licencias SAP activas y solo cubre datos de SAP. Las copias de solo lectura deben ser parcheadas y administradas continuamente.
Plataformas modernas de historización, como Historia de SDD Group, siguen un enfoque diferente. Los datos se exportan del sistema de origen y se almacenan en un repositorio basado en la nube. El acceso se realiza a través de una aplicación web que replica la lógica empresarial del sistema anterior. Los usuarios ven los datos en la estructura familiar, aunque el sistema de origen ya no exista.
El modelo de precios se basa en el volumen de almacenamiento, no en el número de usuarios. Usuarios ilimitados, inicio de sesión único (Single Sign-On) y control de acceso basado en roles. Para los departamentos de TI, esto significa: sin costes recurrentes por licencias de sistemas heredados, sin sobrecarga administrativa y sin gestión de parches para software fuera de soporte.
Un gestor de retención garantiza que se cumplan los plazos de eliminación conforme al RGPD (Reglamento General de Protección de Datos de la UE) y que los datos se borren o anonimicen automáticamente tras expirar el período obligatorio de conservación. En sectores regulados como servicios financieros y farmacéutico, las autoridades supervisoras verifican activamente este cumplimiento.
Por qué este tema debe estar ahora en la agenda
La combinación de la finalización del soporte de SAP, el aumento de los costes en la nube y los requisitos de cumplimiento normativo cada vez más estrictos genera una presión para actuar que no se puede ignorar. Quien siga operando sistemas ECC más allá de 2027 en modo de mantenimiento extendido pagará un 9 % más por un sistema que ya no recibirá nuevas funcionalidades.
Al mismo tiempo, crece la presión regulatoria. La conservación conforme a GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form – Principios para la gestión y conservación ordenadas de libros, registros y documentos en formato electrónico), las obligaciones de eliminación bajo el RGPD y normativas sectoriales como DORA en el ámbito financiero convierten la historización estructurada de datos en una obligación. “Seguir así sin hacer nada” no es una estrategia de cumplimiento.
Para directores de TI y CIOs, el desmantelamiento de sistemas legacy no es un tema glamuroso. No aporta innovación, ni funciones de IA, ni proyectos estrella para la próxima presentación ante el comité ejecutivo. Pero libera presupuesto, reduce riesgos y simplifica el entorno tecnológico. Son estos los temas que marcarán la diferencia dentro de doce meses.
Seguir operando sistemas legacy
- ✗ Costes continuos de licencia sin uso productivo
- ✗ Gestión de parches para software fuera de ciclo de vida
- ✗ Conocimiento decreciente en el equipo
- ✗ Riesgo de seguridad por sistemas sin actualizar
- ✗ A partir de 2028: +9 % por mantenimiento extendido
Desmantelamiento con historización
- ✓ Hasta un 80 % de ahorro en costes
- ✓ Acceso auditado y seguro a todos los datos históricos
- ✓ Sin sobrecarga de hardware ni administración
- ✓ Eliminación conforme al RGPD, automatizada
- ✓ Reducción de CO₂ al apagar servidores
Preguntas frecuentes
¿Qué es la desactivación de datos (Data Decommissioning)?
La desactivación de datos se refiere al proceso estructurado de apagar sistemas heredados y transferir los datos que contienen a un sistema independiente de archivo o historización. El objetivo es mantener el acceso a los datos históricos sin necesidad de seguir operando el sistema fuente.
¿Cuánto dura un proyecto típico de desactivación?
La implementación depende de la complejidad del sistema fuente y del volumen de datos. En entornos SAP estandarizados, un proyecto puede completarse en pocas semanas. Los entornos más complejos con múltiples sistemas heredados pueden requerir entre tres y seis meses.
¿Cuánto cuesta simplemente seguir manteniendo los sistemas heredados?
Las estimaciones del sector indican que el mantenimiento de sistemas heredados consume aproximadamente el 15 % del presupuesto de TI. A esto se suman costes indirectos: gastos de personal para administración, riesgos de seguridad por sistemas sin parches y costes de oportunidad derivados de recursos inmovilizados.
¿Es relevante la desactivación de datos solo para sistemas SAP?
No. Soluciones de historización como Historia admiten, además de SAP, sistemas no SAP como Navision, aplicaciones AS/400, aplicaciones mainframe y otras bases de datos heredadas. El enfoque es independiente del sistema.
¿Qué requisitos de cumplimiento normativo aborda la desactivación?
La GoBD (principios de contabilidad digital en Alemania) exige hasta diez años de acceso seguro a datos relevantes para la empresa. El RGPD exige la eliminación de datos personales tras el vencimiento de su propósito de tratamiento. Normativas sectoriales como DORA en el ámbito financiero endurecen aún más estos requisitos. Las plataformas modernas de historización abordan los tres ámbitos.
Recomendaciones de lectura del equipo editorial
Migración a SAP S/4HANA: 5 preguntas que todo CTO debería hacerse
Fuente de la imagen principal: FLUX.2 / Cloudflare Workers AI