Preservica Alternatives for Digital Preservation Programmes

Why archives teams start looking for a Preservica alternative

The trigger is usually the renewal conversation meeting the storage curve. A digitisation programme lands, or an audiovisual collection arrives, or a records transfer from a department turns out to be twenty years of email and shared drives. Volume grows in a way the original business case never modelled, the subscription grows with it, and somebody senior asks whether the same outcome could be had for less. That is a fair question and it deserves a better answer than a feature grid.

The second trigger is the access side rather than the preservation side. Preservation is quiet, invisible work that nobody thanks you for. Access is what your director, your funder and your public actually see. When a curator wants an exhibition style presentation of a collection, or a researcher wants faceted search across archives, library and museum holdings, or a records team wants a self service portal for departmental requests, the generic viewer that comes with a preservation platform starts to feel like the constraint on the whole programme. Teams then mistake an access problem for a preservation problem and start shopping for the wrong thing.

What Preservica genuinely does well

Active digital preservation is not storage with a nicer label. It is identifying what a file actually is regardless of what the extension claims, characterising it, flagging formats that are drifting towards obsolescence, migrating them under a documented policy, checking fixity on a schedule, and keeping a record of every one of those actions that will still make sense to an auditor in twenty years. Doing that properly, at volume, and keeping the tooling current as format registries and standards evolve, is genuinely hard specialist engineering.

The second thing it does well is give you a supported product with a roadmap rather than a project. Plenty of institutions have a preservation repository that works beautifully and depends entirely on one grant funded developer who has now moved on. A commercial platform with structured packaging, retention handling and chain of custody documentation is a defensible answer when a regulator, an auditor or a public inquiry asks how you know a record has not been altered. If your obligation is legal rather than aspirational, that defensibility is the product you are buying, and it is worth paying for.

Where it actually strains

Economics scale with volume, and volume in this field only goes one way. Audiovisual material, high resolution digitisation and born digital records transfers all consume capacity far faster than paper era planning assumed. That is not a criticism of any vendor, it is the shape of the category, but it means your five year cost curve depends almost entirely on ingest decisions made by people who are not looking at the invoice. Appraisal discipline, deciding what genuinely warrants permanent preservation, becomes a budget control and most programmes apply it too late.

Configuration ceilings are the second strain. Description models differ sharply between archival, library, museum and records management traditions, and a platform has to pick a shape. Institutions holding all four kinds of material spend real effort mapping their descriptive practice onto the model the software offers, and the mapping is rarely lossless. Reporting rigidity follows: the questions your funder or your board asks tend to cut across collections, formats, rights status and processing state at once, and cross cutting questions usually mean an export and an analyst.

Integration burden is third and it is bigger than people expect. A working programme touches a collections management system, a digital asset manager, the productivity suite where records are born, the finance and records retention schedule, and the public access layer. Each connection needs an owner. Finally, treat portability as a commercial question, not a technical one. Standards aligned export is normal in this category, but before you sign, establish what package structure you get back, what descriptive and preservation metadata comes with it, how long a full extraction takes at your volume, and what the egress costs. The answer to those four questions determines how free you actually are.

Your real options

Staying is often correct. If your obligation is regulatory, your auditors are satisfied, and your complaint is really about access and presentation, then replacing the preservation core solves nothing and puts your defensibility at risk during the transition. Build the access layer instead and leave the vault alone.

Switching vendors is the second path. Arkivum and Libnova come up in the same conversations, and Ex Libris Rosetta appears where the institution is already deep in that stack. Weigh these on the same four portability questions above, on whether their description model matches your practice better than what you have, and on whether their support model suits a small team. Switching preservation systems is not like switching a CRM (Customer Relationship Management), because the thing you are moving is the evidence that your records have been intact all along.

The open source route is genuinely viable here in a way it is not in every category. Archivematica offers a standards driven preservation pipeline with commercial support available, AtoM covers archival description and access, and Fedora with Samvera or DSpace underpins repository work at many universities. This route trades subscription for staff and integration effort. It works well for institutions with developers and a systems archivist, and it fails quietly for institutions that adopt it to save money and never staff it.

Unbundling is the fourth path and the one most teams should consider first. Keep the preservation core, and build the ingest workflow, the description and appraisal tooling, and the public access experience around it. Preservation platforms are built to be integrated with, and the parts you find frustrating are almost always the parts closest to your users rather than the parts closest to the bits.

When a custom build pays back

The strongest case is access. A public facing portal that presents your collections the way your curators think about them, with your own navigation, your own contextual essays, decent full text search, an image viewer that behaves properly on a phone, and rights handling that reflects your actual policy rather than a generic toggle. This is the work that turns a preservation programme into something the institution values, and it is a well understood web application rather than a research project.

The second case is ingest. Records rarely arrive tidy. A pipeline that pulls from the systems where records are actually created, applies your appraisal rules, normalises descriptive metadata, routes anything ambiguous to a human, and hands clean packages to the preservation system, removes an enormous amount of repetitive work. The third case is workflow: appraisal decisions, rights review, takedown requests, access approvals and reporting to funders and regulators. These are your policies, and encoding your own policies is exactly what custom software is for.

It does not pay back when there is no digital archivist to own preservation policy, because software cannot decide what your institution should keep. It does not pay back when the bottleneck is a description backlog, which is a staffing problem wearing a technology costume. And it never pays back to rebuild the preservation core itself, because you would be recreating format registries, migration pathways and audit machinery that already exist and are maintained by people who do only that.

Migration reality

Moving preserved content is different from moving business data because the point of the exercise is proving nothing changed. Export content with checksums, verify fixity independently on both sides, and keep the full preservation history including every migration action, every fixity check and every access event. If you lose the audit trail you have not migrated an archive, you have copied some files, and the difference is exactly what you were paying to maintain.

Plan the physics. Multi terabyte transfers take real time and real bandwidth, egress may carry cost, and a sample migration of one representative collection should always run before the full move. Keep the source system readable and licensed until reconciliation is complete rather than cancelling the day the copy finishes. Expect the descriptive metadata mapping to be the slowest part of the project, because that is where two different models of what a record is have to be reconciled by hand.

Cost bands and the honest recommendation

Preservation platforms are quoted on volume, deployment model and support level, so treat published tiers as a starting point and model your five year storage curve before you compare anything. On the custom side, from what Digital Heroes delivers: a focused build such as a public access portal, an ingest pipeline or an appraisal and rights workflow runs roughly $30k to $80k over 8 to 14 weeks. A broader platform covering access, ingest, workflow and reporting runs roughly $100k to $220k. Those are one time build costs plus hosting, and they sit alongside your preservation subscription rather than replacing it.

Stay on your preservation platform if your obligation is regulatory and your auditors are satisfied. Switch vendors only if the description model genuinely fits your practice better or the volume economics have become indefensible after you have tightened appraisal. Go open source if you have developers and a systems archivist and can commit for the long term. Build the layer, not the vault, if what your institution actually wants is for people to find and use the collections you have already spent years preserving.