Almost everything libraries want to change in Koha is achievable. The real question is not can it be done but what will it cost you at every upgrade for the next ten years.
Customization in Koha is a ladder. Configuration survives upgrades. Forked templates do not. Every rung up buys more control and more standing cost. The skill is achieving the goal from the lowest rung that will reach it.
The five levels
| Level | What it can do | Skill needed | Upgrade risk |
|---|---|---|---|
| 1. System preferences | A surprising amount of behaviour and display | Librarian | None |
| 2. CSS / JS injection | Branding, layout tweaks, added content | Web basics | Low |
| 3. Custom fields & frameworks | Local data, cataloging structure | Cataloger + admin | Low |
| 4. Plugins | New features and integrations | Developer | Moderate |
| 5. Core code changes | Anything | Perl developer | High, forever |
Level 1 — System preferences
Hundreds of settings, and most libraries never explore them. Before commissioning any work, check whether a preference already does it — the answer is often yes.
High-leverage areas: what the OPAC displays and hides, search behaviour and default sorting, circulation behaviour, holds policy, and self-registration. Free, instant, and upgrade-proof.
Level 2 — OPAC branding with CSS and JS
OPACUserCSS and OPACUserJS inject your own styles and scripts into every OPAC page. This is how most libraries apply their institutional colours, logo and typography, and add blocks of content the theme does not provide.
Keep the contents in version control, outside Koha. A system preference is a text box in a database — easy to overwrite, impossible to diff, and gone if someone restores an older backup. Paste from your repository into Koha, not the other way round.
Use JavaScript sparingly. CSS that fails degrades to unstyled; JavaScript that fails can break a page for every patron.
Level 3 — Custom fields and frameworks
Patron attributes add fields to member records — student number, department, programme. Item-level custom data and MARC framework changes let you catalog local material properly. See our MARC21 guide.
Structural, but done through the interface rather than code, so upgrades carry it forward.
Level 4 — Plugins
Koha's plugin system allows added functionality without touching core code. Before installing a third-party plugin, check when it was last updated, whether it declares support for your Koha version, and whether you could maintain it if the author stopped.
Plugins are the right level for integrations. They are not free of upgrade risk — a plugin can break on a new Koha release — but a broken plugin is a contained problem.
Level 5 — Core code changes
Modifying Koha itself does anything you want and creates a permanent obligation: every future upgrade becomes a merge. You now maintain a fork, twice a year, forever, and the person who wrote it will not always be available.
Sometimes justified. When it is, contribute the change upstream. If it is accepted into Koha, your customization becomes everyone's feature and your maintenance burden goes to zero. This is the single best piece of advice in this article and it is regularly ignored.
Customizing the staff interface
IntranetUserCSS and IntranetUserJS do for staff what their OPAC counterparts do for the public. Treat staff-side changes with more caution: a broken OPAC page is embarrassing, a broken checkout screen stops the library working.
Multi-branch and multi-library customization
Koha configures a good deal per branch — circulation rules, holds behaviour, item defaults. Where it stops is presentation. Branches largely share one OPAC appearance, and the common request from a group of institutions — each library wants its own branded catalog at its own address — is not something core Koha does.
Libraries usually solve this by running a separate instance per library, which multiplies every maintenance task by the number of members, or by accepting one shared appearance.
There is a third answer: each library having its own branded catalog and its own address as configuration rather than forked code, so it costs nothing at upgrade time — because the upgrades are somebody else's job. That is how per-library branding with no upgrade cost works, and it is the case where the ladder above stops applying.
What we will not do, and why
We decline core code changes when a lower rung reaches the goal, because we would be selling you a permanent liability to solve a temporary problem.
When a core change is genuinely necessary we will say so, quote it, explain the standing upgrade cost in writing, and recommend upstreaming. A vendor who takes every customization request without mentioning this is billing you twice — once now, and again at every upgrade.
What customization costs
Branding is modest. Frameworks and custom fields are a day or two. Plugin development and core changes are project work. See our cost breakdown.
Always ask for the ongoing cost, not just the build cost.
Keeping customizations through upgrades
- Write down every customization, with what it does and why. The list is worth more than the code when the person who wrote it has gone.
- Keep CSS and JS in version control.
- Upgrade on a staging copy first — see our upgrade guide.
- Re-test every customization after each upgrade, from your written list.
- Reassess annually. Koha may have added the feature natively — retiring a customization is a real saving.
Want your catalog to look like your institution? We do OPAC branding, custom fields and frameworks — built at the lowest level that achieves the goal, so your next upgrade does not undo it.