Zoo and Aquarium Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope quietly grow into a ZIMS replacement?

Almost every zoo and aquarium software project starts with a sentence everyone agrees on: get the keepers off paper. By the fourth requirements workshop it has become something else. If we are capturing weights anyway, someone says, we should hold the medical record. Then the transaction record, then the studbook. The scope now describes a private rebuild of the Zoological Information Management System (ZIMS) that Species360 has developed with the profession over decades, and the version you build will be readable by exactly one institution, yours.

This failure is specific to this sector because your animal record has value precisely because other institutions can read it. A transfer, a cooperative breeding recommendation and a pathology query all depend on a shared vocabulary you do not control. Rebuilding it privately does not give you a better record, it removes you from the network that makes the record useful.

The same drift arrives a second way, through veterinary scope. A hospital module with anaesthesia records, controlled substance logging and diagnostic imaging references is close to a project of its own, and it usually appears in the requirements list as a single line.

The fix is unglamorous. Write down on day one what the system is not, name the person allowed to say no, and put the boundary in the statement of work rather than in a meeting. A first release of keeper daily records, diet delivery, enrichment and training logs and exhibit records runs $65,000 to $140,000 over 12 to 18 weeks in our delivery experience. Scope drift is how that becomes an 18 month programme that never reaches a keeper.

What goes wrong when decades of animal records are migrated?

Migration is where you discover your history cannot be expressed in the model somebody chose. The usual mistake is one row per animal with a quantity field on it. That works for a rhino and falls apart on almost everything else. A school of 200 anchovy is a group whose count changes without a documented event. A clutch of eggs becomes individuals only after hatching, and not all of them get there. Groups split when half a shoal moves exhibit and merge when new arrivals join. Once history is loaded into a flat model, a question about what a fish was fed six months ago returns the group that exists today rather than the group that animal was in at the time.

The second problem is the state of the source data. Species names have changed over the years. Weights sit in different units against different scales. An animal has a house name, a transponder number and an accession number, and different teams reach for different ones. The training record is in a binder in the mammal building and was never digital at all.

Two fixes. Model identity as a chain of events, accession, identifier assignment, split, merge, transfer and death, and attach every daily record to the identity as it stood on that date. Then migrate a bounded window of operational history, usually two to three years, rather than everything. Older material belongs in a searchable archive with scanned documents attached to the right animal. Budget the reconciliation as staff labour, because it is your registrar and head keepers who resolve identifier conflicts, not the developer.

Why do the integrations that matter here break after launch?

Two integrations carry the weight in this sector, and both fail for the same reason: nobody owns them after go live.

The first is the life support and water quality feed. Most aquariums read this from an existing supervisory control and data acquisition (SCADA) or building automation platform rather than replacing it, which is correct. What breaks it is ordinary facilities work. A chiller is replaced and the point names change. A controls contractor swaps a panel over a weekend. The read only account expires under a password policy nobody mentioned. Historian retention is shortened to free up disk. The symptom is cruel, because a chart that stops updating looks exactly like a stable system, and a flat line can sit on a dashboard for two weeks before anyone notices that alkalinity has not moved since the fourteenth.

The second is ZIMS. Projects get into trouble by promising an ambitious two way synchronisation, then finding that reconciling conflicting edits across two systems of record is harder than the rest of the build. A bounded flow in one direction, with a human confirming what crosses, is duller and survives.

The fix for both is staleness monitoring rather than threshold alerting alone. Alert when a stream stops arriving, not only when a value crosses a line. Name someone in facilities who tells you before controls work happens. And agree data access with your building automation vendor in writing before you sign the software contract, because that conversation can take longer than the integration itself.

What happens when permits and regulatory records are left out of scope?

Regulatory tracking is the classic phase three item that never arrives. Depending on your collection you are handling acquisition and disposition records under the Animal Welfare Act, documentation under the Convention on International Trade in Endangered Species (CITES), Endangered Species Act permits, marine mammal inventory reporting and the accreditation standards of the Association of Zoos and Aquariums.

The failure is almost never a permit that does not exist. It is a permit sitting in a filing cabinet with nobody watching the renewal after the registrar who tracked it changed role. Or it is a transfer packet assembled by hand at 5am where one document is missed and a crate waits on a loading dock while two institutions exchange emails.

The fix is cheap to build and expensive to omit. Attach permits and regulatory documents to the animal or group they cover, with expiry dates that generate a task and an escalation path before they lapse. Assemble transfer packets against a checklist that varies by species and destination rather than from memory. Make annual inventory reconciliation a report rather than a fortnight of cross checking. None of this is technically hard, which is exactly why it belongs in the first release.

Should you build custom or configure what you already own?

Some readers should stop here and configure. If you are a small collection, a wildlife rescue with a modest permanent population, or a private breeder, ZIMS covers the institutional record and ZooEasy covers pedigree and small collection management properly. A custom build at that scale consumes the curator you cannot spare.

Even at institutional scale, do the audit first. Institutions regularly pay for Species360 modules they have never configured, and have keepers on paper next to a husbandry module that was licensed and never rolled out. A week of configuration and training against software you already fund is a better first move than a six figure commission.

Build the operational layer when several of these are true. You hold more than roughly 400 accessions, or enough group accessions that counting is awkward. You run life support systems and the water data lives in a different world from the animal data. Your keepers spend the last hour of shift transcribing. You run more than one site. Your veterinary team is chasing observations made days ago. Your registrar spends weeks assembling transfer packets. Keep ZIMS regardless of what you build, because the shared record is the part you cannot replicate alone.

How do hidden costs get into the quote?

Quotes here are usually honest about the software and silent about what has to be true for it to work. These land on your budget, not the developer's.

• Devices that survive the environment. Consumer tablets do not last long in salt spray, chill rooms or a hose down. Cases, chargers in every building and spares are a real line.
• Wireless coverage. Concrete holding walls and plant rooms are where signal dies, and fixing that is usually a facilities capital item nobody costed.
• Access to your own control system data. Some building automation vendors charge for a data licence or an integration gateway before anyone can read a sensor.
• Data cleanup labour. Reconciling identifiers, species names and historical weights is your staff time, in the middle of their normal jobs.
• Training and the dual running dip. Expect a few weeks where keepers do both, and staff that slower period deliberately.
• Taxa variety. A collection spanning mammals, birds, herptiles, fish and invertebrates needs five different record shapes, and is often priced as though it needs one.
• Hosting, backups and support after launch. An animal records system is not a project that ends.

Ask for the exclusions list in writing. A quote with no exclusions is not cheaper, it is incomplete, and the gap returns as change requests once you have no room left to negotiate.

What separates a build that works from one that fails here?

The builds that work share a few habits, none of them about technology choice.

The developer spent a shift with keepers before writing anything. Not a workshop, a shift. There is no substitute for watching someone try to record a feed with wet gloves in bright sun with forty seconds before the next task, and every screen designed without that experience is designed for an office.

They put one building or one life support system into real use before building the rest. Six weeks of a single mammal house on the new records tells you more than any design review, and it is small enough that changing your mind is still cheap.

There is a keeper champion with genuine authority to reject a screen. If only curators and IT can veto a design, you get a system that reports well and captures badly.

Offline capture was designed in from the start rather than retrofitted, because sync is an architectural decision and not a feature you add in month nine. Alerting works on rate of change as well as thresholds, since the slow drift over nine days is what costs you a display.

And you own the repository, the hosting accounts and the unrestricted right to hire someone else, written into the contract before kickoff. At Digital Heroes the client owns the code from the first commit. One last test: ask a prospective developer to model a group accession that splits, on a whiteboard, in front of you. If they draw one animal row with a quantity field, they have told you what you needed to know.