MARC21 or UNIMARC: the choice you cannot undo

Choose MARC21 unless your national library and your record suppliers use UNIMARC. MARC21 is what the Library of Congress and most Z39.50 targets publish, so copy cataloguing works out of the box. The flavour is set when the instance is created, and changing it afterwards means rebuilding the frameworks and re-importing every record — so treat it as permanent.

Both encode the same bibliographic ideas; they disagree about which numbered field holds what. MARC21 came out of the North American tradition and is the de facto international standard; UNIMARC came out of IFLA as an exchange format and remains standard in parts of Europe, and in national systems built around it.

Note the last row: even Koha's own holdings field differs. Every import template, MARC modification rule, report that reads a MARC field, and export mapping is written against one flavour and is wrong under the other.

The question is not which standard is better designed. It is which one the records you will acquire are written in.

• Choose MARC21 if you will download records from the Library of Congress, OCLC or most university catalogues; if your suppliers send MARC21; or if you have no strong reason either way.
• Choose UNIMARC if your national library publishes UNIMARC and you will copy-catalogue from it, or if you are migrating from a system whose records are already UNIMARC.
• Migrating from another ILS? The answer is whatever your existing records are. Export a sample and look at it before deciding — that is a five-minute check that settles the question.

The practical consequence of choosing UNIMARC without a supplier who publishes it is that copy cataloguing stops being useful: every downloaded record needs conversion, and every conversion loses something. That is the trade, and it is worth being explicit about it rather than discovering it at the first import.

Pass it to koha-create. Note the spelling — the flag has no u, unlike the system preference of the same name. This is the single most-copied error in Koha install guides, and getopt rejects it outright:

$ sudo koha-create --create-db --marcflavor marc21 library

Valid values are marc21 (the default), unimarc and normarc. Set the Zebra indexing format to match in /etc/koha/koha-sites.conf before you create the instance, so search and storage agree:

# marc21 or unimarc — must match the flavour you create instances withZEBRA_MARC_FORMAT="marc21"

$ sudo koha-mysql library -e \    "SELECT value FROM systempreferences WHERE variable = 'marcflavour';" MARC21

And confirm the Zebra side matches:

$ grep -i marc /etc/koha/sites/library/koha-conf.xml | head

The system preference is also visible in the staff interface under Administration → System preferences → Cataloging → marcflavour. It is displayed there because reports and plugins read it — not because changing it converts anything.

Editing the preference on a catalogue with records in it does not convert them. It tells Koha to interpret existing records as a format they are not in, which is worse than leaving it wrong: displays go blank, indexes stop matching, and the damage looks like unrelated bugs.

The real procedure is a migration: export every record, convert them with a MARC conversion tool, create a fresh instance in the target flavour, re-import, rebuild the frameworks, redo every MARC modification rule and import template, and re-index. It is a project, and it is why the choice is worth ten minutes on day one.

If that is where you are, it is the same shape as any other catalogue migration — see Koha data migration.