A guide to choosing a digital strategy for your catalogue raisonné

A practical guide for those creating a digital catalogue raisonné and deciding between an off-the-shelf platform, assembling several pieces of software, or engineering a custom solution from the ground up.

Claude Monet, Winter Landscape with Evening Sky, ca. 1870.1880. Pastel chalk on woven paper, 23 x 32.6 cm. Städel Museum, Frankfurt am Main; in the public domain.

Three approaches to catalogue raisonné technology

A digital catalogue raisonné is one of the most complex publishing projects an institution can undertake. In these living scholarly projects, records accumulate, information changes, high-resolution images must be served securely, and the publication must remain accessible and credible for future generations. Getting the technology right matters not only for preparation and launch but also for the long-term sustainability of the scholarship.

Most technical setups fall into three general categories, distinguished by how much software you buy, configure, and build:

• Off-the-shelf platform: You subscribe to a platform built specifically for developing and publishing catalogues raisonnés and use it largely without modification.

• Assembled system: You combine existing tools—a database, a content management system, plugins, and other services—into a system that fits your requirements.

• Custom solution: You commission software written specifically for your catalogue and tailored to your needs.

Each path has advantages and costs. The right choice depends not only on your budget and the work you are documenting but also on your organization’s technical and project-management capacity.

The iceberg: decisions you might not anticipate

Before examining the three approaches, one observation applies to all of them. Planning a digital catalogue raisonné can feel a little like examining an iceberg. Above the waterline are the visible questions: How much will it cost? What features will it have? What will the site look like?

Below the waterline are hundreds of smaller decisions that do not announce themselves at the start of a project. How should a provenance line be rendered when ownership is uncertain between two dates? Who may change an attribution, and what record should be kept of the change? Which fields should appear on a mobile screen? How will digital assets be stored, processed, and delivered at the appropriate resolution and in the correct context? Who will be responsible for software maintenance ten years from now?

Do not underestimate the scholarly, technological, and administrative decisions involved in creating, publishing, and maintaining a digital catalogue raisonné.

In every approach, these decisions must first be identified and then resolved, adding to either your workload or someone else’s. Where that responsibility falls depends on the technical strategy. An off-the-shelf platform has already addressed many of these questions, informed by the catalogues running on it. An assembled system distributes the decisions among your team, your technical partner, and the defaults built into each component. A custom solution places almost all of them in your hands.

This distinction is fundamental. With assembled and custom systems, your organization does not simply acquire software; it assumes responsibility for managing software. That means overseeing vendors or developers, setting priorities, approving changes, testing releases, managing risks, and ensuring that the system continues to serve the scholarship over time.

Off-the-shelf catalogue raisonné platforms

Off-the-shelf catalogue raisonné platforms are built specifically for developing and publishing digital catalogues raisonnés. You subscribe to a single service that handles infrastructure, image delivery, and the browsing interface, all designed around catalogue scholarship from the start. Tools in this category include Artifact, Navigating.art, Artlogic, InventoZen, and Artifex Press.

What this approach offers

• Little or no dedicated in-house technical staffing is typically required. Each party concentrates on its area of expertise: scholars conduct scholarship, while the vendor develops and maintains the software.

• Upfront costs are generally lower and ongoing expenses more predictable than they are for assembled or custom approaches.

• Many of the submerged parts of the iceberg—including the rendering of provenance, governance rules, and publication citations—have already been researched and integrated.

• The data model is designed for catalogue raisonné scholarship, so you are not contorting general-purpose tools to fit specialized requirements.

• Other catalogues use the same platform. Improvements can therefore benefit a broader community rather than only the institution that commissioned them.

• Infrastructure, security, and software updates are handled by the vendor.

• Digital asset management may be included: the platform can store and version images, generate derivatives, and enforce rights and access rules.

A platform still creates dependency on a vendor. The difference is that the vendor maintains a product for a community of customers rather than a one-off system for a single organization. That community can collectively influence the vendor’s roadmap, while the cost of general improvements, security work, and compatibility updates is distributed across multiple customers.

What this approach costs

• Some control over design and presentation is ceded.

• Unusual data structures may require workarounds.

• Features are prioritized according to the needs of the platform’s customer base, which may not always match the priorities of an individual catalogue.

• Switching platforms is possible but requires careful planning for data and image portability.

Questions to ask a platform vendor

Pricing over time. This deserves as much scrutiny as the launch cost, and it is often where platforms differ most. Some subscription costs decrease over time; others increase. Ask for a realistic ten-year projection. The economics that make a platform attractive at launch should still hold—or improve—a decade later.

Vendor stability. This matters when your publication is designed to last for generations. How many active catalogues does the platform support? How is the company funded? Is there evidence of continued development? A strong and growing user community is a good sign.

Support and transition. Talk to other catalogue teams using the platform. How responsive is support when something does not work as expected? How much institutional knowledge must you retain, and how much does the vendor manage? What resources are available to help you move your data onto—and, if necessary, off—the platform?

Feature fit. Most purpose-built platforms handle standard catalogue raisonné requirements well: work records, attribution states, provenance, exhibition history, and literature. If your scholarship involves unusual data structures—highly complex edition hierarchies or deeply interlocking archival relationships, for example—test those cases specifically rather than assuming that customization will provide a solution.

Field extensibility. The ability to add fields carries a hidden cost. Fields added ad hoc, without reference to the surrounding data model, create inconsistency. The same information may be recorded in several places and in several ways, display logic may become unpredictable, and future migration may become more expensive. A platform’s data model is usually the product of sustained thinking about what a catalogue raisonné record contains. When a platform does not provide a particular field, ask why it is absent and where the information is intended to live—not merely whether the field can be added.

Images. Are images served using the International Image Interoperability Framework, or IIIF? Can you retrieve the original files at full resolution, together with their technical and rights metadata? An export that returns your records but leaves your images stranded does not provide true portability.

Data portability. If you decide to leave, can you export your records in a clean, structured format such as JSON or CSV? What happens to images and their metadata? A vendor confident in its product should answer these questions clearly. 

Collections management systems

Collections management systems occupy an adjacent space. If your organization already uses one, such as TMS, Axiell, PastPerfect, or eMuseum, the temptation to build the catalogue raisonné within it can be strong. These systems natively handle object records, provenance, exhibition history, and controlled vocabularies, and some of the relevant data may already be there.

However, a collections management system exists primarily to track what an institution holds, while a catalogue raisonné documents an artist’s complete output regardless of ownership, including works that are lost, destroyed, or known only through photographs. The record types can diverge quickly. Attribution states, edition hierarchies, rejected works, and the scholarly apparatus of a published entry rarely map cleanly onto a system designed for accessioning, location tracking, and loans.

Public presentation is another potential gap, since many collections management systems were not designed to publish a scholarly catalogue on the web.

Some institutions successfully use their collections management system as the authoritative source and export data to a purpose-built platform or custom front end for publication. Others find that the workarounds accumulate until they have effectively constructed a second system inside the first.

Assembling a system from existing tools

Assembling a solution means configuring and connecting existing tools. This usually begins with a database that stores and organizes data, metadata, and links to digital assets. On top of that may sit a content management system, a front-end theme, and various plugins or services that make the components work together.

This approach can work well when an organization already has relevant database or content-management expertise and when its scholarship fits reasonably within the structures supported by the available tools.

The appeal is that you are not reinventing every component. Each piece has already been built and, ideally, tested and maintained by someone else. The engineer’s job is to configure and connect those pieces during setup and then provide ongoing attention to prevent components from becoming outdated or version upgrades from breaking custom code.

The fact that individual components are maintained by their respective developers does not mean the assembled system maintains itself. Your organization—or an agency acting on its behalf—remains responsible for the connections, customizations, testing, and overall operation of the system.

What an assembled system typically looks like

Many assembled catalogues share a recognizable structure: a research database, often FileMaker, in which the scholarship is housed; a content management system, such as WordPress or Drupal, that renders the public site; and a bridge between them.

That bridge may be an automated export, but it is often a periodic CSV or XML export that must be reconciled manually. Images may live in FileMaker container fields or on a shared drive, then be resized and uploaded to the CMS media library. A JavaScript viewer may be added to provide deep zoom.

Variations include Drupal used alone with custom content types, WordPress with Advanced Custom Fields standing in for a data model, or Airtable used instead of FileMaker in newer projects.

CollectiveAccess occupies an interesting middle ground. It is open-source collections management software designed specifically for museums and archives. It natively handles complex object records, hierarchical relationships, and controlled vocabularies. It is free to download, but it requires significant technical expertise to deploy. Its interface is functional rather than highly polished, and implementation can cost tens of thousands. It may suit institutions with broader collections-management needs and the technical staff and budget required to support it.

Keeping track of the components and their connections

The defining feature of an assembled system is not any one component but the seams between them.

Decide early which system owns each category of information. The research database might own attribution, provenance, and exhibition history, while the system holding the images might own technical metadata, rights information, and reproduction permissions. Bidirectional synchronization of the same field is a common source of failure.

Ensure that every record has a stable identifier shared across the systems. Without one, reconciliation becomes a permanent tax on staff time.

The seams are also where much of the ongoing cost and risk reside. Every connection creates tight coupling: a change in one component may require changes elsewhere. An update to the CMS can break a plugin; a change to the database schema can interrupt an export; the abandonment of a third-party tool can require part of the system to be rebuilt. These dependencies must be documented, monitored, tested, and funded.

Where do the images live?

An assembled system requires you to answer a question that a full-service platform may answer for you: what stores, manages, and serves the images?

FileMaker container fields may work at a small scale but do not by themselves provide robust derivative generation, rights workflows, or version control. A dedicated digital asset management system—such as ResourceSpace, Piction, NetX, Canto, or CollectiveAccess used as a DAM—can handle derivative generation, technical metadata, rights, and access control. It can hold the files as the single source of truth while the research database stores references to them.

Many catalogues also use a IIIF image server, such as Cantaloupe or IIPImage, in front of the assets. IIIF is widely used to deliver high-resolution scholarly images and is supported by viewers such as Mirador and OpenSeadragon.

Every additional service is another component to configure, integrate, maintain, and fund.

What this approach offers

• Core components have already been built and tested.

• Large support communities exist around widely used software.

• The system can accommodate a broad range of scholarship without requiring every component to be built from scratch.

• Initial development may cost less than a fully custom build.

• Organizations with established technical infrastructure may be able to reuse existing expertise and services.

What this approach costs

• Dedicated technical staff or an ongoing agency relationship is still required.

• Plugins and integrations become outdated, and major CMS upgrades can break custom code.

• General-purpose tools were not designed for catalogue raisonné scholarship. Workarounds can cause long-term problems, particularly as the tools continue to be developed for purposes other than yours.

• The organization assumes responsibility for managing the assembled system, even when an external agency performs the technical work.

• Tight coupling among components increases operational and security risks. A problem in one part of the system can affect several others.

• The organization may become dependent on the agency or technical partner that understands the integrations. Changing partners can be expensive and disruptive.

• Unlike customers of a shared platform, the organization is often the only party paying for enhancements, compatibility updates, custom changes, and issue resolution specific to its system.

• The maintenance burden is ongoing and easy to underestimate at the outset.

• The research team needs enough digital literacy to explain the scholarly and publishing requirements of the catalogue. Even a strong technical team will not automatically understand the particular challenges of art-historical research and publication.

• Costs are irregular and difficult to predict because they depend on development needs and changes to the underlying components.

Over time, managing these dependencies can consume significant institutional attention. Software and project management are rarely core competencies of organizations whose primary mission is research. Staff may find themselves spending increasing amounts of time specifying technical work, reviewing estimates, testing changes, and managing vendor relationships rather than pursuing scholarly outcomes.

Questions to ask an agency or technical partner

Who maintains the connections between components? When the transfer between the database and CMS breaks, who fixes it, on what timeline, and at what cost? Is this covered by a retainer or billed as it arises?

Who owns the system? Does your organization own the custom code, configuration, documentation, deployment process, and relevant accounts? Can another agency take over without requiring the cooperation of the original supplier?

What is the upgrade path? When the CMS releases a major version, what happens to the custom code and plugins? Has the agency managed a comparable upgrade before?

What is documented? If the agency relationship ends, what will the next team receive? A configuration document, data dictionary, system diagram, deployment guide, and decision record should be considered the minimum.

Which components are load-bearing? Identify the plugins and integrations without which the catalogue cannot function. For each one, ask who maintains it, when it was last updated, and what the fallback will be if it is abandoned.

How tightly coupled is the system? Which components can be replaced independently, and which changes would require work across the entire system?

How are enhancements prioritized and priced? Is every new requirement billed as a separate project? Can improvements be reused across the agency’s clients, or must your organization finance them alone?

What is the five-year cost? Consider not merely the build cost, but also upgrades, integrations, hosting, security work, agency retainers, and the staff hours spent reconciling records or managing suppliers.

One operational practice that assembled systems require is a structured communication plan among the technology, editorial, and research teams. Regular check-ins, shared documentation, and a clear process for reporting and resolving problems help the project remain coherent as components are updated and personnel change. Establishing this structure at the beginning—rather than after the first crisis—is worth the investment.

Building a custom solution from scratch

Building from scratch means commissioning custom software. A development team designs a data model around your scholarship, writes code specifically for your catalogue, and builds the interface and technical infrastructure. This rarely means writing every layer from the ground up. Most custom projects commission a bespoke data model, application logic, and interface, then integrate an existing database, DAM, image server, or cloud service underneath. What is custom is usually the model, the workflows, and the presentation; what is bought or adopted is everything the organization does not need to differentiate.

The case for custom

The principal advantage is control. A custom build can accommodate unusual scholarly structures, including multiple edition states, uncertain attributions, complex provenance chains, and linked exhibition histories. This matters when an artist’s output genuinely resists the categories provided by existing platforms. The interface can be designed around the way your research team works and around the requirements of the larger institution. When the catalogue must integrate closely with existing systems—such as a collections database, authentication service, or digital repository—custom code may be the most effective option. The online presentation can also be designed specifically to represent the artist rather than conforming to a template. For artists whose work is closely bound up with its presentation, this is not merely a cosmetic consideration.

The potential challenges

Custom development is expensive upfront—typically tens to hundreds of thousands of dollars for a well-executed project—and costs do not end at launch. Software requires maintenance. Frameworks become outdated. Security vulnerabilities appear. Infrastructure and browser standards change. Eventually, substantial parts of the system may need to be rebuilt.

A custom build also turns the organization into a software owner. Even if an outside company writes and operates the code, the organization remains responsible for defining requirements, approving priorities, managing budgets and contracts, testing releases, accepting risk, and arranging long-term maintenance.

The relationship with the development partner can become a critical dependency. The original engineers may be the only people who fully understand the system, its undocumented assumptions, and its workarounds. If they leave—or if the agency changes direction, raises its prices, or closes—the institution must find someone willing and able to take over a unique codebase.

A shared platform develops in response to the needs of a community of users. With a custom solution, your organization is usually a single customer. It must pay for every enhancement, change, compatibility update, and issue resolution unless those items are explicitly included in a maintenance agreement.

This burden can grow over time. Organizations established to conduct and publish research may find themselves devoting increasing resources to software roadmaps, developer procurement, contract negotiation, acceptance testing, and vendor management. Every hour spent managing a bespoke software product is an hour unavailable for the institution’s primary scholarly mission.

The image layer deserves particular attention during scoping. Custom builds frequently begin with a carefully considered data model for works, attributions, and provenance but treat images as an afterthought. A folder of JPEGs and an upload form may work until the first request for a tiled deep-zoom viewer, a rights restriction that permits thumbnails but not full-resolution access, or a requirement to display a photographer’s credit with every reproduction. Adopting IIIF and a dedicated asset-management system at the outset can avoid building these capabilities twice.

What this approach offers

• Complete control over the data model, allowing unusual scholarly complexity to be accommodated.

• Interfaces and presentation designed specifically around the research team and the artist.

• Close integration with existing institutional systems and workflows.

• Control over the technical roadmap, provided the organization has the resources to exercise it.

What this approach costs

• The highest upfront and total cost.

• A need for sufficient digital literacy within the research team to articulate the requirements of the catalogue.

• Responsibility for managing an ongoing software project, including budgets, contracts, priorities, testing, and risk.

• Dependence on the developers or agency that knows the system, unless knowledge transfer and supplier independence are designed into the project from the beginning.

• Ongoing maintenance as frameworks age, security vulnerabilities appear, and rebuilds become necessary.

• Fragile institutional knowledge. If the engineers who built the system leave, their expertise may leave with them.

• A shrinking pool of developers familiar with aging frameworks, making maintenance progressively more difficult and expensive.

• The need to specify and build or integrate asset delivery, derivative generation, and rights management—capabilities that are easy to underestimate during scoping and expensive to retrofit.

• The full cost of catalogue-specific enhancements and issue resolution, rather than a cost distributed across a wider product community.

Questions to ask before commissioning a custom build

Is the data model demonstrably unusual? Map your most complex record types against what purpose-built platforms provide natively. If they fit, the case for custom rests on presentation, control, or integration rather than capability. Those can be legitimate reasons, but they are different and usually narrower ones.

Can your organization manage a software project? Scoping, procurement, contracts, acceptance testing, change requests, risk management, and the authority to reject a good idea that arrives too late are distinct competencies. A catalogue project that lacks them will not discover the fact gently.

Does managing software support the organization’s mission? Consider not only whether the institution can oversee the project at launch but whether it wants to devote staff time to software and vendor management for decades.

Is the funding recurring? A one-time grant that ends at launch leaves a system that nobody has budgeted to maintain. Software does not simply have a launch cost; it has an annual cost, of which the first year is usually the largest.

How dependent will you be on the original vendor? Can another competent team deploy, maintain, and extend the software? Do you own the source code and all relevant accounts? Are the architecture, configuration, and release procedures documented?

Who will brief the next developer? Do not assume it will be the current developer. Identify the person who will still be present in five years and who understands the system well enough to hand it over. If that person does not exist, the knowledge problem is not hypothetical.

What happens in year eight? Frameworks reach the end of their supported lives. Ask the development team what a major upgrade or rebuild would involve and what it might cost, and treat the answer as part of the purchase price.

Who pays for each improvement? Establish what is included in ongoing maintenance and what will be treated as separately commissioned development. Clarify how bugs, security updates, browser changes, accessibility requirements, and new features are categorized.

Documentation as a response to fragility

The most direct practical response to institutional fragility is to keep a running record of every important technical and editorial decision made throughout the project: why a particular framework or data model was chosen, which alternatives were considered and rejected, what workarounds were introduced, and why.

When engineers move on—and in a project intended to span decades, they will—what remains is the scholarship, the data, the code, and whatever documentation the project produced. A catalogue supported by thorough system and decision records can be maintained by developers who were not present for the original choices. A catalogue without them is far more difficult and expensive to sustain.

Documentation reduces vendor dependency, but it does not eliminate it. Good documentation cannot replace the budget, staff capacity, and governance needed to manage custom software.

This practice matters for assembled systems too, but it is most critical for a custom build, where the stack was created specifically for one organization and no product community or standard vendor documentation exists to fill the gaps.

Why technology choices have long-term consequences

Many digital catalogues raisonnés, including some built within the last decade, run on technology from the early or middle 2010s. This is not a criticism of the organizations that built them. It reflects the reality that catalogue projects operate on a timescale very different from that of digital technology.

Older frameworks receive fewer security updates and eventually reach the end of their supported lives. Web standards, accessibility expectations, browsers, and search practices change. Sites designed before responsive design became standard may provide poor experiences on mobile devices. The pool of developers familiar with aging frameworks also shrinks, making maintenance progressively more difficult and expensive.

This does not mean that you need the newest possible technology. Stability and maintainability matter more than novelty. When making a decision today, however, consider not only what will work at launch but also what the maintenance landscape will look like in five or ten years.

A platform with an active user community, a clear roadmap, and a track record of updates is often a stronger long-term proposition than a technically impressive custom build maintained by one person in their spare time. Conversely, a stable custom system supported by capable internal staff, open standards, strong documentation, and recurring funding may be more sustainable than a poorly managed commercial product.

Every approach creates dependencies. The relevant questions are who manages them, who pays when something changes, how much influence your organization has, and whether the necessary work supports or distracts from its primary mission.

Which approach is right for your catalogue raisonné?

There is no universally correct answer. The right choice depends on the complexity of your scholarship, the size and reliability of your budget, and your organization’s ability—and willingness—to sustain digital development over time.

If your budget is limited and you do not have dedicated technical or software-project-management staff, a purpose-built platform is almost certainly the right starting point. Its upfront economics are usually more favorable, and you do not assume direct responsibility for infrastructure and software maintenance. Evaluate the available platforms carefully, ask difficult questions about data portability, vendor stability, and long-term pricing, and choose the one whose data model best fits your scholarship. This allows your organization to concentrate on art-historical research rather than software management.

If you have established database or content-management expertise, whether in-house or through a trusted agency relationship, an assembled system may work. Budget for ongoing maintenance, coordination, security, and upgrades—not merely the initial build. Treat the management of components and suppliers as a permanent organizational responsibility, and plan for the possibility that the agency relationship will eventually change.

If your scholarship genuinely requires a custom solution, and your organization has the budget, project-management capacity, technical governance, and long-term commitment needed to maintain bespoke software, then building from scratch remains a viable option. Proceed with a clear understanding of the total cost of ownership and invest in documentation, knowledge transfer, and vendor independence from the first day.

The decisive question is not simply, “Can this system be built?” Almost anything can be built with sufficient time and money. The more important question is, “Does our organization want to manage and sustain this software while continuing to fulfill its research mission?”

Whatever path you choose, the most durable investments you can make are in well-structured data, clear documentation, and sustainable governance. The software will change. The scholarship is what lasts.