Museum Management Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a ticketing project turn into a collections replacement?

The scope starts sensibly: unify ticketing, timed entry and membership so the front desk stops guessing. Then someone points out that the exhibition record should reference objects, which is true. Then the registrar mentions that if objects are in the system anyway, cataloguing might as well move too. Then a curator asks about provenance fields. Within a month the project is a collections management replacement with a ticketing module attached, and the timeline has gone from 12 to 16 weeks to most of a year.

This happens in museums more than in other sectors because the two halves of the institution rarely get a shared project, so when one finally arrives everyone brings their wish list to it. The registrar has waited eight years for someone to care about the loans tracker.

The fix is a hard rule for phase one: your existing collections system stays the system of record for cataloguing, objects sync into the new platform read only, and the exhibition entity references them by identifier. Curators and registrars have workflows in TMS, The Museum System, that took years to settle, and replacing those in phase one is the most reliable way to kill the project. Cataloguing migration is a later phase if the team actually wants it, and quite often they do not.

What goes wrong migrating a legacy PastPerfect or TMS database?

The extraction is fast. The decisions are slow, and they are not decisions a developer can make. A database with thirty years of cataloguing behind it contains free text provenance, inconsistent date formats, dimensions recorded four different ways, and image files linked by filesystem path rather than by a stable reference, which means half of them point at a server that was decommissioned.

Two failure modes recur. The first is a project that migrates everything faithfully, including the inconsistency, so the new system is exactly as unusable as the old one and the registrar loses faith in it. The second is a project that cleans aggressively without the registrar in the room, and quietly discards distinctions that mattered, which is a curatorial loss you cannot reverse.

The fix is to plan migration as a parallel workstream of six to ten weeks with named registrar time booked into it, and to budget it honestly. For a collection in the tens of thousands of objects that is typically $20,000 to $50,000, and it will produce a list of records that cannot be reconciled. That list is not a failure, it is the first accurate picture anyone has had of the catalogue's condition.

Why do the payment, donor and collections integrations break after launch?

Three integrations carry most of the post launch pain. Card present payments are first, because behaviour differs by terminal provider on tips, refunds and partial voids, and the flows that look identical in a demo diverge the first time a visitor asks to split a family ticket across two cards at a busy door.

The donor system is second. If Blackbaud Raiser's Edge NXT holds constituents and the new platform holds members, you now have two records for the same human being and no agreed authority over which one is right. Development edits one, the front desk edits the other, and within six months the renewal file is wrong in ways nobody can trace.

The third is the collections sync, which usually breaks quietly. A curator renumbers a group of objects, the identifiers the exhibition record depends on change underneath it, and the exhibition page shows an object that no longer exists at that reference.

The fixes are ownership rules rather than code. Name one authority per field, in writing, before build. Make the sync fail loudly rather than skipping records it cannot match. And run the payment flows through your actual terminals at an actual door during a busy weekend before cutover, not in a demo environment.

What happens when entitlements and gallery capacity are not modelled properly?

Entitlements enforced by memory produce two costs, and the second is worse than the first. The obvious one is inconsistency: a member gets one answer at your downtown site and a different answer at the campus site, complains, and the development director issues a goodwill upgrade to settle it. The deeper one is that the goodwill upgrade never gets recorded, so the membership programme's real economics are unknowable. Nobody can say whether a Family membership is profitable at its current price, because actual guest pass usage and door overrides are invisible.

Capacity has the same shape. If a gallery is not modelled as a resource that multiple booking types consume, group sales and school programmes will keep loading slots the public ticketing system believes are empty.

The fix on entitlements is a rules engine evaluated at scan time against the specific event, returning admitted party size, remaining guest passes, discount rate and conditions, so the desk sees an answer instead of a policy. Keep the override, because museums are hospitality businesses, but capture who, why and what it was worth. On capacity, make the space the constrained resource with one calendar that every booking type draws from, with configurable holds and release rules for member previews and unconfirmed school blocks.

Should you build custom or configure Altru, ACME or Tessitura?

Plenty of museums reading this should not build, and the line is reasonably clear. A single site under roughly 100,000 annual visitors, a membership base under 5,000 and no venue rental business will be held perfectly well by ACME or Altru, and the money is better spent on a person than on software. If your collection is a few thousand objects and PastPerfect is not hurting anybody, leave it alone. For most museums in the United States, buying is simply the right call and we say so on calls that end without a project.

Configure before you commission. Most institutions have not exhausted the tier, hold and reporting configuration their current platform already offers, because nobody had time to sit with it for a fortnight. Do that first, and you will at least know precisely which rules the product cannot express, which is the strongest specification you can bring to a build.

The build case is a stack of signals rather than any single one: two or more sites with no honest occupancy or revenue number without a human assembling it, membership rules that live in staff heads, a registrar maintaining a load bearing shadow spreadsheet, and platform plus per ticket fees past roughly $40,000 a year. Add the decisive one, which is making pricing and staffing calls on numbers you privately do not trust.

How do hidden costs get into the quote?

Four things reliably arrive after the estimate. Accessibility is the first. If you receive public funds you should be building to WCAG 2.1 AA properly, which in our estimating adds roughly 10% to 15% to front end work when designed in from the start and about three times that when retrofitted after a review flags it. Put it in scope on day one.

Entry points are the second. Every door is a device, a network assumption and an offline mode, so a three site institution with six entrances is a materially different build from one with two. Scanners must keep working when the building wifi drops, which it will, on your busiest day.

Payment scope is the third. Card present at the door plus online plus the shop, handled carelessly, drags your whole platform into PCI audit scope. Tokenised flows and a point to point encryption terminal path keep it contained, and that decision is cheap at design time and expensive later. Fourth is collections migration, covered above, which is almost always underestimated because the extraction looks easy.

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

Phasing, first. The builds that succeed unify ticketing, membership and capacity, integrate to everything else, and leave cataloguing where it is. The ones that fail try to replace the whole stack at once and lose the registrar and the curators somewhere in month five, after which nobody defends the project internally.

Second, insist the developer models an accession record and a loan on a whiteboard unprompted. If they cannot distinguish an accession number from an object identifier, or do not ask whether you catalogue at object or lot level, you are paying for their education. Apply the same test to membership: ask how they would model a household with two named adults and a floating guest pass allowance, and listen for whether they reach for a rules engine or add a column.

Third, make loans a workflow with states, owners and due dates rather than a folder of documents, because the failure mode there is a lapsed insurance rider nobody notices until an auditor asks. Fourth, settle ownership before the first invoice. You should hold the repository, the cloud account and the data from day one rather than on completion. Museums keep things for centuries, and the software should at minimum outlive the vendor relationship that produced it.