Migrating to Koha from another library system

Moving to Koha is not just a software change. It is a data, workflow, and go-live project.

This guide explains what a typical migration involves, what data is usually needed, where the work can get harder, and how to plan the move without unnecessary surprises.

What usually gets migrated

A typical migration can include some or all of the following:

• bibliographic records
• item records
• patron records
• current loans and holds, where needed
• fines or account balances, where needed
• branch and location data
• selected acquisition or serials data, depending on the project

Not every migration includes every data type.

The most important question first

The quality of the migration depends heavily on:

• what your current system can export
• how clean the source data is
• how much local customization exists
• how much testing your library wants before cutover

That is why migration timelines vary.

What KohaSupport usually needs to review early

Before a real migration plan is proposed, KohaSupport usually needs:

• the name of your current ILS
• sample export files
• a rough count of records, items, and patrons
• any known data issues
• whether you need loans, holds, fines, or serials migrated
• your desired timeline

Recommended source files

Bibliographic records

Preferred: MARC export if available.

Item records

Usually CSV or the source system’s item export format.

Patron records

Usually CSV.

Current circulation state

If you need open loans, holds, or fines carried over, provide sample exports for those too.

Branch, shelving, and code lists

Any local codes, item types, patron categories, or branch mappings should be shared early.

A practical migration sequence

1. Discovery

The first step is understanding the source system and the available exports.

This is where KohaSupport reviews what can realistically be migrated, what will need mapping, and where manual decisions may still be needed.

2. Mapping

The next step is mapping the source data into Koha.

That usually includes:

• bibliographic mapping
• item mapping
• patron mapping
• code translation for libraries, locations, item types, and patron categories

3. Test import

A test migration should happen before any final cutover.

This gives your library a chance to review:

• sample records
• item visibility and holdings
• patron data quality
• circulation rules and workflows
• reports and searches

4. Validation

Validation is where the project succeeds or fails.

At this stage, your library should check:

• MARC quality
• item counts and locations
• patron records
• problem records
• search behavior
• circulation and hold behavior
• any custom workflows you rely on

5. Final cutover planning

The final migration should be scheduled around:

• the last export from the source system
• the time needed for import and validation
• staff availability
• patron communication
• any DNS or go-live timing

Common migration risks

The most common risks are not mysterious technical failures. They are usually things like:

• incomplete exports
• inconsistent item/location codes
• duplicate or low-quality records
• missing patron fields
• serials and fines data that needs extra handling
• unrealistic expectations about timing
• not testing enough before go-live

What often takes longer than expected

Libraries often underestimate:

• data cleanup
• local code mapping
• validation time
• staff review time
• cutover coordination

That is normal. Good migration planning makes room for it.

What your library should do internally

Your library should decide early:

• who signs off on migrated data
• which workflows must be tested before go-live
• whether you need staff training before cutover
• whether old-system access will remain available during transition
• who will approve the final switch

When Managed Services is worth adding

Managed Services is often worth adding when:

• your team is short on time
• your current system is hard to export from
• your data needs more mapping and review
• your library wants a more guided rollout

Related guides

• New to AWS? How Koha on AWS works for libraries
• Which Koha on AWS option is right for your library?
• Standard Self-Service Launch Checklist
• How to choose the right Koha on AWS setup
• Who handles what? Self-Service, Managed Services, and AWS responsibilities
• Implementation Checklist

Need help with migration planning?

If your library is planning a move from another ILS, talk to KohaSupport and be ready to share sample exports.