Jeff Campbell (UNC Chapel Hill) & Stephanie Brew · 4:30–5:30 PM · Chicago Ballroom A · Sierra Track · Wednesday, April 15
Speaker: Jeff Campbell
An open forum for Sierra system administrators — Jeff’s last time hosting. Wide-ranging discussion covering Sierra-to-Polaris migration considerations, invoicing workarounds, Koha feasibility, bot protection strategies (Cloudflare, F5, fail2ban), locations served and paging configuration, SDA vs. Sierra Web, WebPAC accessibility challenges, and circ active date behavior with e-vendor APIs.
Show of hands: 2 definite, 4 maybe considering Sierra-to-Polaris migration. Polaris pricing is similar to Sierra renewal costs, but there’s an additional unknown implementation cost on top. Pricing should be negotiable — one attendee just renewed Sierra for 3 more years at comparable rates.
A sales rep deflected on pricing at lunch — an attendee pushed back: “I’m the one who has to get it approved… Our board isn’t going to just say oh yeah spend another hundred thousand.”
One attendee: “I feel like it’s now or five years from now” — the renewal cycle is the natural decision point.
A consortium hired Marshall Breeding for a landscape report. After 20 years on Sierra, his conclusion: “Stay on Sierra for the moment and do a deep dive in about three years, maybe five.”
III themselves recommended staying on Sierra — at PLA, an attendee’s assistant director spoke with III reps and “that was their recommendation. Stay on Sierra. You’re good here.”
An attendee evaluated Polaris: “It couldn’t be just a hair better, it had to be like this much better, and it wasn’t… not worth everything that comes with the migration.”
End users driving the push — people who migrated Sierra-to-Polaris said the common denominator was end users wanting “something that looked a little bit more modern.” Staff hired from Polaris libraries miss things from a technical perspective.
The true cost extends far beyond the contract: Aspen discovery layer migration, 72+ hours of downtime, communications team, staff training, morale. “Your staff want Polaris because it is pretty but do they want to go through all of that?”
A consortium’s ILS RFP took 9 months. Consortium constraints limit choices: “Our only two choices are Sierra or Polaris.”
Contact Derrick Brown for a Polaris demo — someone offered to show how Polaris works.
A small standalone library stopped using Sierra invoicing when their municipality switched finance systems. A year and a half later, unprocessed invoices are blocking order record deletion (~6,000 records). Can’t do global updates on status codes — would have to change each one manually. Innovative support confirmed the problem and has been manually force-clearing on their end.
Budget pressure is driving Koha interest: “We don’t have concrete plans but we are getting a lot of budget pressure to look at another ILS.”
Another attendee came from Koha to Sierra — they loved the flexibility (direct SQL querying was great).
Jeff (UNC): “We have 20 million records, almost 23 million… large library consortiums struggle with Koha and they could not handle our records.”
Jeremy (Minuteman Library Network — a Sierra consortium in Massachusetts): other MA consortiums are on Koha/Evergreen; as staff move between libraries there’s “an influx of staff who are used to open source systems… Sierra is sort of railing to them.” That said, the Minuteman Consortia office staff “are extremely happy” with Sierra.
One attendee feels locked into Lyngsoe Systems (automated materials handling / book sorter). Only certain ILS vendors support integration: Sierra supports it, SirsiDynix supports it, Polaris is working on it. This significantly limits ILS migration options.
Jeff: “The ILS you have is the best ILS.”
Victor: his library has a “sister library” on Koha — “Acquisitions and cataloging are not quite as mature as Sierra.” His advice: identify what features are essential and make sure the new ILS has them. “That kind of frames the conversation into that specific set of requirements. As opposed to like, well the other one was nice, but functionally speaking that doesn’t do anything.”
Victor’s pragmatic filter for complaints: “We have people say oh we hate Sierra… some of those opinions may be valid but it’s one person and we’re catering to over 99%.”
Jeremy: “The system you start with is kind of what you imprint on” — echoed by multiple attendees.
Jeff: “I don’t think it’s any secret that they’re not selling a lot of Sierra subscriptions in the United States. But it sounds like it is doing better overseas.” Saudi Arabia deploying Sierra for 175 libraries.
Public libraries are going Polaris — III would “absolutely encourage them to buy” Polaris for public libraries.
Roughly 2/3 Polaris, 1/3 Sierra at IUG — Jeff predicted “that’s probably going to become more lopsided.”
“One company with two competing products seems curious” — the elephant in the room about Clarivate/III having Sierra, Polaris, Millennium (legacy), and Leap all active. There are still a few Millennium customers.
The migration was a “nothing burger” — Jeff was a beta institution: staff were terrified but “Oh, new color scheme. Great.” Intentional design decision to keep it similar, but “the interface felt dated already when it came out.” “They got rid of the mountains” (Sierra splash screen reference).
The “looks old” complaint is the #1 thing Polaris fans say.
“Pretty things are usually shallow. If you focus on the UI first, the power behind it is not as strong. That’s how databases work.”
Jeff’s pushback: “Why does the look matter more than the functionality? Is it to please my younger users, my Gen Zers?”
“This is not an end user system. This is not meant to be used by someone who has never been trained before.”
Lost 55 staff due to hiring freeze — migration impossible without adequate staff. Part of Triangle Research Library Network (Duke, NC State, NC Central). Getting Rapido because partner institutions moved to Alma, but don’t have budget/staff to migrate.
Overrides are a problem — consortium/shared system admin actively discourages staff from using overrides to reduce downstream data cleanup.
Patron override coming to Vega — once it arrives, front-line staff expected to “stop using the actual Sierra client and go exclusively in Vega for everything.”
Remote desktop user reporting issues with SDA — failure to log in or initialize once or twice a week. Updating the JRE to the most recent version dramatically improved SDA startup (“night and day”), though “not perfect.”
Growing sentiment that more reliance on Sierra Web is important — one speaker noted “Leap is going to be a more sustainable platform than the Sierra desktop app.”
Some libraries are ~50-50: front desk/circ on Sierra Web, collection management staff still on SDA.
ERM (Electronic Resource Management) is bad in Sierra Web — electronic resources person at one library “hates Sierra Web” and refuses to give up the desktop app. Sierra Web only works properly in Chrome, not Firefox.
Pagination is painful in Sierra Web — editing records that get paginated is bad enough to drive users back to SDA.
One user couldn’t see expected menu functions despite having all permissions — workflows (which control dropdown menus) are configured separately from permissions.
Multiple libraries are getting “dinged” about accessibility of the classic WebPAC. Even if you don’t point patrons to it, it’s still publicly accessible, which “alarms our accessibility people.”
Libraries want to hide classic catalog from public but keep it for staff — no one has found a solution yet. Firewall approaches tried; ticket open with Innovative.
A “very small core set of patrons” still use the classic catalog and are already complaining. Catalogers “will revolt” if classic is removed entirely — staff still depend on it.
Patron registration forms are served through WebPAC — another dependency that blocks removal.
Innovative may be “working with somebody to figure out how to disable it” — uncertain.
“We fixed everything you can fix using the templates.” The remaining failures are in server-side code: “Your template calls this function and then magic happens on the back end, and the magic is broken. You can’t fix it in post.”
Some exploring Vega Discover as a WebPAC replacement. Good to see other people concerned about WCAG compliance.
Bulk updating patron records is difficult because the circ active date gets updated whenever a patron record is modified (including via API) — makes it unreliable for purging inactive patrons.
Mike Dicus (Clarivate) confirmed a new API enhancement coming: for e-vendors (Hoopla, Overdrive) validating patrons, the record won’t get its “last updated” date changed, but the circ active date can be set to indicate the patron is using e-resources. However, it does not take a date parameter to backdate. Toggle is “all or nothing.”
Action item: everyone should contact Hoopla/Overdrive to push them to adopt the new validation method.
Someone has a script workaround for this issue.
Someone implemented Cloudflare on Monday morning to stop bot/DDoS attacks — it stopped the bots but also blocked all staff from Sierra and Sierra Web. Associated resources authenticating against Sierra also broke. They were “desperately trying to get lists of IPs from different vendors” to whitelist.
Advice: become “best friends with your networking team” — use Admin Corner in Sierra to get list of currently connected IPs to feed to firewall allowlist.
Another library’s firewall upgrade broke Sierra connectivity because “they didn’t really consider Sierra before they upgraded the firewall.”
Went behind F5 for bot control starting 2024–2025, cost $30,000/year and “they weren’t really providing much after that initial catch up.” Switched to block lists and fail2ban “in a fairly robust way.”
Set up a separate hostname — public-facing domain behind F5 for bot protection, different one for internal services. Currently “hardly any bot now” on Sierra, but digital library hosts still getting hit (38K–120K bot attacks daily). Offered to share setup via email.
III can put a blocker on your Sierra host — if a client claims to be a browser version more than 3 versions old, it gets blocked. Everything rewritten to denied. Rarely catches legitimate users (maybe one every few months). When bots get rebuilt and start claiming newer versions, they just update the block. “Whack-a-mole, but it does work.”
Advantage: didn’t lock any API access or integrations because legitimate integrations don’t claim to be browser versions.
Justin: bot blocking is a game of whack-a-mole — “once the bots pretend they are version 144, then we’ll get 400,000 requests one morning” and they just block all 144s. AI can help write those rewrite rules.
Jeff: has a dedicated sysadmin who “attacks this constantly.” Offered to share fail2ban rules and set up a call with “Joe” — contact Jeff directly. Credited Justin for the old browser trick. Applied same rule sets to protect ArchivesSpace and other digital asset management systems.
III currently uses fail2ban and is moving to Cloudflare in June/July 2026. ByWater Solutions (Koha hosting) already uses Cloudflare.
| Approach | Pros | Cons |
|---|---|---|
| Cloudflare (reverse proxy/WAF) | DDoS mitigation, bot filtering, SSL termination, caching, free tier | Can block staff and integrations if not configured carefully; only HTTP |
| F5 BIG-IP | Full protocol support, session persistence | $30K/year; “weren’t really providing much” after initial setup |
| fail2ban + block lists | Free, effective for known patterns | Requires dedicated sysadmin effort; constant maintenance |
| III’s crawler blocker (old browser trick) | Simple, doesn’t break APIs/integrations | Whack-a-mole; bots adapt their version strings |
X-Forwarded-For / CF-Connecting-IPSee full guide: Cloudflare Protection for Sierra ILS — Practical Guide
Bob: order of locations served matters — he actually read the manual (hat tip to Dan and Dave Blizinski as knowledge sources).
Drives the paging list — pickup location matches the first group it encounters going down the list, so supersets must come before subsets or items will fail to page.
Issue: items getting picked up while the paging list is still being processed. Discussion around title-level priority paging and item-level vs. title-level paging — a key distinction.
| Aspect | Item-Level Paging | Title Priority Paging |
|---|---|---|
| Slip format | One slip per item | One list with all eligible items |
| Priority table | Library Priority table (0–99) | Hold Pickup Locations table, Paging Priority field (0–999) |
| Items targeted | Single item at highest-priority branch | All eligible items across multiple locations |
| Cycling/escalation | Not built-in | Automatic — cycles through priority tiers |
| Permission | 358 | 394 |
Catalogers have deep workflows baked into Sierra — record templates and macros are critical to cataloger performance. “Our catalogers will revolt” if classic is removed.
Switching to Polaris remains a hot topic in the room.
IUG 2027 will be in Boston.
