Migration Madness
I spend a lot of time researching how to migrate content efficiently from one platform to another. In the past four years, I have worked on two major migration projects and hundreds of smaller ones. The smaller ones are generally not that time consuming, but the major projects are apt to cause PTSD.
My first major migration at SDSU was helping the library archives’ faculty and staff transition from iBase to Islandora. Islandora has already been established with a good bit of content from another system that was migrated into it before I arrived at SDSU. They needed to transfer the data, collection-by-collection, so archives faculty and staff may clean up the metadata for each entry as they go. The best way for them to do this is to pull the data sets into separate CSV files per collection. Each row needs to be in a particular order to suit the ingest process in Islandora— so I wrote a script to do this for them. Easy enough right? Well, the number of collections multiplied by the shear volume of data in each collection, and then considering the time in manually fixing the metadata equals. . .eons later. . .I am still helping migrate the data. But hey, it is getting there!
My second major migration at SDSU was to help the library special collections group transition from Archon to ArchivesSpace. This migration was more difficult than it needed to be in large part due to ArchivesSpace requiring a very particular setup that can easily break if not configured exactly. I cannot tell you how many times I had to rollback the system to a working snapshot just because I made one change to the config file. Did I mention that my actions were always per the installation documentation provided by ArchivesSpace? After finally getting the system to properly function, it took around two months to migrate the data using the ArchiveSpace migration tool. It did what it was supposed to do— for the most part— but it took a few custom scripts before the data was correct and actually ready to launch. I have become confident while working with this server over the years, and much better at figuring out what works for it and what does not.
This year, I am looking into another major migration project. Islandora 7 will hit end-of-life November 2022, and it has got to be migrated to something else. Currently, there appears to be two options: Islandora 8 and Archipelago. You would think Islandora 8 would be an easy-ish update, but unfortunately, the company had to rewrite it and it is now basically a completely different system. So it requires a complete migration. Due to having to perform a full migration regardless of which option we choose, a new option, like Archipelago, is becoming more appealing. My team works very well with Metro, the company that created Archipelago. We have worked with Metro in Islandora 7 for the past five years, too, and the experience has been very positive. I look forward to working with Metro in Archipelago should it be the chosen route. Regardless, migrating systems always teaches me something new and useful for future projects.