Migrating to Lyra from another library system

This is the overview of switching to Lyra from whatever library system you’re on today — Follett Destiny, Alexandria, Atriuum, or anything else. It covers the project as a whole — access, sequence, cutover, and the day-one checks — and hands off to focused guides for the two big pieces of data:

Migrating catalog data — getting your titles and copies out of your old system, MARC for preference.
Migrating patrons — where your roster should come from (your SIS, not your old ILS) and the three ways to load it.
Term mapping — a crosswalk from your old system’s vocabulary to Lyra’s.

What a migration moves

A migration moves two things into Lyra: your catalog and your patrons. Each has its own guide above. Everything else on this page is the connective tissue around them — the planning, the cutover, and the verification that turn two data loads into a working library.

The sequence

Confirm your access and source of truth

Make sure you can export from your current system, and decide whether your patron roster comes from your SIS (preferred) or your previous ILS.
Produce your data

A catalog export (MARC with copy data where you can get it, otherwise a spreadsheet), a patron roster (by OneRoster sync where possible, otherwise a spreadsheet or CSV), and a current-checkouts report you’ll use as a worklist on day one.
Import into your new library, reviewing before you commit

Both imports let you preview before anything changes: the catalog import has a setting: Stage for review mode, the roster import a setting: Dry run. Import into your new library, review, then commit.
Reconcile your circulation policies

Most systems carry a policy matrix that doesn’t translate one-to-one to Lyra’s model. Plan to collapse it.
Cut over and freeze your old system

Save a final checkouts report as a day-one re-checkout list, then mark the old system read-only.

Confirm your access and source of truth

Before you export anything, get clear on three things.

That you can actually export. You’ll need administrator-level access to your current system to run catalog and report exports. If you only have plain librarian or staff access, ask whoever holds the top-level account at your school (or your district or diocesan IT office, if your system is hosted centrally) to either run the exports or raise your access for the duration of the migration.

Whether you’re standalone or part of a larger deployment. An independent school is usually a single site you administer yourself. If your school is part of a shared diocesan or district installation, your data may live inside a larger catalog with other schools’ records alongside yours, and a properly scoped export (just your titles, just your patrons) may need the district administrator. Confirm this early; it’s the most common cause of a migration that pulls in too much or too little.

Where your patron roster will come from. In almost every school the real source of truth for patrons is your Student Information System, not your old ILS — and that choice shapes the entire patron side of the move. Migrating patrons explains why, and lays out the three ways to load a roster, best first.

Plan for circulation state

This is the part that doesn’t import. Ask your current system for a current-checkouts report (everything currently out, with the patron and the item), output to Excel or CSV.

A few notes on the rest of your circulation state:

Holds. Most systems have no clean, machine-readable hold-queue export, and Lyra wouldn’t import it anyway. For a handful of open holds, capture the holds list (a screenshot is fine) and re-place them in Lyra after cutover. For a large queue, contact us and we’ll help you plan it.
Fines. Lyra doesn’t model fines or fees by design. If your school’s policy allows it, zero out outstanding fines in your old system before cutover. Otherwise, export the fines list as a paper record for your business office and let it close out in the old system.
Historical circulation (who borrowed what, years ago) is usually reportable from your old system but rarely worth migrating. Lyra doesn’t import it. If you need it for the record, archive a report and keep it.

Reconcile your circulation policies

Nearly every ILS carries circulation rules as some kind of matrix: patron types crossed with item or circulation types, with each cell holding a loan period, a holds limit, hold expiry, and (in most systems) fine and overdue-to-lost rules. A “Faculty / Reference” cell might say 30 days; a “Student / Regular” cell 14 days; a “Student / Reserve” cell 1 day.

Lyra resolves loan and pickup window from three layers in a fixed order: library defaults, a patron override (a faculty override for faculty, a grade-level override for students), and item policies. The full resolution model and examples are on the Policies page; read that first if you haven’t.

A practical approach: don’t try to recreate every cell of your old matrix. Aim for a handful of grade-level overrides (one per grade band), a faculty override if teachers’ rules differ from the defaults, and three to five item policies (Regular, Reference, Reserve, Equipment, Professional). Start there and add complexity only when a real workflow demands it.

Cut over and freeze

The night before go-live:

Run one final current-checkouts report from your old system and save the file. This is your day-one re-checkout worklist; it doesn’t import.
Mark the old system read-only: disable circulation actions for staff accounts, or take it offline entirely if your hosting allows it.
The morning of cutover, walk down the report and re-check-out each item to its patron in Lyra at Library level navigation path: Circulation then Check Out.