
Escrito por OpenKM el 25 de septiembre 2026
Un CIO que maneja un repositorio documental en crecimiento se ve obligado a preguntarse algo inevitable: ¿qué pasa cuando el almacenamiento local se acerca al límite de la plataforma?
Más documentos significa más versiones, más texto indexado, más previsualizaciones, más copias de seguridad y mayores requisitos de continuidad. Para un responsable de infraestructura el problema no es simplemente añadir capacidad sino poder decidir dónde está el contenido (o cómo se distribuye), cómo puede evolucionar la arquitectura (sin alterar la gestión documental de los usuarios).
En lenguaje coloquial, el cambio hace posible separar mejor dos conceptos: gestión de los documentos e infraestructura física donde se almacenan.
El soporte S3 permite usar almacenamiento de objetos como backend para conservar el contenido documental gestionado por OpenKM.
Hasta ahora el modelo común era un datastore sobre filesystem. Con la nueva arquitectura una organización puede mantener ese modelo o plantear usar buckets compatibles con S3 cuando necesite mayor flexibilidad para escalar, distribuir o reorganizar su infraestructura.
La clave está en la abstracción de la capa de almacenamiento. OpenKM sigue gestionando los documentos, permisos, metadatos, versiones, búsquedas y procesos, mientras que la infraestructura subyacente puede evolucionar de forma independiente.
Para el usuario final la lógica documental está todavía en OpenKM. Para el equipo de infraestructura hay una nueva alternativa para decidir dónde reside físicamente el contenido.
Un repositorio documental no contiene sólo archivos. Además de los documentos originales y versiones, una plataforma como OpenKM maneja texto extraído para búsquedas e indexación; representaciones usadas para previsualizaciones, miniaturas y otros recursos auxiliares.
La arquitectura prevista permite usar buckets o prefijos distintos para diferentes tipos de información.
Esta separación es especialmente útil cuando una organización quiere aplicar políticas diferentes según la función del contenido. El documento original puede tener unas necesidades de retención y disponibilidad distintas a una miniatura generada automáticamente o al texto extraído para facilitar una búsqueda.
También tenemos prefijos asociados a tenants y shards que permiten organizar el contenido en arquitecturas donde hay distintos repositorios, clientes o particiones de almacenamiento.
El resultado es una arquitectura documental menos dependiente de un solo sistema físico de archivos.
S3 suele asociarse directamente con Amazon Web Services pero el concepto es más amplio.
La arquitectura prevista usará el SDK estándar de AWS y permitirá configurar endpoints personalizados (Amazon S3 como infraestructura de almacenamiento de objetos compatible con su API).
Esto no quiere decir que cualquier plataforma S3-compatible sea automáticamente certificada por OpenKM. La lista definitiva de plataformas válidas debe confirmarse antes de hacer afirmaciones comerciales concretas.
Desde el punto de vista arquitectónico, sin embargo, esa flexibilidad abre las puertas a distintos escenarios.
Una organización puede mantener OpenKM sobre su infraestructura actual, usar servicios cloud OpenKM para almacenamiento de documentos; desplegar almacenamiento de objetos sobre infraestructura privada o combinar distintos componentes en un modelo híbrido.
El objetivo no es imponer un modelo concreto sino ampliar las posibilidades.
Los repositorios empresariales no siempre trabajan con documentos pequeños. Planes, CADs, documentación técnica, expedientes digitalizados o grandes paquetes documentales pueden llegar a ser muy grandes.
Para estos casos el soporte S3 admite transferencias multipart.
En lugar de enviar un gran archivo como una sola operación, puede dividirse en varias partes. Si se interrumpe una transferencia no siempre tenemos que empezar todo el proceso desde cero.
La arquitectura también tiene mecanismos para cancelar cargas incompletas y dejar que no queden fragmentos o datos sobrantes ocupando espacio innecesariamente en el almacenamiento.
Además los procesos de borrado, restauración y purga han sido considerados como parte del proceso para reducir el riesgo de objetos huérfanos después de eliminar contenido desde OpenKM.
Esta es probablemente una de las preguntas más importantes para una organización que ya tiene cientos de miles o millones de documentos almacenados.
Adoptar S3 no debería ser empezar desde cero. La arquitectura tiene una herramienta de migración desde filesystem hacia S3 para trasladar contenido existente progresivamente.
El proceso puede ejecutarse de forma incremental, volver a ejecutar para agregar documentos creados durante la migración y usar comprobaciones de integridad para validar el contenido trasladado.
Esto permite plantear una transición por etapas: una primera migración puede copiar la mayor parte del repositorio. Una sincronización final puede incorporar los cambios producidos durante el proceso. Solo después se hace el cambio controlado del backend.
Esta distinción es importante: copiar el contenido a S3 y activar S3 como backend son dos operaciones distintas.
La migración tiene que ser parte de un proyecto controlado (copia de seguridad, comprobación de errores, validación de versiones, pruebas de descarga y búsqueda, y verificación de la integridad).
Mover documentos a S3 no quita la necesidad de aplicar controles de seguridad.
Las credenciales que OpenKM usa para acceder al almacenamiento tienen que ser seguras. Se ha diseñado almacenar estas credenciales en configuración protegida y excluir ciertas paquetes de diagnóstico y soporte (por ejemplo) para evitar exposición accidental.
Por otra parte las políticas del backend también deben diseñarse con el principio mínimo privilegio.
S3 tampoco debe ser confundido con una estrategia completa de backup o recuperación ante desastres. Almacenar documentos en infraestructura de objetos no reemplaza la necesidad de definir copias, restauración, retención y pruebas periódicas de recuperación.
La infraestructura cambia; las operaciones no. La infraestructura es diferente pero las responsabilidades operativas siguen siendo las mismas.
El modelo es especialmente interesante cuando un repositorio crece de forma sostenida, cuando hay una estrategia cloud o híbrida, cuando se quiere reducir la dependencia del almacenamiento local de un único servidor o cuando distintos tipos de contenido requieren políticas diferentes de infraestructura.
También puede ser relevante para organizaciones que desean que su plataforma de gestión documental evolucione de forma relativamente independiente del proveedor o de la tecnología utilizada para almacenar los objetos.
Eso no quiere decir que S3 sea siempre la opción correcta. Costos de almacenamiento, número de operaciones, transferencia de datos, latencia en la ubicación geográfica, políticas de retención, de recuperación, requisitos de continuidad; deben analizarse en cada proyecto.
La decisión no debería ser “filesystem o S3” sino qué arquitectura permite gestionar mejor el crecimiento y los requisitos de la organización.
La principal novedad del soporte S3 no es cambiar la forma en que los usuarios trabajan con OpenKM.
Es ofrecer una nueva posibilidad para la infraestructura que sostiene el repositorio.
Para IT significa más opciones para gestionar capacidad y crecimiento. Para los responsable de la arquitectura ayuda a diseñar escenarios cloud privados o híbridos. Para gestión documental permite cambiar la infraestructura manteniendo en OpenKM la lógica de permisos, búsqueda, versiones, automatización y control documental
¿Tu repositorio de documentos está creciendo y necesitas una arquitectura de almacenamiento más flexible? Ponte en contacto con el equipo de OpenKM para ver cómo integrar almacenamiento S3 en tu entorno y definir una estrategia de migración según el volumen, infraestructura y continuidad de tu organización.