Academic Library Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why do library software projects drift into rebuilding the platform?

The brief starts sensibly. Fix link resolution. Then somebody observes that the resolver depends on holdings, holdings depend on acquisitions, acquisitions depend on the fund structure, and by week six the proposal contains a circulation module. This is the most common way library development money is wasted, and it happens because everything inside a library services platform genuinely is connected.

The specific trap here is that the platform vendors have spent well over a decade on cataloguing, circulation and acquisitions. Ex Libris Alma, FOLIO, Koha and OCLC WorldShare all handle those functions to a standard no first release will approach. A project that begins as entitlement reconciliation and ends as a replacement catalogue ships late, ships thin, and is compared daily by your own staff against a product built by a team of dozens.

The fix is a written boundary agreed before the first sprint. The platform stays the system of record for bibliographic data, patrons, loans and orders. The custom work reads from it and writes back through its interfaces, and anything that requires replacing a platform function is out of scope and stays out, even when it looks like a small addition. In our delivery experience the library projects that hold three or four precise objectives finish and get used. The ones that accumulate a fifth and a sixth get cancelled at the point where the money has been spent and nothing is in production.

What goes wrong when you migrate decades of MARC records?

Your bibliographic data is not generic. It carries local practice going back decades. A 590 note that means something specific to your institution. Item types that encode circulation policy rather than describe an object. Location codes referring to a building demolished years ago. Serials holdings statements written in the style one cataloguer used for eleven years. None of this is documented, because it was never intended to leave the system it was created in.

The failure mode in a library migration is almost never a crash. It is the quiet loss of a category. A material type maps to nothing and disappears. A note field used for donor acknowledgement lands in a display field and starts showing on the public catalogue. Boundwith relationships break and the second title stops being findable. Nobody notices for months, because the counts look approximately right and the records people search for most were the ones tested.

The fix is unglamorous. Profile the legacy data first and report honestly on what will not map, before anyone agrees a cutover date. Write the transformation rules as tested code rather than as a vendor spreadsheet, so a rule change re-runs in minutes instead of triggering another extract. Reconcile after load by comparing counts and samples per material type, per location and per record status, not in aggregate. And keep a queryable copy of the legacy data for about two years, because someone will ask a question the new system cannot answer and the alternative is a restore from tape.

Why do knowledge base feeds and proxy integrations break after launch?

The integrations that matter in a library are the ones nobody watches. KBART title lists from each content provider. COUNTER 5 usage harvested over SUSHI. EZproxy stanzas or an OpenAthens configuration standing between your users and every platform you licence. A link resolver reading a vendor maintained knowledge base. These are standards, and providers implement standards with real variation, which is the whole problem.

Things break in specific and predictable ways. A provider renames a column in a KBART file and your ingest silently drops a field. A SUSHI endpoint moves and the harvest stops, and because usage reporting is a quarterly activity nobody notices until renewal season. A publisher redesigns their platform and the proxy stanza that used to work now fails on a subdomain. None of these produce an error message anyone in the library sees. They produce users who cannot get to content and do not complain.

The fix is to treat every feed as untrusted input and to alert on absence rather than only on failure. Validate each file on arrival against expected row counts and column names, and raise a ticket when a provider file does not arrive at all, which is the more common failure. Then add synthetic link checks: overnight, resolve a sample of links you know should work across your major providers, and open a queue entry for each one that lands somewhere other than full text. That queue is the closest thing this sector has to a smoke alarm, and almost no library has one.

What happens when licence terms are not in the system?

Can this journal be supplied through interlibrary loan. Can this ebook go on course reserve. Does walk in access cover the public. Do you hold post cancellation rights on this backfile and for which years. Is text and data mining permitted. Every one of those questions has an answer in a signed agreement, and in most libraries the answer is produced by a licensing librarian from memory or by opening a PDF and reading it.

Two failures follow. The first is refusal of something you are entitled to do, which is a service loss nobody measures because the requester simply goes elsewhere. The second is the reverse, and it is worse: supplying something the licence prohibits, which is a breach your institution carries. There is a third, specific to consortia. A shared print agreement commits your library to retain named titles for a defined period, and a deselection project run against shelf space rather than against retention obligations will withdraw volumes your group promised to keep.

The fix is making terms operational rather than reference. Both Alma and FOLIO can hold structured terms, and the reason those fields sit empty is that entering them is slow and the benefit is invisible until an interlibrary loan request arrives at four in the afternoon. So wire the decision into the workflow. The loan system asks the licence at request time and returns an answer with the governing clause attached. The reserves workflow does the same. Deselection proposals are checked against retention commitments automatically. Once a system is producing decisions rather than storing notes, the data gets maintained, because staff feel the cost of it being wrong.

Should you build custom or configure what you already own?

Configure, for a great many libraries, and we will say that plainly. A single campus library under roughly $500,000 in collections spend should run Koha or OCLC WorldShare as they come and put the difference into content and staff. The gap between what you have configured and what you could configure is usually larger than the gap between the product and a custom build. Alma has an electronic resource management module capable of holding licence terms, and most libraries that complain terms are unqueryable have simply never populated it. FOLIO has apps you may not have enabled.

Configuration also wins when the requirement is really a policy decision wearing a technical costume. If two departments disagree about fund structure, no software resolves that.

Build around the platform when two or more of these hold. Your link resolution failures are known to be significant and nobody owns the reconciliation between entitlements and the knowledge base. Your consortium has rules that no vendor configuration expresses and the only person who knows them is the group's operations manager. Fiscal year end reconciliation against your institutional finance system takes weeks of a senior person's time. Or you are on FOLIO and have identified a specific workflow where a module is cheaper than the workaround you are living with. FOLIO is the one case in this sector where building rather than working around is genuinely sensible, because the architecture was designed for it.

How do hidden costs get into the quote?

The costs that surprise libraries are not engineering costs. They are discovery and coordination costs, and they are structural to this sector.

The first is the number of content providers whose files you must ingest. A quote written against three providers and delivered against fourteen is not the same project, because each provider brings its own interpretation of KBART, its own SUSHI quirks and its own idea of a title identifier. Count them before you sign.

The second is consortium size. Every member institution brings its own policies, its own opinions and its own meeting schedule. A rule that takes an afternoon to write takes six weeks to agree across twelve libraries, and that time is real project cost even when no code is being written.

The third is the authentication estate. EZproxy configuration is a workstream. An OpenAthens or SAML migration is a bigger one, and it usually belongs to central IT rather than to the library, which means it moves at their pace.

The fourth, and the one that most often blows the schedule, is the condition of your legacy data. A quote that assumes clean records and encounters forty years of local practice will be renegotiated. Insist that data profiling happens first and is priced as its own small piece of work, so both sides are estimating against evidence rather than hope.

What separates a build that works from one that fails here?

Four things, consistently. The first is a named owner inside the library who can make decisions, usually the head of electronic resources or collection services. Library projects governed by a committee produce requirements that are the sum of every attendee's wish list and satisfy nobody.

The second is one measurable outcome agreed at the start. Reduce unresolved link failures on a named sample. Cut fiscal year end reconciliation from three weeks to three days. Produce a weekly entitlement exception list somebody actually works. Projects with a number attached get finished because progress is visible. Projects justified by improved workflow drift.

The third is staff time budgeted honestly. Somebody in the library has to answer questions, review sample data and test. If that person is also running renewals, the project will stall in exactly the weeks it most needs attention. Name them, and protect their calendar.

The fourth is ownership settled in writing before kickoff: the repository, the cloud accounts, the right to hire another firm, and for FOLIO work an agreement on what goes back to the community. At Digital Heroes the client owns the code from the first commit. Libraries keep institutional memory far longer than they keep vendor relationships, and your local logic should outlive both.