Respuesta breve
Un archivo SAP existente no debería trasladarse a la nube en un Big Bang. Un camino de migración resiliente comienza por una inventariazión del existente, separa conceptualmente documentos, metadatos, enlaces SAP y, si procede, archivos de archivado SAP; define un piloto representativo y sólo permite una migración por oleadas y el cutover tras una validación documentada. Antes de apagar el sistema antiguo deben demostrarse integridad, localización (recuperabilidad), legibilidad, permisos, capacidad de análisis y la operación en el estado objetivo.
Para datos con relevancia fiscal no basta con un simple traslado de ficheros. Las GoBD exigen, en caso de cambio de sistema, una transferencia cuantitativa y cualitativamente equivalente de los datos sujetos a registro y conservación, incluidos metadatos, datos maestros y de movimiento y los enlaces necesarios. El sistema destino debe permitir los mismos análisis; en las transformaciones de datos no se debe alterar el contenido y cualquier cambio debe documentarse.[1]
Para la visión general son de ayuda los artículos SAP Archivierung in der Cloud – Anforderungen, Risiken und Lösungen y SAP ArchiveLink vs. CMIS: Warum Unternehmen jetzt handeln sollten. Esta lista de verificación se centra deliberadamente en la ejecución operativa con piloto, validación y aceptación.
Ámbito y límites
Esta lista de verificación describe un procedimiento para la migración de un escenario existente de repositorio de documentos o contenidos cercano a SAP hacia una solución objetivo en la nube. No es una guía de migración para cada versión de SAP ni constituye asesoramiento legal o fiscal.
| Esta página trata | Esta página no trata |
|---|---|
| Inventario y migración controlada de existencias documentales y archivísticas | Promesas generales sobre conformidad con GoBD, RGPD o derecho |
| Piloto, validación, cutover y transferencia operativa | Implementación técnica de todas las variantes ArchiveLink, CMIS, BTP o ILM |
| Pruebas de documentos, metadatos, enlaces, accesos y capacidad de explotación | Evaluación de plazos de conservación concretos sin revisión especializada |
| Preguntas de decisión y aceptación para equipos de proyecto | Compromisos sobre funcionalidad, SLA, precio o ubicación de datos de un proveedor específico |
Antes del inicio del proyecto: separar claramente los objetos del archivo
El término «archivo SAP» suele referirse a distintas cosas. Estas deben inventariarse y probarse por separado antes de la migración.
| Objeto del archivo | Pregunta típica en la migración | Evidencia requerida |
|---|---|---|
| Documentos y anexos | ¿Está el documento original completo y legible en el destino? | Comprobar recuperación, descarga, visualización y, si procede, formato original frente al origen. |
| Metadatos e índices | ¿Se han trasladado el tipo de documento, fecha, socio comercial, número de documento y otros criterios de búsqueda? | Validar mapeo de campos, campos obligatorios y realizar muestreos frente al origen. |
| Enlaces SAP | ¿Conduce el acceso desde el objeto de negocio SAP correspondiente al documento correcto? | Probar ID de objeto e ID de documento, tablas de enlaces o el mapeo y el re-enlace. |
| Permisos | ¿Sólo las personas autorizadas ven los contenidos? | Probar y registrar casos positivos y negativos de permisos por rol. |
| Archivos de archivado SAP y archivado de datos | ¿Se trata de documentos, archivos de archivado o datos gestionados por procedimientos SAP propios? | Responsable(s) de arquitectura y procesos deben definir procedimientos, rutas de lectura y pruebas de conservación. |
En las configuraciones ArchiveLink se gestionan por separado el repositorio de contenido, la Content-Repository-ID, las tablas de enlace, parámetros de conservación y permisos de usuarios.[2] Esta separación es importante también para la planificación de la migración: un documento transferido con éxito no basta si luego las tablas de enlace, los permisos o las rutas de recuperación no funcionan.
Fase 1: Definir gobernanza y la visión objetivo
Antes de la implementación técnica el proyecto necesita una visión objetivo común. Esta visión incluye no sólo el repositorio futuro, sino también responsabilidades, alcance, condiciones de aceptación y una ruta operativa.
| Decisión | Roles responsables | Resultado antes de la Fase 1 |
|---|---|---|
| ¿Qué sistemas, mandantes y clases de documento están en el alcance? | Área de negocio, arquitectura SAP, ECM/DMS | Lista de alcance aprobada incluyendo exclusiones. |
| ¿Qué reglas de conservación, bloqueo y eliminación son relevantes? | Área de negocio, cumplimiento, responsables fiscales/legales | Requisitos funcionales documentados; no asumir únicamente aspectos técnicos. |
| ¿Qué vía de integración se utilizará? | Arquitectura SAP, ECM/DMS, Seguridad | Decisión de arquitectura con versión y estado de interfaces. |
| ¿Quién revisa, quién aprueba y quién opera? | Dirección del proyecto, operación, seguridad de la información | RACI, vías de escalado y firmas de aceptación. |
| ¿Cuándo se apagará el sistema antiguo? | Dirección del proyecto, área de negocio, operación | Criterios Go-/No-Go y plan de retroceso definidos de antemano. |
Fase 2: Realizar el inventario del existente
Planificar la migración basándose sólo en tamaño de almacenamiento es insuficiente. Inventarice por sistema origen, como mínimo: repositorio, volumen de datos, clases de documento, formatos, metadatos, relación con objetos SAP, permisos, estado de conservación, interfaces y casos especiales conocidos.
Lista de verificación del inventario
- ¿Qué sistemas SAP, versiones y mandantes acceden al archivo?
- ¿Qué Content Repositories, enlaces ArchiveLink o endpoints CMIS están implicados?
- ¿Qué tipos de documento, formatos, volúmenes y tasas de crecimiento existen?
- ¿Qué metadatos, índices, versiones y enlaces a objetos de negocio SAP deben preservarse?
- ¿Qué roles necesitan visualización, descarga, archivado, administración o acceso de auditoría?
- ¿Qué contenidos tienen requisitos especiales de conservación, bloqueo, eliminación o protección de datos?
- ¿Qué documentos están técnicamente defectuosos, duplicados, bloqueados o sólo accesibles mediante procesos especiales?
- ¿Qué análisis, exportaciones y accesos de auditoría deben estar disponibles tras la migración?
El resultado es un protocolo de inventario con una cantidad total inequívoca y subconjuntos rastreables. Servirá después como punto de referencia para el piloto y la aceptación.
Fase 3: Diseñar la migración y plan de retroceso
Un diseño robusto define el tratamiento de cada clase de documento. Una buena planificación responde especialmente a cuatro preguntas: ¿Cómo se transferirá? ¿Cómo se registrará? ¿Cómo se tratarán las discrepancias? ¿Cómo se mantiene la operativa si se cancela una oleada?
| Punto de diseño | Decisión en el proyecto |
|---|---|
| Modo de migración | La migración por oleadas según clase documental, organización, periodo temporal o volumen suele ser más verificable que un Big Bang. |
| Mapeo de datos | Para cada campo de origen existe una regla documentada de destino: conservar, transformar, descartar o tratar manualmente. |
| Enlaces | El objeto SAP, la ID del documento y el enlace se planifican como elementos de prueba separados. |
| Gestión de errores | Se definen por anticipado clases de error, reintento, manejo de duplicados, cuarentena y responsables. |
| Operación en paralelo | Se definen claramente el periodo, la fuente de verdad de los datos y la vía de soporte. |
| Retroceso | Las condiciones de retroceso y la vía de recuperación se prueban, no sólo se describen. |
Importante: para datos sujetos a conservación obligatoria deben permanecer en el nuevo sistema contenidos, metadatos y los enlaces necesarios con equivalencia cuantitativa y cualitativa. Extractos puros de datos, informes o archivos de impresión no son suficientes si se pierden así informaciones sujetas a conservación.[1]
Fase 4: Ejecutar un piloto representativo
El piloto no es una prueba técnica con unos pocos ficheros al azar. Debe cubrir las configuraciones típicas y las de riesgo del conjunto a migrar.
| Dimensión del piloto | Ejemplos de selección |
|---|---|
| Clase documental | Facturas, justificantes, contratos, anexos, formatos firmados o estructurados. |
| Objeto de negocio | Varios objetos y procesos SAP con rutas de enlace y recuperación distintas. |
| Antigüedad de los datos | Registros actuales, contenidos de conservación prolongada y casos antiguos especiales. |
| Volumen | Recuperaciones individuales, documentos masivos y ficheros de gran tamaño. |
| Permisos | Rol estándar, rol restringido, rol auditor y acceso no autorizado. |
| Casos excepcionales | Metadatos faltantes, enlaces duplicados, ficheros dañados, objetos bloqueados o eliminados. |
El piloto finaliza con un protocolo de resultados consensuado. No sólo se registrará la transferencia exitosa, sino también mensajes de error, desviaciones, reintentos y comportamiento temporal.
Fase 5: Validación y aceptación
La validación combina pruebas técnicas con aceptación funcional. Verifica si el contenido destino coincide con el inventario y el diseño aprobados.
| Campo de prueba | Pregunta guía | Evidencia mínima |
|---|---|---|
| Cantidad | ¿Se han transferido todos los contenidos previstos? | Comparación de volúmenes origen y destino por oleada de migración. |
| Integridad | ¿El contenido está sin cambios y es legible? | Métodos de comparación según el concepto de pruebas del proyecto, p. ej. comprobación de hash o de fichero, en la medida técnica posible. |
| Metadatos | ¿Coinciden los criterios de búsqueda y asignación? | Comparación de campos para metadatos obligatorios y críticos funcionalmente. |
| Enlace SAP | ¿Abre el objeto de negocio SAP correcto el documento destino correcto? | Prueba end-to-end con IDs de objeto y documento documentadas. |
| Recuperabilidad | ¿Pueden los roles autorizados buscar, mostrar, leer y exportar los contenidos? | Pruebas funcionales de recuperación y exportación por rol. |
| Permisos | ¿Los accesos están correctamente limitados? | Pruebas positivas y negativas por rol. |
| Operatividad | ¿Se dominan errores, reintentos y monitorización? | Protocolo de pruebas para timeouts, errores, reintentos y transferencia de soporte. |
| Trazabilidad | ¿Es comprensible el proceso para terceros peritos? | Documentación actual de procedimientos, sistemas, usuarios y operación. |
Las GoBD exigen una documentación de procedimiento significativa y actual. Debe hacer comprensibles el contenido, la estructura, el flujo y los resultados del procedimiento y también reflejar históricamente los cambios.[1]
Fase 6: Decisión Go-/No-Go y migración por oleadas
Un go-live solo es razonable cuando las desviaciones del piloto están valoradas, hay responsables designados y los riesgos abiertos están aceptados o corregidos. Defina la decisión no por un porcentaje genérico, sino según la clase documental afectada, el tipo de negocio, la relevancia legal y el riesgo de retroceso.
Go-live solo si se cumplen condiciones mínimas
- Alcance e inventario están aprobados.
- Pruebas de piloto y end-to-end están documentadas.
- Desviaciones críticas están resueltas o formalmente aceptadas.
- Procesos de permisos, recuperación, exportación y operación están probados.
- El plan de retroceso es ejecutable y las responsabilidades están cubiertas.
- Área de negocio, TI, operación y roles de cumplimiento necesarios han otorgado la aceptación.
A continuación la migración se realiza en oleadas controladas. Cada oleada recibe su propio protocolo de inicio, cierre y aceptación. Una oleada automatizada sin comprobación de cantidades, errores y cierre puede reducir esfuerzo, pero no la obligación de pruebas y evidencias.
Fase 7: Operación tras la migración
La migración no termina con el último documento transferido. La operación destino debe dominar recuperación, monitorización, permisos, modificaciones, respuesta a incidentes, backup/recuperación, exportación y futuras ausencias/expurgos.
- Realice pruebas periódicas de recuperación y restauración.
- Mantenga versionadas las modificaciones en interfaces, modelos de metadatos, roles y procedimientos operativos.
- Conserva los protocolos de aceptación, pruebas y migración en el archivo de evidencias.
- Apague el sistema antiguo sólo tras un periodo de transición aprobado.
- Revisite los casos de recuperación y enlace ante cambios de versión SAP o de integración.
Lista de verificación compacta para copiar
| Fase | Pregunta de comprobación | Estado |
|---|---|---|
| Gobernanza | ¿Están aprobados por escrito alcance, roles, visión objetivo y criterios de aceptación? | ☐ |
| Inventario | ¿Se han registrado repositorios, clases de documento, metadatos, enlaces, roles y casos especiales? | ☐ |
| Diseño de migración | ¿Existe mapeo, plan de oleadas, gestión de errores, operación en paralelo y plan de retroceso? | ☐ |
| Piloto | ¿Cubre el piloto documentos, roles y procesos representativos y de riesgo? | ☐ |
| Validación | ¿Se han probado cantidad, contenido, metadatos, enlaces SAP, búsqueda, exportación, permisos y operación? | ☐ |
| Aceptación | ¿Se han evaluado desviaciones y documentado las aprobaciones? | ☐ |
| Operación | ¿Están establecidos monitorización, soporte, archivo de evidencias, pruebas de restauración y proceso de cambio? | ☐ |
| Sistema antiguo | ¿Está prevista la desconexión sólo tras el periodo de transición aprobado? | ☐ |
Siguiente paso recomendable
Comience con un taller de inventario de dos horas. El resultado no debería ser un concepto en la nube general, sino una lista verificable de sistemas SAP implicados, repositorios, clases de documento, enlaces, roles y criterios de aceptación. Sobre esa base se puede planificar un piloto que haga visibles los riesgos reales de la migración.
Para el contexto de proyectos de transformación SAP complementa esta lista RISE with SAP: Tener en cuenta el archivado desde el principio. Para la pregunta de cómo delimitar archivado de datos y archivado documental está disponible el artículo ILM und Datenarchivierung: Wie Unternehmen ihre Daten nachhaltig verwalten können.
Fuentes y límites profesionales
Esta página ofrece orientación técnica y organizativa. No sustituye asesoramiento fiscal, legal o de protección de datos. Las obligaciones concretas de conservación, eliminación, auditoría y acceso deben evaluarse para cada empresa, clase documental, paisaje de sistemas y ámbito jurídico.
