16 May 2026
How to Move Your Museum Collection Off Spreadsheets
How to move your museum collection off spreadsheets: clean your data, choose a collection management system, and migrate records without losing history.
A spreadsheet holds a collection together far longer than it should. That is the trap. It works well enough that replacing it never feels urgent, and then a registrar leaves, or an insurer asks for a location history, or Arts Council England wants evidence of documented procedures, and the spreadsheet stops being a tool and becomes a liability.
If you manage a museum or gallery collection in Excel, Google Sheets, or a stack of Access databases that one person built in 2011, you already know this. The question is not whether to move. It is how to do it without losing data, breaking your week, or spending money you do not have.
Here is the short version. Moving a museum collection off spreadsheets means migrating your object records into a dedicated collection management system that enforces a consistent data structure, records every change to every record, and supports the procedures that accreditation bodies expect. Most of the effort goes into cleaning your existing data before migration. The migration itself is usually the easy part.
Why spreadsheets fail collections
They do not fail immediately. That is what makes them dangerous.
A spreadsheet has no opinion about what goes in a cell. Accession number 1994.12.3 can be written as 1994.12.3 in one row and 1994/12/3 in the next and "1994.12.3 (part)" in a third, and the spreadsheet will accept all of it without complaint. Multiply that across fifteen years and four members of staff and you get a dataset that looks fine until you try to search it.
Then there is the audit problem. A spreadsheet does not remember who changed what. If an object's location was updated last March, there is no record of who moved it, when, or why. For accreditation, and for basic accountability, that history matters. The Spectrum standard maintained by Collections Trust is built almost entirely around documented, traceable procedures. A spreadsheet cannot give you that. It was never designed to.
And spreadsheets do not handle relationships. An object has a maker, a provenance chain, condition reports over time, loan history, and a physical location that changes. In a spreadsheet all of that gets flattened into columns, or scattered across tabs, or simply left out. The information that makes a collection a collection, rather than a list of things, is the part spreadsheets are worst at holding.
Clean your data before you migrate anything
This is the step everyone wants to skip and nobody should.
Before you move a single record, go through your spreadsheet and find the inconsistencies. Accession numbers formatted three different ways. Date fields that mix "c. 1880", "1880s", and "19th century". Maker names with and without dates, with initials and without. Locations recorded as "store 2" and "Store Two" and "ST2". Every one of those will follow you into the new system if you let it.
You do not need it perfect. You need it consistent enough that the new system can map it. A good rule: decide the correct format for each field, document that decision, and apply it. If you have 4,000 objects this might take a fortnight. If you have 40,000 it might take a season. Either way it is cheaper to do now, in a familiar tool, than after migration.
While you are in there, flag the gaps. Objects with no location. Objects with no accession number. Objects that appear twice. Migration is a good moment to find out how bad the backlog really is, because the new system will make those gaps visible whether you want it to or not.
Choosing where to move it to
The collection management software market has a reputation, and it earned it. Much of the established software is genuinely difficult to use. Some of it dates back decades in its core design, costs more than a small museum's entire annual IT budget, and requires consultants to do things that should take a registrar five minutes. Axiell, KE EMu, and Calm are capable systems, and large institutions run them well, but for a small or mid-sized museum they are often heavier and more expensive than the collection needs.
What you are actually looking for is fairly specific. The system should enforce structured data so the mess you just cleaned up stays clean. It should track every change with a date and a user, because that is what accreditation and accountability require. It should support Spectrum 5.1 procedures properly, not as a checkbox but as the actual shape of how you work, covering object entry and exit, location and movement control, loans in and out, and condition checking. It should handle provenance as a chain, not a text box. And it should let your team get useful work done in the first week, not the first quarter.
VitrineCMS is a modern collection management platform built for exactly this audience. It supports Spectrum 5.1 compliance, MARC records, provenance tracking, condition reporting, and loan management, and it is priced for institutions that do not have a consultant budget. It is also, in fairness, a newer and independent product, so it does not carry thirty years of installed base. For some institutions that history matters. For many others, what matters more is software that a registrar can actually use without a training contract. You can see the full feature set and how the Professional and Institution tiers compare before committing to anything.
The migration itself
This is the part people dread, and it is usually the least painful step.
Once your spreadsheet is clean and consistent, migration is mostly a mapping exercise. You decide which column becomes which field, the system imports the records, and you check a sample to confirm it landed correctly. A well-structured export from a tidy spreadsheet imports cleanly. A messy one does not, which is the entire reason step two comes first.
Do it in stages if the collection is large. Migrate one collection area, check it properly, then move to the next. Keep the original spreadsheet as a frozen reference copy until you are confident, then keep it anyway, archived, because there is no reason not to.
Expect to find things during migration. Records that do not fit the structure usually do not fit because something was wrong with them. That is the system doing its job. It is uncomfortable in the moment and useful in the long run.
What changes once you are off the spreadsheet
The day-to-day difference is that the system starts answering questions instead of you.
Where is object 2003.45.1. Who moved it last. What condition was it in when it came back from loan. Which objects in store 3 have no condition report. What is on loan right now and when is it due back. With a spreadsheet, every one of those questions is a manual search and a hope that the data is current. With a proper collection management system, they are queries, and the answers are trustworthy because the system recorded them as they happened.
It also changes what accreditation feels like. The Museum Accreditation Scheme run by Arts Council England expects documented collections management, and the gap between "we have procedures" and "here is the evidence, generated automatically" is large. A system that records procedures as you carry them out turns accreditation from an archaeology project into a reporting exercise.
None of this requires you to be a large institution with a dedicated documentation team. It requires a clean dataset, a system that suits the size of your collection, and a fortnight of unglamorous preparation. The spreadsheet got you this far, and that is genuinely worth something. It is just not what should be holding your collection in five years.
If you are weighing up the move, the most useful thing you can do is start small: create an account and migrate a single collection area to see how your data behaves in a structured system. You will learn more from moving 200 objects properly than from another month of thinking about it.
Ready to catalog your collection?
Free to start. No credit card required.
Create your free account →