Your ILS Is Not Your Enemy

There's a particular kind of frustration that only library staff know. The ILS is slow. The search is terrible. The interface looks like it was designed in 2004 because it was. Cataloging takes three times as many clicks as it should. The reports module requires SQL you were never taught. And when you call the vendor, the hold music alone takes longer than the actual fix.

So you hate your ILS. Most library staff do. According to the 2024 Library Automation Perceptions Survey, which collected 1,050 narrative comments from nearly 4,000 libraries in 74 countries, the top complaints are universal: slow performance, confusing interfaces, features that technically exist but require expertise nobody at the library has.

But here\'s the thing: your ILS probably isn\'t the problem. Or at least, not the whole problem. Before you spend 12-18 months and your entire tech budget on a migration, it's worth understanding what you actually have, who owns it now, and whether optimization might save you from the most painful project in library technology.

Part 1: What Your ILS Actually Does (And What You Are Probably Not Using)

An integrated library system is a suite of interconnected modules. Most frontline staff only ever touch one of them. That's what shapes their entire opinion of the system.

What Staff Touch Every Day

Circulation. Check-in, check-out, holds, renewals, fines, patron registration. This is where frontline staff live. Every beep of the barcode scanner runs through this module. If circ is slow or clunky, the whole system feels broken, even if every other module works perfectly.

OPAC (Online Public Access Catalog). The patron-facing search interface. What patrons use to find books, place holds, manage their accounts. Many libraries now layer a discovery product on top (Aspen Discovery, Vega, BiblioCommons) because the native OPAC is often terrible. If your patrons complain about search, the fix might be a discovery layer, not a whole new ILS.

What Staff Touch Sometimes

Cataloging. Creating and editing bibliographic and item records. Copy cataloging (pulling records from OCLC or other sources) vs. original cataloging. Still uses MARC format, which dates to the 1960s and remains the backbone of library metadata whether anyone likes it or not.

Acquisitions. Ordering, receiving, invoicing. Tracks the money. This is often the most underused module because staff default to spreadsheets or vendor websites instead of learning the ILS acquisitions workflow. If your library maintains a separate spreadsheet for tracking orders, your acquisitions module is either misconfigured or nobody was trained on it. Probably both.

What Runs in the Background

Serials. Managing magazine and journal subscriptions, check-in patterns, claims. Less relevant for small public libraries, critical for academic ones.

Reports and analytics. Circulation statistics, collection analysis, overdue notices. Often requires SQL or a vendor-specific query language that nobody on staff was taught. This is where most libraries leave the most value on the table, and they don't even know it.

SIP2 and API connections. How the ILS talks to self-check machines, PC reservation systems, digital signage, and third-party services. Some vendors charge around $2,000 per SIP2 connection. Others include them at no extra cost. This is one of the biggest hidden cost differences between vendors.

The Workaround Problem

Libraries routinely maintain parallel systems because the ILS falls short: spreadsheets for tracking acquisitions, Google Sheets for collaborative inventory, separate databases for ILL and outreach, paper logs for things the ILS technically tracks but makes too hard to access.

Every workaround is a signal. Some signals mean your ILS genuinely can't do the thing. Others mean nobody configured it to. Before you migrate, figure out which is which.

Part 2: Who Owns Your ILS Now (The Consolidation Map)

The library technology market has consolidated dramatically. Understanding who owns what matters because it affects your vendor's stability, pricing power, and development priorities.

Clarivate: The Giant

Clarivate (publicly traded since 2019) now controls:

• Alma (Library Services Platform, ~2,745 libraries) and Primo (discovery) via Ex Libris
• Sierra and Polaris (traditional ILS products) via Innovative Interfaces, which Ex Libris acquired in 2019
• ProQuest (content platform, Ebook Central) acquired in 2021 for $5.3 billion

One company now controls the dominant academic LSP, two major public library ILS products, and a massive content platform. The brands still exist. The development teams are "increasingly merged and coordinated."

The Clarivate Trust Crisis

In February 2025, Clarivate announced it would phase out one-time perpetual purchases of print books and ebooks on ProQuest's Ebook Central. Libraries would only be able to subscribe to content, never own it.

The backlash was immediate. The Canadian Association of Research Libraries publicly condemned the move. Within two weeks, Clarivate's CEO apologized and extended perpetual purchase options through June 30, 2026.

The reversal doesn\'t undo the signal. This is the company that owns your ILS. They tested whether they could eliminate ownership of digital content, and they\'ll test it again. If your library runs Sierra or Polaris, you're not directly affected by this specific decision. But you're affected by the priorities of the company making it.

SirsiDynix: The Latest Acquisition

SirsiDynix (Symphony, Horizon) was acquired by Harris Computer in December 2024, a subsidiary of Constellation Software. After cycling through private equity ownership for a decade, this may actually be good news. Constellation doesn't resell companies it acquires. This is intended to be a permanent home.

The concern: staff have reported that SirsiDynix keeps building new add-on products (BLUEcloud, CloudSourceOA) while the core ILS falls further behind. Development focus goes to customers who pay for premium subscriptions, not base Symphony users.

The Rest of the Field

• OCLC (nonprofit) offers WorldShare Management Services (WMS), an LSP primarily for academic libraries already deep in the OCLC ecosystem.
• EBSCO is the primary commercial supporter of FOLIO, the open-source LSP. They signed 159 contracts in 2024.
• ByWater Solutions supports Koha (1,653 locations in the US).
• Equinox Open Library Initiative supports Evergreen (895 locations) and also offers Koha support.

Part 3: When to Migrate vs. When to Optimize

Migration is the most resource-intensive project in library technology. Before committing to one, be honest about whether your problem is the software or everything around it.

Red Flags: Time to Migrate

1. Vendor sunset or acquisition instability. If your vendor has been acquired twice in five years, or if your product is clearly in maintenance mode with no new development, the writing is on the wall.
2. No API or modern integrations. If your ILS can\'t connect to third-party services without expensive proprietary middleware, you're trapped.
3. Data hostage situation. If you can\'t export your bibliographic records, patron data, and circulation history in standard formats on demand, you\'ve got a vendor lock-in problem.
4. Cost escalation without value. Annual increases exceeding 5-8% with no new features or improvements.
5. SIP2 costs are out of control. Paying thousands per connection for what should be standard interoperability.

Green Flags: Stay and Optimize

1. Underused features. Most libraries use 30-40% of their ILS capabilities. Before migrating, conduct a feature audit. Your acquisitions module might actually work if someone configures it.
2. Training gaps, not software gaps. "I don\'t know how to do X" is a training problem. "The system can\'t do X" is a software problem. These require different solutions.
3. Configuration issues. Many ILS problems come down to system preferences, notice templates, hold policies, fine rules. A good systems librarian or vendor support session can fix these without a migration.
4. Stable vendor with active development. If your vendor is releasing updates, responding to support tickets, and has a user community, optimization is almost certainly cheaper than migration.

The Feature Audit

Before any migration decision, answer these questions:

1. Which ILS modules does your library actively use? Which ones have you never opened?
2. Where are you maintaining parallel systems (spreadsheets, paper logs)? Is that because the ILS can't do it, or because nobody configured it to?
3. When was the last time anyone attended vendor training or explored new features?
4. What are your top five daily frustrations with the system? Are they interface issues, configuration issues, or genuine missing functionality?

If most of your frustrations trace back to configuration and training, not fundamental software limitations, a migration will just give you a fresh set of problems without solving the old ones.

Part 4: Migration Realities (What Nobody Tells You Upfront)

If you've done the audit and migration is genuinely the right call, this is what the process actually looks like.

Timeline

The actual data migration takes 5-6 months. The full project, including planning, vendor selection, RFP process, contract negotiation, and training, takes 12-18 months. Build in a 2-4 week delay cushion at minimum. One library district couldn't order physical materials for the final three months of their migration year.

The Vendor Demo vs. Reality Gap

Every vendor demo shows polished workflows with clean data. Reality includes configuration options that were never set up during implementation, features that technically exist but require a level of systems expertise the library doesn\'t have, report tools that require SQL or proprietary query languages, and modules that go unused because they\'re too complex for the staff available.

That\'s not unique to any one vendor. It\'s the nature of complex software deployed in environments with limited IT capacity. Be skeptical of any demo that makes everything look easy.

What Migrates Cleanly

• Bibliographic records: MARC export is standard. Every ILS can do this. Easiest data to move.
• Patron records: The basics (name, address, barcode, expiration date) migrate cleanly. Notes, messages, and custom fields often don't.
• Item records: Barcodes, locations, statuses, call numbers. Generally exportable but format varies.

What Does Not Migrate

• Configuration: Hold policies, notice templates, circ rules, system preferences. You rebuild all of this from scratch.
• Custom reports: Every report you built stays in the old system.
• Circulation history: Patron checkout history often can't be exported in bulk.
• Staff muscle memory: Every workflow changes. Every saved shortcut breaks. Expect 6-12 months of reduced productivity post-migration.

Support Quality After Migration

One library reported that after migrating to a new system, "many tickets submitted to the support provider fell through the cracks" and the vendor was "unresponsive to support requests since migration completion." That's not unique to any one vendor type. Ask every vendor for references from libraries that migrated in the past 12 months, not three years ago. Recent experience tells the real story.

Part 5: Open Source (What It Actually Costs)

The two major open-source ILS options are Koha and Evergreen. The software is free. The costs aren't.

Koha

Best for single-branch or small multi-branch libraries, special libraries, and libraries wanting maximum flexibility. Largest global open-source ILS community.

• Support: ByWater Solutions (largest US provider), Equinox, PTFS, and others globally
• Strengths: No vendor lock-in. No licensing fees. No charge for SIP2 or API connections. Active development community. Highly customizable.
• Weaknesses: Requires a support contract or internal IT expertise. The staff interface, while improving, still feels utilitarian.

One Koha user summarized the cost difference: "After seeing Koha and how inexpensive it is, with vendors not charging for SIP2 or API/Web services connections, we have been paying far too much for far too long."

Evergreen

Best for large multi-branch public library systems and consortia needing sophisticated resource sharing. Purpose-built for consortial environments.

• Support: Equinox Open Library Initiative (nonprofit)
• Strengths: Strong print circulation. Robust holds and transit management across branches.
• Weaknesses: Smaller community than Koha. More complex to administer. Not ideal for single-branch libraries.

The Real Costs of "Free" Software

• Hosting: Cloud hosting through ByWater or Equinox costs significantly less than most commercial ILS annual fees, but pricing depends on library size
• Support contracts: Annual support covers implementation, training, ongoing support, and upgrades
• Customization: Any local development or custom features require developer time
• Staff time: Someone needs to be the local ILS expert. In a commercial environment, you call the vendor. In open source, you can call your support provider, but you also have the option and sometimes the need to dig into the system yourself

Equinox offers "Koha On Demand" designed to be cost-effective for libraries with fewer than 50,000 titles. If you're a small library considering open source, start there.

Who Should Not Go Open Source

• Libraries with zero IT capacity and no budget for a support contract
• Libraries whose staff are deeply resistant to change and whose administration won't invest in training
• Libraries that need hand-holding through every configuration change (though support providers do offer this)

Who Should Consider It

• Libraries paying excessive licensing and SIP2 fees for features they don't use
• Libraries frustrated by vendor lock-in or vendor instability
• Libraries in states or regions with strong Koha or Evergreen consortia
• Libraries with even one technically curious staff member willing to learn

Part 6: Do You Need a Library Services Platform?

Vendors, especially Clarivate, are increasingly pitching Library Services Platforms (LSPs) to public libraries. An LSP is architecturally different from a traditional ILS: designed from the ground up to manage both print and electronic resources, built-in knowledge bases for managing large-scale e-resource collections, cloud-native and multi-tenant.

The three main LSP options are Alma (Clarivate/Ex Libris), FOLIO (open source, EBSCO-supported), and WorldShare Management Services (OCLC).

The Short Answer for Small and Medium Public Libraries

You almost certainly don't need one.

LSPs are built for managing complex, multiformat collections with thousands of electronic subscriptions. A small public library with a Libby account and a handful of database subscriptions doesn't need this. The 2024 Perceptions Survey consistently shows that "ILS products continue to be favored by public and school libraries with smaller budgets and limited collections of electronic resources."

Small and very small public libraries "gave excellent marks to proprietary ILS products" and "give superlative scores to products able to meet their basic requirements without complex features they do not need."

FOLIO: The Open-Source LSP

FOLIO is growing fast (159 contracts in 2024), but it's still maturing. Staff describe FOLIO implementation as "a frustrating experience that has required a massive amount of staff time and energy to do basic library tasks." Print circulation functionality "still is not on par with legacy systems that were primarily built for print circulation." Patrons "routinely run into unexpected issues."

FOLIO may be the right choice for academic libraries with large electronic resource collections and the staff capacity to ride out a complex implementation. It's not ready for a small public library that needs reliable print circ above all else.

The Sales Pitch Test

If a vendor pitches you an LSP, ask one question: What specific problem does this solve that my current ILS can't?

If the answer is about managing thousands of electronic resource subscriptions and you manage five database subscriptions through a simple link resolver, you don't need it. If the answer is "future-proofing," ask what specifically they mean by that, because "future-proofing" is a sales term, not a technical specification.

Part 7: Protecting Your Data (Before You Need To)

Test Your Exports Now

Don\'t wait until you're mid-migration or mid-crisis to find out whether you can get your data out of your ILS. Test these today:

1. MARC export: Can you export your bibliographic records in standard MARC format?
2. Patron export: Can you export patron records as CSV?
3. Item export: Can you export item-level data (barcodes, locations, statuses)?

If the answer to any of these is "I don\'t know" or "I need vendor assistance," that\'s a red flag you should address now, not later.

Vendor Lock-In Tactics to Watch For

• Charging for data exports or requiring vendor assistance to export
• Using proprietary extensions to MARC that don't translate to other systems
• Bundling ILS with discovery, content, and other services so leaving one means losing all
• Multi-year contracts with auto-renewal clauses and early termination fees
• Making SIP2 and API access paid add-ons rather than standard features

Document Your Configuration

Circ policies, hold rules, notice templates, report queries. Take screenshots. Save them somewhere outside the ILS. This doesn\'t migrate automatically, and you\'ll need it whether you switch systems or just need to rebuild after an update goes wrong.

Read Your Contract

Specifically look for data ownership and export clauses. Ask your vendor what format your data would be delivered in if you left. If they hesitate or add conditions, you have your answer about how that relationship would end.

So Should You Stay or Go?

Your ILS isn\'t your enemy. It\'s a complex tool deployed in an environment with insufficient training, insufficient IT support, and a vendor landscape that has consolidated to the point where a single company can threaten to eliminate content ownership and then apologize when libraries push back.

The frustration is real. But the solution isn't always migration.

Your move. Pick one of these before Friday:

1. Run a feature audit. List every ILS module you use and every workaround you maintain. Figure out which workarounds exist because the ILS can't do the thing vs. because nobody configured it.
2. Test your data exports. Can you get your MARC records, patron data, and item records out of the system right now? If not, fix that before anything else.
3. Read your contract. Know your renewal date, your termination clause, your data ownership terms, and what you're paying for SIP2 connections. Write it down somewhere your successor can find it.

Whether you stay or go, you need to understand what you have. That starts with looking at your ILS not as the source of your frustration, but as one piece of a larger system that includes training, configuration, vendor relationships, and your own institutional knowledge. Fix what you can control before you replace the whole thing.