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

Why do archives projects end up rebuilding description?

The brief starts with an operational complaint: we cannot find boxes, or we cannot tell researchers what is restricted. Then somebody demonstrates ArchivesSpace and finds a screen they dislike, and by the third meeting the proposal includes a new description module. That is the biggest scope failure in this sector, and it is expensive because archival description is much harder than it looks.

Description under the sector's content standard runs from collection to series to subseries to file to item, and description at any level applies to everything beneath it. Encoded Archival Description exists because that structure is not optional. A general purpose records table with a parent identifier will not express it, and a team that discovers this in month four has spent your budget learning what ArchivesSpace and Access to Memory already implement properly.

The fix is a boundary agreed before scoping. Description, accessioning and the component tree stay in the description system, which remains the system of record. The custom work owns the operational layer that those products deliberately leave thin: restriction rules that can be evaluated, container and location control, reading room and digitization queues, and backlog triage. Everything reads from and writes back to the description system through its interfaces. In our delivery experience the archives projects that hold that line ship in a single funding cycle. The ones that cross it do not ship at all.

What goes wrong with legacy finding aids and hierarchical data?

Every established repository has finding aids in Word, in PDF, in HTML exported from a website built in the early 2000s, and in typescript in binders. Retyping them is a multi year clerical project that never gets funded, so those collections stay invisible, which is the same in practice as not holding them.

Migration of the descriptions you do have structured brings its own failures. Component trees move badly when the target model assumes every node has a title and a date, because plenty of real archival components have neither. Container links are the classic loss: a folder record migrates fine and arrives with no idea which box it is in, because the legacy system stored that association in a place the export did not include. Boundwith and multi container relationships break. None of this produces an error, and the collection level records look correct, which is why it passes review.

The fix on legacy conversion is machine assisted parsing with archivist review, which is one of the clearer places a language model does useful work: identify hierarchy levels, extents, date ranges and container references, propose structured components with confidence scores, and route anything ambiguous to a human. Expect supervision rather than automation, because inconsistent typescript defeats naive parsing. On migration, test container associations explicitly and reconcile per collection rather than in total, and never accept an export whose container linkage nobody has verified against the shelf.

Why do reading room, preservation and storage integrations break after launch?

An archive's integrations are unusually consequential because each one sits between a researcher and material. ArchivesSpace interfaces feeding description into your operational layer. A reading room platform such as Aeon handling requests. A digital preservation system such as Preservica holding objects. An offsite storage vendor with its own barcodes and retrieval process.

They fail in ways that surface at the desk rather than in a log. An ArchivesSpace upgrade changes an interface response and component identifiers stop resolving, so paging slips start printing with the wrong container reference. The offsite vendor changes its request file format and retrievals silently queue rather than dispatch, which the reference desk discovers when a researcher who travelled arrives to nothing. Digital surrogates lose their link to the archival component they represent, and the repository ends up with thousands of scans nobody can place in a finding aid, which wastes the entire digitization budget retrospectively.

The fix is to key everything to a stable component identifier that travels with the object into every other system, including into the preservation platform, and to verify that identifier on the way back rather than trusting it. Alert on absence: an offsite request with no acknowledgement within the vendor's stated lead time should raise a flag the same day. And build a reconciliation report between description and containers that a collections manager runs monthly, because a broken link discovered by a report is an afternoon and one discovered by a researcher is a reputation.

What happens when restrictions are not enforceable?

Restrictions in archives are not one flag. A collection may be open with three exceptions. A donor agreement may close a series for a number of years from the date of its latest document, which requires computing a date rather than storing one. Student records carry statutory obligations. Medical material in an institutional collection carries its own rules. Files concerning living individuals may be closed for a period after death, which depends on a fact the archive does not hold. And restrictions inherit downward through the component tree unless locally overridden.

Systems that offer a restriction note give you text a human reads, which means the decision depends on whether that human reads it, understands the deed it references and knows the exceptions. Every repository has at least one archivist who is the actual access control system, and that person will retire.

The fix is a restriction record attachable at any level, carrying a type, a legal or donor basis, a fixed or computed end date, a review requirement, and downward inheritance with local override. The reference archivist then opens a folder record and sees a determination: open, closed until a computed year under a named clause, or requires curator review. This is the single highest value thing a custom layer does in an archive, because it converts institutional memory into a rule the next hire inherits, and because it protects the repository at the exact moment protection matters. Pair it with the same check on paging slips, so a slip is never issued for material that cannot be served.

Should you build custom or configure what you already own?

Use ArchivesSpace or Access to Memory for description and do not consider replacing them. Both are open source, both implement the standards properly, and rebuilding archival description is a poor use of anyone's money. A single repository with under roughly 3,000 linear feet and no reading room should run one of them as it comes and spend the budget on processing staff, which will do more for access than any software.

Preservica is the right answer for digital preservation if you hold digital material with long term obligations, and it is not a substitute for a collections management system. Axiell Collections suits institutions whose holdings are mostly objects rather than hierarchical archival material. Aeon is the established reading room product, and integrating with it is usually smarter than rebuilding request handling.

Build the operational layer above when restriction decisions currently depend on a specific archivist's memory, when containers are tracked in a spreadsheet and boxes go missing, when you run offsite storage and cannot tell a researcher when material will arrive, when your backlog needs to be evidenced to funders, or when legacy finding aids keep whole collections invisible. The tipping point is not holdings size. It is whether access decisions and physical control have moved out of institutional memory into something a new colleague can use on their second week.

How do hidden costs get into the quote?

Legacy finding aid volume is the first, and it should be priced by document count rather than estimated. A repository that says it has some legacy finding aids and then produces four hundred documents in six formats has changed the project. Count them and sample them before anyone quotes.

Offsite storage vendor integration is the second. Each vendor has its own interface, its own file format and its own lead time model, and the elapsed cost is waiting for a vendor with no commercial incentive to prioritise you.

Multi repository institutions are the third. When a university archive, a manuscripts library and a records management programme share infrastructure but not policy, every rule needs three answers and a governance meeting to agree them. That coordination is real project cost even in weeks when no code is written.

Fourth is public access. Exposing material publicly raises questions about restriction correctness that internal use lets you defer, and it usually triggers a review of legacy restriction data that nobody has looked at in years. Fifth is digital preservation integration, which brings its own metadata expectations and its own vocabulary, and should be scoped as a separate piece of work rather than folded into a general integration line.

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

The working build starts from the right data model. A developer who has worked with archives whiteboards accession, resource, component tree, container, location, restriction and event, and they ask whether a container can hold components from more than one series, because the answer is yes and it complicates everything downstream. One who proposes a flat records table with a parent identifier is about to learn archival hierarchy on your budget.

The second difference is that the system copes with material described only at accession level. Most of your holdings will be in that state for years, and a system that assumes full description will fight your staff every day. Unprocessed material has to be locatable, requestable and restrictable without a component tree beneath it.

The third is that backlog triage is treated as evidence rather than a to do list. Record each accession with extent, condition, restriction risk, known demand and format complexity, hold the intended processing level so nobody quietly does item level work on material that warranted a box list, and report the backlog in linear feet. That number wins grant funding far more reliably than a narrative does.

The fourth is ownership and portability settled in writing before kickoff: the repository owns the code and the cloud accounts, and export in Encoded Archival Description is a contractual requirement so descriptions stay portable regardless of what happens to any vendor. At Digital Heroes the repository owns the code from the first commit. For an institution whose entire purpose is long term custody, depending on software you cannot take with you is a contradiction worth refusing.