Archival Description Management Software

One factor that comes immediately to mind is around consortial use. Are you imagining  one AtoM instance used by several institutions, or multiple AtoM instances, each for an institution? If the former, there are some further considerations. AtoM's multi-institutional functionality right now is geared more towards public users - e.g. it is designed to support usage as a union catalogue or regional portal. However, not all of the internal modules are designed for full multi-institutional usage. 

For example, accessions, physical storage, donors, rights-holders - these modules do not currently have a way to separate records by institution, as they were not designed (or have not yet been developed further to support) multi-institutional usage. Do you intend to use these modules, or do individual institutions have separate systems in which storage location and accession information will be kept? The same is true for authority records in AtoM - they cannot at present be organized/browsed by repository (though this is a development we would like to see happen in AtoM). Is this a critical factor to you?

Another factor we often come up against is about authority records in general - we have found that fewer institutions than we expected have actually implemented any kind of authority control over their holdings, and because of this, it can lead to a lot of duplication and possibly manual cleanup after a migration into AtoM. 

AtoM will create authority records for all names added to the system as creators or access points, so that a single authority can be associated with multiple resources in different capacities over time, to eliminate variations in naming conventions and general confusion for end users - this way you have multiple entry points into exploring a collection. If you are interested in a specific person, you can find their authority record and view all descriptions associated with them, and vice versa. The standards-based reasons, and the specific ways in which this is implemented in AtoM, are described in our documentation here: 

• https://www.accesstomemory.org/docs/2.1/user-manual/add-edit-content/authority-records/#atom-authority-records-biographical-histories-and-name-access-points
• https://www.accesstomemory.org/docs/2.1/user-manual/add-edit-content/terms/#term-name-vs-subject

Often we have found that users migrating into AtoM have not properly implemented ISAD(g)'s 3.2.2 Administrative / Biographical history field - instead of making their description of an actor's history general to the actor, they have used it to add a sort of scope and content specific to one description. In AtoM, the admin/bioghist data is stored with the authority record and is then visible on each description where the actor is linked as a creator, as ISAD and ISAAR recommend - so if you try to import multiple descriptions with the same actor but different histories, one will overwrite the last in the authority record, and the last imported version will be visible in all linked descriptions. This often means doing data cleanup to achieve true standards-compliance prior to migration.

We have done many large migration projects! We are currently undergoing a massive migration with the World Bank Archives, who have previously been using TRIM internally for managing their archival holdings, and want to move to a standards-based system that the public can access. They will be migrating about +/-1 million records into AtoM, and hope to launch next year. I can share this because they have publicly mentioned as much in places such as the LoC's Signal blog in interviews. We have a couple other very large international organizations working on data migrations with us as well! 

In terms of challenges and lessons learned, see above about authority records - but in general, the biggest issue is with standards compliance. AtoM was designed around the ICA standards - fortunately, the DACS standard maps pretty much 1:1 to ISAD(g), but users have often added custom fields in their internal systems, or have not followed any standard when creating their descriptions. The biggest part of our migration work is to partner with archivists from the institution in question and map their customized data to standards-based fields in ISAD(g), so we can import them into AtoM. If your descriptions are already standards-based, this can take a lot of the pain out of performing a migration. 

The other challenge of course is around the legacy system the client is leaving, and how easy/hard it is to get data out. If there is a CSV or EAD export option in your legacy systems, this can help a lot. If not, then the challenge is to figure out how to convert a custom or proprietary data model to something open such as AtoM. 

I recently prepared a lengthy email for a client beginning a migration via CSV import that outlined the process and factors we will need to consider. I would be happy to anonymize the content and forward it to you if you think it would be useful.

This is definitely something we intend to pursue - I recently attended the webinar organized by Michael Rush of the SAA's Technical Standards Committee so we could get a sense of the coming changes and figure out what it will mean for AtoM. We're excited about the changes - they introduce more structure that will make managing descriptions in a database system much easier, in fact! 

We will definitely be waiting until the final version of the new EAD standard is released before considering implementation - things are still changing, even this late in the game. Beyond that, it will depend on the priorities and support of our community. 

As a small company, we follow what is often called community-driven development, or the Bounty Model of open source. Meaning, we offer our software, all our documentation, and user support via the forum free of charge to all users, and as a company we maintain and develop the software by offering fee-based value added services - hosting, theming, consulting, data migrations, trainings and workshops, and custom development. Because we are small, we often can't afford to take on major development projects or code revisions without community sponsors - in fact, this is how every feature in AtoM has been supported thus far. When we are approached by an institution with a need for a new feature or functionality in AtoM, we work with the client to develop the feature in such a way that it meets their specific use case, but can also be generalized enough to be useful to the broader community - and we always aim to release custom sponsored developments in a future public release. This way, when one institution sponsors development in AtoM, the entire community benefits, and the sponsoring institution does not have to maintain the feature - if it goes in the public release, Artefactual maintains the feature over time so it continues to work in future versions. As well, as an open source project, anyone can develop features for AtoM, and if they share those customizations back with us, we will often include them in the public release as well - 2.1 includes several features developed by community members and generalized into AtoM's code base. The advantages of not having to maintain the feature over time are still gained by the contributors, and again, the whole community benefits. Finally, Artefactual commits to incrementally including minor improvements and bug fixes with each release, so that we are maintaining key features and improving the application over time. 

So when it comes to larger changes like EAD3, this is something we definitely want in AtoM, and believe that our community will want as well, but the development required will likely be somewhat beyond what Artefactual, as a small company with limited resources, can take on without sponsorship. This means we will be looking to partner with institutions who are willing to help us develop this - and once it is sponsored, all users will have access to the results. We're currently exploring ways that we can help smaller institutions with limited budgets work together to collectively fund common feature requests, such as crowdfunding models. The user forum can be an excellent way to connect users so they can continue discussions off-list about such collaborative development funding as well. As to when we might see EAD3 in AtoM - that will depend on how much of a priority the feature is to our users.