Migrating to Koha is a mapping exercise, not a file transfer. Records come out of one system in one shape and have to go into another in a different shape, and the work is deciding what each field becomes.
Realistic timeline: six to twelve weeks for a mid-size library, from first data export to go-live. If someone has told you a weekend, they are describing the final cutover and not the project.
What actually moves
| Data | How it moves |
|---|---|
| Bibliographic records | Cleanly — this is what MARC is for |
| Holdings / items | Needs mapping — barcodes, locations, item types, call numbers |
| Patrons | Needs mapping — categories, expiry, permissions |
| Active loans | Needs mapping, and a freeze window |
| Holds | Needs mapping; queue position often rebuilt |
| Fines and payments | Needs mapping; often carried as opening balances |
| Circulation history | Optional — decide deliberately, see below |
| Authorities | Moves, with cleanup |
| Serials subscriptions | Usually rebuilt — prediction patterns rarely translate |
| Acquisitions / open orders | Usually rebuilt |
| Circulation rules | Always rebuilt — every ILS models these differently |
Being honest that some things are rebuilt rather than moved is what makes the rest credible. Anyone claiming everything transfers perfectly has not done many migrations.
The migration process, step by step
1 — Audit and clean the source data
The cheapest hour in the project. Find duplicate barcodes, records with no items, patrons with no category, inconsistent item types. Fixing these in the old system before export is far cheaper than fixing them in Koha afterwards.
2 — Export from the current system
MARC for bibliographic data — ISO 2709 or MARCXML. Patrons, loans and fines usually come out as CSV or a database extract. Get a full export early, even a rough one: it tells you what you are actually dealing with rather than what the documentation claims.
3 — Map fields to Koha's structure
The intellectual core of the work. Every source field either has a Koha equivalent, needs transforming, or has nowhere to go and requires a decision. Item data maps into MARC field 952 — see our MARC21 guide.
4 — Test migration into a staging instance
Load everything into a throwaway Koha. Expect to do this several times; the first pass always reveals mapping decisions nobody anticipated.
5 — Validate
Record counts before and after. Spot checks on a random sample. Deliberate edge cases: the longest title, a record with fifteen copies, a patron with outstanding fines and an overdue book, a multi-volume set.
6 — Freeze, migrate, go live
Stop circulation in the old system, take the final export, run the migration, verify, switch over. Usually a weekend. Have a written rollback plan.
7 — Reconcile afterwards
For the first fortnight, check the exception list and watch for problems only real use surfaces.
Migrating MARC records
Character encoding is the failure that ruins migrations. Older systems often store records in MARC-8; Koha expects UTF-8. Convert properly and everything is fine. Convert carelessly and every accented character, every non-Latin script, becomes unrecoverable mojibake — and you usually notice weeks later.
Always validate a sample containing your most awkward records before running the full load.
Also plan for deduplication. Most catalogs contain duplicate records; migration is the natural moment to merge them, using matching rules on control numbers or ISBN.
Migrating patron data
Patron categories drive circulation rules, so map them deliberately rather than mechanically. Check barcodes for duplicates, and decide what happens to expired members.
Then a question worth pausing on: how much circulation history should you actually carry over? It is the largest and least-used dataset in the migration, and it is personal data about what people read. Many libraries take the opportunity to keep only what they need. That is a policy decision, not a technical one — make it consciously.
Migrating loans, holds and fines
The hardest part, because this is live state that changes until the moment you stop. It is the reason the freeze window exists.
Loans need item, patron, due date and renewal count. Holds are often rebuilt with fresh queue positions — patrons rarely notice, and preserving exact positions is disproportionately expensive. Fines are commonly carried as opening balances rather than itemised history.
What usually breaks
- Non-UTF8 characters — the big one. Validate a sample first.
- Local fields with no Koha equivalent — decide: map to a note, use a custom field, or drop it deliberately.
- Duplicate barcodes — Koha enforces uniqueness where the old system may not have.
- Item types that do not map — twenty source types collapsing to eight, and the loan rules that depended on the distinction.
- Fine rules that behaved differently — different grace periods and accrual produce different balances. Reconcile, do not assume.
- Records with no items — invisible as available in the OPAC, and they look like data loss.
Migrating from specific systems
- Sierra / Millennium — good MARC export; item and patron data need the most mapping work.
- Alma — clean exports; the work is in fields with no Koha equivalent.
- Destiny — common for schools; usually straightforward.
- Older Koha — the easiest case, same schema.
- Spreadsheets or a card catalog — more common than vendors admit, and entirely doable. Records are matched against Z39.50 sources to build proper MARC rather than typed by hand.
How we validate — and what we promise
Nobody honest promises zero data loss. What you should expect instead, and insist on in writing:
- Record counts reconciled before and after, per data type
- Spot checks on a documented sample
- Edge cases deliberately tested
- A written exception list of anything that could not be moved cleanly, given to you at handover rather than discovered by a cataloger in March
Go-live checklist
- Full backup of the old system, verified readable
- Record counts recorded before export
- Staging migration validated and signed off
- Circulation rules configured and tested in Koha
- Notice templates written and test-sent
- Email deliverability confirmed to an external address
- Scheduled jobs configured and confirmed running
- Staff trained, with a written cheat sheet at each desk
- Backups configured and one restore tested
- Rollback plan written down
- Someone identified to call during the first week
How long, and what it costs
Six to twelve weeks for a mid-size library. Cost scales with source-data messiness rather than record count — see our installation cost breakdown.
One thing worth deciding at the same time: a migration answers "where does the data go" but leaves "who runs it afterwards" open. Migrating into a system that is already set up and hosted closes both questions at once, so the project ends with a working service rather than a working server you now own.
Planning a migration? Send us a sample export and tell us what system you are on. Our Koha migration service will tell you what moves cleanly, what needs decisions, and how long it will take.