How to Choose Plant Collection Management Software

Choosing a collection management system is one of the longest-lasting decisions a botanical garden makes. Plant records outlive staff, software versions and sometimes the institutions that created them, so the system you pick today shapes what your successors can know about the collection decades from now. Yet many gardens approach the decision with a generic software checklist that misses what makes botanical data different.

Here is a framework built around the questions that actually separate systems in practice.

Start with the data model, not the interface

Screens change; data models rarely do. The core question is whether the system models the things a living collection actually consists of:

• Taxa, accessions and plants as separate entities. An accession is a group of plants of one taxon from one source, received at one time. A system that conflates accessions with individual plants, or with taxon names, cannot represent the reality of a garden where one accession grows in four beds and one bed holds a dozen accessions.
• Name history. Taxonomy moves. When a genus is revised, you need the determination history preserved: what the plant was called, by whom, when and on what authority. A system that simply overwrites the name discards scientific evidence.
• Provenance and lineage. Wild-collected, garden origin, or of unknown provenance? From which expedition, collector and locality? For conservation value, the chain from wild source through propagation events matters enormously.

Ask each vendor to walk through how a re-identification, a repropagation and a partial deaccession are recorded. The answers reveal more than any feature list.

Insist on open standards

Your data should never be hostage to one product. Look for support for the international conventions the botanical community already uses:

• ITF2 (International Transfer Format) for exchanging accession data between gardens and with BGCI.
• Darwin Core for publishing occurrence data to aggregators such as GBIF.
• Structured, documented export of everything: not just a filtered report, but the full relational data.

If a vendor cannot show you a complete export, assume migration away from their product will be painful, and weigh that in the total cost.

Mapping is part of the record

For a living collection, where a plant grows is core curatorial data, not an add-on. Evaluate whether mapping is integrated with the plant record, so moving a plant updates one system rather than two, and whether staff can capture coordinates in the field. Check what base maps are supported, whether garden infrastructure (beds, paths, irrigation) can be layered, and how easily a printed or public map is produced from the same data.

Everyday workflows decide adoption

A system only pays off if the whole team uses it. Sit your actual users (curators, records officers, propagators, volunteers) in front of a trial and time the routine tasks:

• Recording a new accession from a seed list
• A nursery-to-garden move with label printing
• An inventory round of one garden area
• Answering a typical enquiry (“which Sorbus of wild origin do we hold?”)

Field work matters here: can inventory be done on a tablet or phone, and does it degrade gracefully where Wi-Fi does not reach?

Reporting, labels and the audiences beyond the records office

Collection data serves many masters: annual statistics for management, plant lists for researchers, interpretive labels for visitors, reports for funders and accreditation schemes. Check that reporting is flexible enough to answer questions you have not thought of yet, and that label production, whether engraved, thermal or paper, is built in rather than bolted on. If public engagement is a goal, ask how collection highlights can be published to the web directly from the database, without maintaining a parallel dataset.

Sustainability of the vendor and the community

You are choosing a partner, not just a product. Consider:

• Track record. How long has the system existed, and how many comparable institutions run it?
• Community. Are there user meetings, a forum, other gardens you can ask for candid references?
• Development cadence. When was the last release, and is there a public record of what changed?
• Support. Who answers when a records officer is stuck mid-inventory, and in which time zones?

Total cost, honestly calculated

Licence fees are the visible part. Add implementation, data migration from your current records, training, hardware for field work and label printing, and the staff time to clean data during migration. A cheaper licence with a weak migration path often costs more within two years. Conversely, migration effort is an investment: it is usually the moment a garden finally standardises decades of accumulated conventions.

A short evaluation checklist

1. Model a re-identification, a repropagation and a deaccession in a trial database.
2. Export everything and inspect the files.
3. Time four routine workflows with real staff.
4. Produce one label, one map and one report from your own sample data.
5. Talk to two reference gardens of similar size and mission.

A system that performs well on those five exercises will almost certainly serve you well in daily use, because they are daily use, compressed into an afternoon.