Cómo migrar a DSpace desde otro repositorio

Qué se migra, qué se reconstruye y qué se pierde

Un repositorio no es una sola base de datos: son cuatro capas con formatos y riesgos distintos. El error de planificación más común es cotizar «migración del repositorio» pensando solo en los metadatos.

• Metadatos descriptivos: la descripción de cada ítem, normalmente en Dublin Core cualificado. Es lo que viaja en XML o en CSV y lo que se mapea campo por campo.
• Bitstreams: los archivos en sí —el PDF de la tesis, el dataset, el audio—, que en DSpace viven en el assetstore y no dentro de la base de datos. Pesan y hay que moverlos aparte.
• Estructura de comunidades y colecciones: el árbol de facultades, programas y tipos documentales. Se reconstruye en el destino antes de cargar nada, porque cada ítem necesita una colección de llegada.
• Identificadores persistentes: los Handle o los DOI ya publicados. Es la única capa que, si se rompe, rompe también todo lo que está afuera del repositorio.

Hay además cosas que no se migran y se reconstruyen: los flujos de depósito y revisión, los grupos y permisos, los formularios de envío, los embargos configurados como políticas de acceso y la personalización visual. Y una capa que casi nunca se migra completa: el histórico de estadísticas de uso. En DSpace las estadísticas viven en un núcleo de Solr, no en la base de datos, y solo se trasladan si el sistema de origen es también DSpace. Viniendo de otra plataforma, lo normal es empezar el contador desde cero y conservar los reportes antiguos como archivo aparte.

Los identificadores persistentes: el punto que no se puede romper

DSpace asigna a cada ítem un Handle, un identificador con la forma hdl.handle.net/prefijo/sufijo. El prefijo lo emite CNRI a la institución mediante una cuota anual, y la promesa del sistema es que esa URL siga resolviendo aunque cambie el dominio, el servidor o la plataforma. Por eso, si el repositorio anterior ya publicó identificadores que aparecen en tesis, artículos y hojas de vida, hay que llevárselos. Hay dos caminos y conviene elegirlo al inicio del proyecto, no al final:

• Trasladar el prefijo: se gestiona con CNRI para que la resolución del prefijo existente apunte al servidor nuevo. Es la opción limpia, pero es todo o nada: el prefijo entero pasa al repositorio nuevo y la plataforma anterior deja de resolver los handles restantes.
• Conservar el identificador antiguo como metadato y publicar redirecciones desde las URL viejas. Es la salida cuando el prefijo pertenece a un consorcio o a un proveedor que no lo cede.

Si el origen usaba DOI de DataCite, la operación es equivalente: actualizar la URL de destino registrada para cada DOI. Es trabajo mecánico y masivo, pero no es opcional. Cuando migramos un repositorio para una universidad, la verificación de identificadores es una tarea con nombre propio en el cronograma y se hace después del corte, con una muestra manual y con el listado completo. Conviene además dejar redirecciones desde las URL directas del repositorio viejo, que también están enlazadas en muchos sitios.

Formatos de entrada: qué acepta DSpace

DSpace tiene varias puertas de entrada y cada una sirve a un escenario distinto. Elegir bien es la mitad del trabajo.

Dos advertencias que aparecen en casi todos los proyectos. El paquete ZIP que se sube por la interfaz tiene un límite de tamaño —2 GB por defecto—, así que un repositorio con miles de PDF se carga por lotes o desde la línea de comandos. Y si el CSV se edita en Excel hay alta probabilidad de que las tildes lleguen rotas, porque Excel maneja mal UTF-8 y suele insertar una marca invisible al inicio del archivo: conviene saberlo antes, no después de cargar 12.000 registros.

Escenarios de migración: dificultad y qué se conserva

No todas las migraciones se parecen. Esta tabla resume los cinco casos que vemos en la región, con lo que realmente se conserva en cada uno.

El último escenario es el más común en las universidades latinoamericanas y el que peor se cotiza, porque parece el más sencillo. No lo es: la dificultad se desplaza del código a la institución. Hay que decidir qué se publica, conseguir la autorización de los autores, definir licencias, armar el árbol de comunidades y, sobre todo, lograr que el repositorio no nazca vacío. En la región abundan los repositorios formalmente activos y prácticamente sin contenido; es exactamente el problema que resolvimos en la Universidad Americana de Paraguay, donde integramos extracción automática de metadatos al flujo de depósito para que llenarlo no dependiera de transcribir a mano cada portada.

Metodología: los siete pasos de una migración que no falla

Esta es la secuencia que seguimos y el orden importa. Saltarse el ambiente espejo es el atajo que más caro sale.

1. Inventario del origen. Cuántos ítems, cuántos bitstreams y cuántos gigabytes; qué esquema de metadatos y qué versión exacta del sistema; si hay acceso a la base de datos o solo a una exportación; qué identificadores se publicaron y quién controla el prefijo.
2. Mapeo de metadatos campo por campo hacia el registro de DSpace. Aquí se decide qué va a Dublin Core estándar y qué va al esquema local, donde deben vivir los campos propios para que ninguna actualización futura los toque.
3. Diseño de comunidades y colecciones en el destino, con los tipos de ítem, los formularios de depósito y las políticas de acceso ya definidos.
4. Carga de prueba en un ambiente espejo, idéntico al de producción, con un lote piloto de 100 a 500 ítems representativos: una tesis con embargo, un artículo con varios autores, un ítem con cinco archivos, uno con caracteres especiales en el título y uno de cada colección conflictiva.
5. Validación con el equipo de la biblioteca sobre el repositorio real, no sobre una hoja de cálculo: buscar por autor, filtrar por facetas, abrir el PDF, comprobar que el embargo bloquea la descarga.
6. Carga completa y congelamiento. Fecha y hora a partir de las cuales no se deposita nada en el sistema anterior, carga del total, cuadre de conteos —ítems por colección, bitstreams por ítem, suma de tamaños— y migración del delta capturado entre el volcado y el congelamiento.
7. Corte y verificación de identificadores. Se apunta el dominio, se abre el repositorio y se verifica que los handles y DOI resuelvan, con muestra manual y revisión automatizada del listado completo. Es el último entregable, no un pendiente.

Sobre plazos, la horquilla honesta: en nuestros proyectos, una migración con exportación en formato estándar y con la biblioteca participando en la validación se mueve entre cuatro y diez semanas de trabajo efectivo para un repositorio de unos pocos miles de ítems. Lo que mueve ese rango no es el número de ítems, sino la calidad de los metadatos de origen, el volumen en gigabytes de los archivos y el número de decisiones que la institución todavía no ha tomado.

Caso especial: subir de DSpace 6 o 7 a una versión actual

No es una migración entre plataformas, pero se le parece más de lo que la gente espera. Tres cambios pesan.

El salto de interfaz

Desde DSpace 7 las interfaces antiguas —XMLUI y JSPUI— desaparecieron y todo el frontend es una aplicación Angular independiente del backend. Cualquier personalización de tema hecha sobre XMLUI no se migra: se rehace. Conviene presupuestarlo como desarrollo, no como configuración.

El registro de metadatos y las entidades

DSpace 7 introdujo el modelo de entidades y relaciones, que guarda los vínculos en una tabla propia. No existe un script que convierta en bloque los ítems antiguos en entidades, así que la recomendación —de la comunidad y nuestra— es desacoplar los dos proyectos: primero la actualización técnica con las entidades desactivadas, después la adopción del modelo. Y una regla que evita dolores futuros: no se editan los esquemas dc ni dcterms; los campos propios van al esquema local.

Las estadísticas y la versión de destino

Las estadísticas de uso y el núcleo de autoridades se exportan e importan explícitamente; los de búsqueda y OAI se reconstruyen reindexando. Si las estadísticas antiguas estaban fragmentadas por año, hay trabajo adicional porque las versiones modernas no manejan esa fragmentación. Revisa además la política de soporte: con la salida de DSpace 10.0 en mayo de 2026 la línea 7.x quedó fuera de soporte y las versiones vigentes son 8.x, 9.x y 10.x. Migrar a una rama sin soporte es pagar dos veces.

Qué suele salir mal

• Handles rotos. El repositorio abre, todo se ve bien y las citas publicadas dejan de resolver. Es el único error de esta lista que daña a gente que no trabaja en la biblioteca.
• Respaldo incompleto antes del corte: se respalda la base de datos y se olvida el assetstore, o al revés. Hay además un orden correcto —primero la base de datos, después los archivos—, porque DSpace toma la base de datos como registro autoritativo.
• Tildes rotas por codificación mal declarada, casi siempre con origen en un CSV pasado por Excel, e ítems sin bitstream: el metadato llegó, el archivo no. Ambos se detectan cuadrando conteos, no revisando a ojo.
• Embargos que no se trasladaron y terminan publicando en abierto una tesis que debía estar restringida. Es el fallo con consecuencias legales, y por eso el lote piloto siempre incluye un ítem embargado.
• Colecciones inventadas durante la carga, en lugar de diseñadas antes. Reorganizar el árbol con 10.000 ítems adentro es mucho más caro que discutirlo en una reunión.
• No congelar el sistema anterior, y terminar con dos repositorios divergentes durante semanas.

Después del corte

Un repositorio migrado no está terminado el día que abre. Quedan tres frentes. El primero es la visibilidad: configurar los contextos OAI-PMH para que los agregadores regionales puedan cosecharlo, lo que implica cumplir sus directrices de metadatos y no solo encender el servidor OAI. El segundo es la infraestructura: dónde vive la instancia, con qué política de respaldos y quién aplica los parches; lo tratamos en hosting de DSpace: nube gestionada o servidor propio.

El tercero es estratégico. Si la universidad necesita responder «qué produjo el investigador X» o «qué salió del proyecto financiado Y», el repositorio de documentos no alcanza y la conversación se mueve hacia DSpace-CRIS. Vale la pena plantearlo antes de migrar, porque decidirlo a tiempo cambia cómo se modelan las colecciones y los metadatos de autoría.

En la Escuela Colombiana de Ingeniería Julio Garavito el repositorio DSpace convive con el catálogo Koha y con el resto de la plataforma de la biblioteca, porque se planificó como un sistema y no como una compra suelta. Si tienes que migrar un repositorio y quieres una propuesta con inventario, mapeo, ambiente de prueba y verificación de identificadores incluidos, lo cotizamos sobre las cifras reales de tu acervo desde nuestro servicio de implementación de DSpace.