Migrar a Koha desde otro sistema consiste en extraer los registros bibliográficos, de ejemplares y de usuarios del sistema actual, convertirlos a MARC21 y cargarlos en una instancia de Koha ya configurada, con una fase de validación antes de la salida en producción. El punto crítico casi nunca es la carga técnica: es el mapeo de campos y la calidad de los datos de origen. Una migración bien planificada de un catálogo mediano —entre 9.000 y 25.000 registros— toma entre cuatro y diez semanas de trabajo efectivo.
Esta guía describe el proceso completo, sistema por sistema: qué exporta cada uno, cómo se traduce a MARC21, qué se limpia antes de cargar y qué suele salir mal. Si aún no conoces la plataforma, empieza por la guía de Koha y su implementación.
Qué se migra exactamente
Una migración completa mueve cinco conjuntos de datos distintos, y cada uno tiene su propio formato y su propio nivel de dificultad. Confundirlos es el primer error de planificación: muchos proyectos cotizan «migración del catálogo» pensando solo en los registros bibliográficos y luego descubren que faltan los ejemplares.
- Registros bibliográficos: la descripción de cada obra. Es lo que viaja en MARC21 o MARCXML.
- Ejemplares: cada copia física con su código de barras, signatura topográfica, sede, colección y estado. En Koha viven en el campo local 952.
- Autoridades: autores, materias y entidades corporativas normalizadas. Se migran como registros de autoridad aparte.
- Usuarios: el padrón de lectores, con categoría, sede, fecha de vencimiento y datos de contacto.
- Circulación: préstamos vigentes, reservas, multas e histórico. Es el conjunto que con más frecuencia se decide no migrar entero.
A esto se suma la parametrización, que no se migra sino que se reconstruye: tipos de ejemplar, categorías de usuario, reglas de circulación, calendarios de festivos, sedes y valores autorizados. En un sistema con tres sedes esa reconstrucción puede ser tan larga como la carga de datos.
Paso 1: inventario del sistema de origen
Antes de exportar nada hay que documentar de qué se parte. Un inventario útil responde siete preguntas y se resuelve en una o dos sesiones con el equipo de la biblioteca y con el área de tecnología.
- Nombre y versión exacta del sistema actual, y si el proveedor original sigue dando soporte.
- Cuántos registros bibliográficos, cuántos ejemplares y cuántos usuarios activos hay. No es el mismo número: 16.620 registros bibliográficos pueden ser más de 22.000 ejemplares.
- Qué formato de descripción usa: MARC21, UNIMARC, un formato propio o campos sueltos en una base de datos.
- Si hay acceso directo a la base de datos (MySQL, SQL Server, ISIS) o solo a la interfaz de exportación.
- Qué juego de caracteres usa: UTF-8, MARC-8, ISO 8859-1. Es la causa número uno de tildes rotas después de la carga.
- Qué se hace con los préstamos activos y las multas pendientes el día del corte.
- Si hay adjuntos: portadas, PDF de texto completo, enlaces a recursos electrónicos.
Formato de exportación por sistema de origen
La dificultad de una migración se decide en esta tabla. Los sistemas que exportan ISO 2709 limpio se migran rápido; los que solo permiten llegar a los datos por la base de datos exigen un trabajo de extracción previo que puede duplicar el cronograma.
| Sistema de origen | Formato de exportación habitual | Dificultad típica | Punto de atención |
|---|---|---|---|
| GLIFOS 8.0 | ISO 2709 o MARCXML desde el módulo de catalogación; en instalaciones antiguas, extracción directa de la base de datos | Media | Los datos de ejemplar suelen estar en tablas aparte, no embebidos en el registro |
| SIABUC | Exportación MARC (ISO 2709) o archivo delimitado, según la versión | Media | Etiquetas locales sin equivalente directo en MARC21 |
| Alejandría | ISO 2709 o CSV, según la versión y los módulos licenciados | Media-alta | Puede requerir gestión con el proveedor para habilitar la exportación completa |
| PMB | UNIMARC o MARC21 en XML, más volcado MySQL | Media | Si el catálogo está en UNIMARC hay que convertirlo a MARC21 |
| Aleph | ISO 2709 por utilidades de exportación; ejemplares y usuarios en tablas separadas | Alta | Volumen alto, campos locales extensos y lógica de sedes propia |
| Winisis / CDS-ISIS | Base ISIS convertida a ISO 2709 con utilidades externas | Alta | Campos repetibles no normalizados y codificación heredada |
| Excel / Google Sheets | CSV o XLSX convertido a MARC21 con un traductor de texto delimitado | Baja en lo técnico, alta en limpieza | Cada columna se decide a mano; casi siempre hay duplicados y varios datos en una misma celda |
| Otra instancia de Koha | Volcado MySQL completo o exportación MARCXML con ejemplares en 952 | Baja | Diferencias de esquema entre versiones muy alejadas |
Koha acepta dos formatos de entrada para registros bibliográficos y de autoridad: MARC binario (ISO 2709, archivos .mrc) y MARCXML. Cualquier otra cosa —CSV, XLSX, JSON, un volcado SQL— debe convertirse antes. Los usuarios son la excepción: se cargan con un CSV propio desde la herramienta de importación de usuarios.
Mapeo de campos a MARC21
El mapeo es la tabla de equivalencias entre cada campo del sistema anterior y su etiqueta MARC21 en Koha. Se hace una sola vez, se documenta y se aplica a todo el lote. Hay cuatro decisiones que siempre deben quedar explícitas:
- 942$c: tipo de documento a nivel bibliográfico. Determina cómo se comporta el registro en circulación y en las facetas del OPAC.
- 952: el campo local de ejemplar. Como mínimo necesita sede propietaria, sede de origen y tipo de ejemplar; en la práctica se cargan también código de barras, signatura topográfica, colección y fecha de adquisición.
- Campos de control: 001, 003 y el identificador interno. Si el sistema anterior tenía un número de control propio, conviene conservarlo en un campo local para poder auditar después.
- Codificación de caracteres: se decide al inicio y se verifica en el primer lote de prueba. Corregir tildes en 20.000 registros ya cargados cuesta más que rehacer la conversión.
Un error frecuente en migraciones desde hojas de cálculo es cargar todo el título en 245$a sin separar subtítulo (245$b) ni mención de responsabilidad (245$c). El catálogo carga, se ve bien en pantalla y luego falla la búsqueda por autor y la ordenación. Conviene resolverlo en la conversión, no después.
Limpieza de duplicados y control de autoridades
Casi ningún catálogo heredado llega limpio. En los proyectos de depuración que hemos hecho sobre acervos cercanos a los 9.000 registros, una fracción que suele situarse entre el 3 % y el 10 % presenta algún problema: duplicados exactos, duplicados por variantes de título, autores escritos de tres formas distintas, materias sin control, ISBN mal digitados o registros sin ningún ejemplar asociado.
La limpieza se hace antes de la carga definitiva, sobre el archivo ya convertido, porque en esa fase se pueden aplicar reglas masivas. Koha ofrece además reglas de coincidencia durante la importación: puede comparar por ISBN (020$a), por ISSN (022$a) o por el identificador interno de Koha, y decidir si ignora, sustituye o agrega el registro entrante. Definir esa regla es obligatorio cuando se carga en varios lotes o cuando se integran sedes que comparten títulos.
Las autoridades merecen una decisión explícita: se migran, se reconstruyen a partir de los bibliográficos o se dejan para una segunda fase. Migrar bibliográficos sin autoridades funciona, pero deja pendiente el control de puntos de acceso.
Ejemplares, usuarios y circulación
Los ejemplares se cargan embebidos en el 952 del propio registro, lo que evita una segunda pasada. Si el sistema de origen entrega los ejemplares en una tabla aparte, hay que unirlos al bibliográfico durante la conversión usando el identificador común. Es la parte que más sorpresas da cuando hay varias sedes: un mismo título con ejemplares en tres campus debe terminar en un solo registro bibliográfico con tres o más campos 952, no en tres registros duplicados.
Los usuarios se cargan por CSV, con número de carné y apellido como campos obligatorios, más los que la institución haya marcado como obligatorios en su configuración. Dos advertencias prácticas: las columnas vacías sobrescriben con vacío los datos existentes, y las contraseñas se envían en texto plano para que Koha las convierta en hash, así que el archivo debe tratarse como dato sensible y borrarse al terminar.
Sobre la circulación, la decisión honesta suele ser esta: migrar préstamos vigentes y reservas activas, y no migrar el histórico completo. El histórico rara vez justifica su costo de conversión, y si se necesita para estadísticas puede conservarse como archivo aparte o cargarse después, ya en producción.
Carga de prueba, validación y corte
Ninguna migración seria carga directo a producción. La secuencia probada es esta:
- Lote piloto de 200 a 1.000 registros representativos: libros, publicaciones seriadas, tesis, material audiovisual y al menos un caso difícil de cada sede.
- Revisión del piloto por el equipo de la biblioteca en el catálogo real, no en una hoja de cálculo: buscar por autor, por materia, ver la ficha completa, prestar un ejemplar.
- Ajuste del mapeo según lo que aparezca. Aquí es donde se corrigen codificación, subcampos mal asignados y tipos de ejemplar.
- Carga completa en el ambiente de pruebas, con el total de registros, ejemplares y usuarios.
- Validación por conteos: número de bibliográficos, de ejemplares por sede, de usuarios por categoría y de códigos de barras únicos debe cuadrar contra el origen.
- Congelamiento del sistema anterior: se fija una fecha y hora a partir de la cual no se cataloga ni se presta allí.
- Carga delta y corte: se migra lo capturado entre el volcado y el congelamiento, se apunta el dominio a Koha y se abre el OPAC.
Conviene mantener el sistema anterior accesible en modo solo lectura durante al menos un mes después del corte. Cuesta poco y resuelve discusiones.
Cuánto tarda según el volumen
El tiempo depende mucho más de la calidad de los datos que de la cantidad. Estos rangos corresponden a proyectos con exportación disponible en un formato estándar y con el equipo de la biblioteca participando en la validación.
| Volumen | Escenario típico | Duración estimada |
|---|---|---|
| ~9.000 registros, 1 sede | Cambio de proveedor con depuración del catálogo y generación de códigos de barras | 3 a 5 semanas |
| ~16.600 registros, 1 sede | Migración desde un sistema propietario con exportación MARC disponible | 5 a 8 semanas |
| ~25.000 registros, 3 sedes | Migración multisede con reglas de circulación distintas por campus | 8 a 12 semanas |
| Más de 100.000 registros | Acervo grande, autoridades propias e integraciones con el ERP académico | 3 a 6 meses |
La variable que más mueve estos plazos es el número de sedes, no el número de registros: cada campus agrega parametrización, reglas de circulación, usuarios y validación propia.
Qué suele salir mal
- Tildes y eñes rotas por una conversión de codificación mal declarada. Se detecta en el piloto o no se detecta a tiempo.
- Ejemplares duplicados: un 952 repetido que la conversión interpreta como varios ejemplares distintos. Nueve registros pueden convertirse en decenas de ejemplares fantasma.
- Códigos de barras repetidos o inexistentes. Koha exige unicidad; si el acervo nunca tuvo códigos, hay que generarlos e imprimirlos, y eso es un proyecto en sí mismo.
- Registros sin ejemplar, que aparecen en el OPAC pero no se pueden prestar.
- Parametrización incompleta: tipos de usuario o reglas de préstamo que no se replicaron y aparecen el primer día de clases.
- No congelar el sistema anterior, y terminar con dos catálogos divergentes durante semanas.
Ninguno de estos problemas es raro ni grave si se detecta en la fase de prueba. Todos son costosos si se detectan en producción.
Después de la migración
Con el catálogo cargado quedan tres decisiones abiertas: dónde se aloja la instancia, con qué política de respaldos y quién la actualiza. Las tratamos en hosting de Koha: nube gestionada o servidor propio. Si además quieres dimensionar la inversión, revisa cuánto cuesta implementar Koha en una universidad.
Si el acervo llega con registros pobres o con lagunas de descripción, la migración es el mejor momento para enriquecerlo: así funciona Koha con catalogación automática por IA.