Your integrated library system works. Mostly. It crashes occasionally. The self-checkout goes down every third Tuesday. The catalog search returns weird results for reasons nobody understands. But overall, it functions.

You know why it functions? Hope. And one person who knows where all the bodies are buried.

The Single Point of Failure Problem

Every library has That Person. The one who’s been there for 15 years. The one who remembers why the system is configured that weird way. The one everyone calls when something breaks.

That Person is your single point of failure.

When they’re on vacation, things break and stay broken until they get back. When they’re sick, projects stall. When they retire, the library descends into chaos for six months while everyone figures out what they actually did.

This is not sustainable. But it’s how most libraries operate.

Why Your ILS Is Actually Broken

Let’s be honest about what’s holding your system together:

Undocumented Workarounds

Your ILS doesn’t do something it should do. So That Person created a workaround. Maybe it’s a cron job that runs at 2am. Maybe it’s a manual process nobody else knows about. Maybe it’s a script that lives on their desktop.

The workaround works. But it’s not documented. And when That Person leaves, the workaround stops working and nobody knows why.

Technical Debt You Can’t See

Your system was implemented 10 years ago. The vendor pushed updates. Your team applied some of them. Others got skipped because they might break things.

Now you’re three versions behind. Security patches are missing. New features don’t work because they assume you’re on the current version. But upgrading is scary because nobody remembers what customizations were made or why.

Customizations Nobody Documented

Your library had specific needs. The vendor said “we can customize that.” Someone made changes to the database directly. Or modified configuration files. Or wrote custom scripts.

Those customizations made the system work for you. They also made it impossible to upgrade without breaking everything.

And nobody wrote down what was customized or how to recreate it.

Integration Duct Tape

Your ILS talks to other systems. Your payment processor. Your authentication system. Your website. These integrations were set up years ago by someone who’s not here anymore.

They work. Until they don’t. And when they break, nobody knows how to fix them because the integration is held together with API calls nobody documented and credentials nobody can find.

The Vendor Doesn’t Actually Help

Your vendor’s support is “limited to configuration issues.” Translation: if it’s their bug, they’ll fix it eventually. If it’s your customization, you’re on your own.

That’s why you rely on That Person. Because calling vendor support is a three-day process that ends with “works as designed” or “not in scope.”

What Happens When That Person Leaves

Here’s what happens when That Person retires, quits, or gets hit by a bus:

Week 1: Panic. Everyone realizes how much they depended on that person.

Week 2: Things start breaking. The nightly backup fails. The self-checkout stops accepting payments. Nobody knows how to fix it.

Week 3: Vendor support is called. They can’t help because the issues involve customizations their documentation doesn’t cover.

Month 2: Someone figures out one of the workarounds. Three others remain mysterious.

Month 6: The library either hires an expensive consultant to reverse-engineer everything or decides to migrate to a new system because this one is too fragile.

Either way, it costs a lot of money that wasn’t budgeted.

Why This Keeps Happening

Libraries end up in this situation for predictable reasons:

Budget Reality

You don’t have money to maintain systems properly. So you hire one person to do everything. That person becomes irreplaceable because there’s nobody else.

Vendor Lock-In

Your vendor makes it hard to leave. Migration is expensive. Data export is complicated. Training on a new system takes months. So you stay with the broken thing you know.

Lack of Documentation Culture

Nobody has time to document processes because everyone’s too busy keeping the system running. The cycle continues.

Fear of Change

Upgrading might break things. So you don’t upgrade. Which means you fall further behind. Which makes upgrading even scarier.

What Actually Fixes This

Fixing this requires uncomfortable changes. But here’s what works:

Document Everything

Yes, it’s boring. Yes, it takes time. Do it anyway.

Every workaround. Every customization. Every integration. Every weird configuration decision. Write it down.

Use a wiki. Use a shared doc. Use whatever system people will actually maintain. Just document it.

Cross-Train Aggressively

That Person needs to train other people. Not just “here’s how to do this task.” Actual understanding of why things work the way they do.

Rotate responsibilities. Make sure at least two people can handle every critical task.

If That Person pushes back because “it’s too complicated,” that’s a sign your system is too complicated.

Budget for Maintenance

Stop treating system maintenance as free. It’s not.

Budget for:

  • Regular upgrades
  • Security patches
  • Documentation time
  • Redundancy (backup people, not just backup data)

If you can’t afford to maintain a system properly, you can’t afford that system.

Reduce Customization

Every customization is technical debt. Ask yourself: does this customization provide enough value to justify the maintenance cost?

If not, cut it. Use the vendor’s standard features even if they’re not perfect. Perfection is expensive.

Have a Succession Plan

What happens when That Person leaves? Write it down. Make sure the plan includes:

  • Knowledge transfer timeline
  • Documentation requirements
  • Overlap period with replacement
  • Budget for consultant help if needed

Test the plan before you need it.

The Uncomfortable Truth

Your ILS is held together with hope because libraries are chronically underfunded and nobody wants to admit how fragile everything is.

Administrators don’t want to hear that the system could collapse if one person leaves. Boards don’t want to budget for invisible maintenance. Staff don’t want to take on more responsibility.

So everyone pretends it’s fine. Until it’s not.

The fix requires admitting the problem exists and spending money to solve it. Neither of those things is fun.

But the alternative is worse. The alternative is spending six months in crisis mode when That Person eventually leaves. And they will leave. Everyone does eventually.

Start documenting now. Start cross-training now. Start budgeting for maintenance now.

Or keep hoping nothing breaks. Hope is free. It’s also a terrible strategy.

Stop hoping. Start fixing. Before That Person leaves.

Authenticity note: With the exception of images, this post was not created with the aid of any LLM product for prose or description. It is original writing by a human librarian with opinions.