Zoo and Aquarium Records Software: Keeping One Animal's History Intact Across Institutions

Why the record has to outlive the institution that holds it

A sea otter is going to another aquarium. The crate leaves at 5am. Two weeks earlier your registrar started assembling what travels with her: the full medical history including two dental procedures and a chronic lens issue, her diet including the exact clam and squid ratio she will actually eat, her training record so the receiving staff know which behaviours she offers on cue, her lineage, her stranding and rehabilitation origin, the permit documentation covering her status, and the last twelve months of body weights.

Some of that is in ZIMS. Some is in a shared drive folder of Word documents. The training record is in a binder in the mammal building. The diet detail lives in the head keeper's head, and the note about her refusing squid after 2pm is not written down anywhere at all. Your registrar spends most of two weeks assembling a packet that should have been a single export, and the receiving institution will spend its first month rediscovering things you already knew.

ZIMS by Species360 is the backbone of this profession and it earns that position. It is the shared language between institutions, it holds the taxonomic and medical record, and you are not replacing it. The gap is not in the species record. The gap is in everything that happens between 6am and 4pm inside your own gates: the keeper who noted reduced appetite on a paper sheet, the water quality reading that drifted for three days before anyone plotted it, the browse delivery that did not arrive, the enrichment that was scheduled and not delivered, the treatment that was given but recorded at the end of shift from memory.

Across zoo and aquarium projects Digital Heroes has delivered, the recurring pattern is 45 to 90 minutes per keeper per day spent transcribing paper records into a system at the end of shift, and a two to five day lag between an observation being made and being visible to a curator or veterinarian. In an animal care operation, a five day lag on an appetite change is not an administrative issue. It is a clinical one.

Problem 1: identity is a chain, not a row

Individual mammals are the easy case. Everything else in a collection breaks the simple model. A school of 200 anchovy is a group accession with an approximate count that changes without a documented event. An ant colony is one accession that is also thousands of animals. A clutch of eggs becomes individuals only after hatching, and some do not survive to be individuals at all. Groups split when you move half a shoal to another exhibit and merge when a new arrival joins an existing group. Every one of those events has to be recorded in a way that still reconciles to an inventory count at year end.

ZIMS models this properly at the species and transaction level, which is exactly why you keep it. ZooEasy models pedigrees well for smaller collections and private breeders and is not built for a public institution running life support systems and a veterinary hospital. What neither does is give your keepers a fast way to log against a group in the moment, on a tablet, standing next to the exhibit with wet hands.

What a custom build does: treat identity as a chain of events. Accession, identifier assignment, group split, group merge, transfer, death, with every daily record attached to the identity as it existed on that date. Historical queries then return the truth as it was, not as it is now. This matters more than it sounds. When a pathologist asks what a fish was fed six months ago, the answer must reflect the group that fish was in at the time, not the group that exists today.

Problem 2: an aquarium is a water treatment plant with animals in it

This is the part that separates aquariums from zoos entirely, and it is the part off the shelf animal records software does not touch. Your exhibits depend on life support: sand filters, protein skimmers, ozone contact, ultraviolet sterilisation, chillers, heat exchangers, pumps with duty and standby pairs. Water chemistry has to stay inside ranges for ammonia, nitrite, nitrate, pH, salinity, alkalinity, dissolved oxygen, oxidation reduction potential and temperature, and the correct range differs by system because a cold water kelp exhibit and a coral system are different animals in every sense.

Most aquariums run this on a mix of a building automation or SCADA system that alarms on thresholds, a lab notebook of hand tested chemistry, and a spreadsheet per system. The alarm tells you something crossed a line right now. It does not tell you that ORP has trended down for nine days while the ozone generator degraded, which is the pattern that actually costs you a display.

What a custom build does: pull the sensor stream from the existing control system rather than replacing it, and hold it alongside the hand tested chemistry and the animal observations in one timeline. Then a curator looking at reduced feeding response in a system can see, on the same screen, the alkalinity drift and the backwash log and the fact that a chiller ran hot on Sunday. Trend alerts on rate of change, not just threshold breach, are the specific feature worth paying for. Building this properly also means designing for offline capture, because plant rooms are where wireless coverage goes to die.

Problem 3: diets and the commissary are a supply chain problem

The nutrition team writes a diet. The commissary prepares it. The keeper delivers it, or delivers part of it, or substitutes because the herring delivery was short. What gets recorded is usually the diet as written, not the diet as eaten, and the difference is where clinical signal hides.

What a custom build does: separate prescribed diet from prepared diet from offered diet from consumed estimate, and let keepers record the difference in two taps. Track fish and produce by lot so a supplier quality issue can be traced to every animal that received it, the same way any food operation would. Manage browse species availability against an approved and excluded list per taxon, because the risk of the wrong cut branch reaching the wrong enclosure is real and entirely preventable with software.

Problem 4: permits, protected species and the paperwork that follows the animal

Depending on your collection you may be dealing with USDA acquisition and disposition records under the Animal Welfare Act, CITES documentation for internationally protected species, Endangered Species Act permits, marine mammal inventory reporting, and accreditation standards from the Association of Zoos and Aquariums. Each has its own document, its own renewal cycle and its own inspection.

What a custom build does: attach permits and regulatory documents to the animal or group they cover, with expiry dates that generate tasks and an escalation path. Transfers assemble a document packet automatically against a checklist that varies by destination and species. Inventory reconciliation, the annual exercise of proving that what you say you hold is what you hold, becomes a report rather than a fortnight.

Problem 5: keepers record with wet hands, cold hands and one hand

Every animal records project succeeds or fails on this. If entry takes longer than paper, keepers use paper, and you have bought a transcription system rather than a records system. The realistic constraints are wet or gloved hands, bright sun on a screen, gloves in a chill room, no signal behind a concrete holding wall, and a keeper with 40 seconds between tasks.

What a custom build does: design for the glove and the glare. Large targets, offline first with sync when coverage returns, defaults from yesterday's record so a normal day is confirmed rather than typed, voice note capture for anything unusual, and photo capture attached to the animal without leaving the screen. Voice transcription of keeper notes is one of two places AI genuinely helps here, turning a spoken observation into structured text with the animal, behaviour and time already attached. The second is image assisted individual identification for species with natural markings, which is real and works for dorsal fins and spot patterns, and is not worth building until your daily record capture is solid.

What this costs and how long it takes

A first release covering keeper daily records, diet delivery, enrichment and training logs, exhibit records and a tablet interface built for the conditions runs $65,000 to $140,000 and ships in 12 to 18 weeks in our delivery experience. A full platform adding life support telemetry integration, water quality trending, commissary and browse management, permit and regulatory document tracking, veterinary workflow with treatment scheduling, and reporting runs $160,000 to $380,000 phased over 7 to 14 months.

What drives the price up: aquarium life support integration, because every SCADA or building automation system exposes data differently and some expose it badly. Veterinary scope, because a hospital module with anaesthesia records, controlled substance logging and diagnostic imaging references is close to a project of its own. Number of distinct taxa groups, since a collection covering mammals, birds, herptiles, fish and invertebrates needs five different record shapes. Multi site operations with animal transfers between your own facilities. And integration with ZIMS, which should be scoped carefully rather than assumed.

Build versus buy, and when buying is the right call

Buy and stop here 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 well. Custom software at that scale is a project that consumes the curator you cannot spare.

Keep ZIMS regardless. This is a point we make firmly with every institution we work with: your species and transaction record belongs in the shared system the profession uses, because the value of that record is partly that other institutions can read it. Building a private replacement isolates you from the network that makes animal transfers and cooperative breeding programmes work.

Build the operational layer when several of these are true. You hold more than roughly 400 accessions, or any number of group accessions that make counting awkward. You run life support systems and your water data lives in a separate world from your animal data. Your keepers spend the last hour of shift transcribing paper. You operate more than one site. Your veterinary team is chasing observations that were made days earlier. Or your registrar spends weeks assembling transfer packets that should take an afternoon.

How to choose a developer for zoo and aquarium software

Ask them to model a group accession that splits, and watch what happens. If they draw one animal record with a quantity field, they will build you something that cannot answer a question about a fish that moved exhibits in March. Group and individual identity handled in the same model is the technical core of this domain.

Ask specifically how they intend to interact with ZIMS, and be suspicious of confident answers given before they have looked. The right approach is usually a controlled and clearly bounded flow rather than an ambitious two way sync, and a developer who says so is telling you the truth.

Ask who owns the code and put it in the contract before kickoff. You should own the repository, the hosting accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. An institution whose animal records depend on a vendor's goodwill has created a risk that no accreditation inspector would sign off on if they understood it.