What migrating our research repository taught me about knowledge management
Repositories have been a hot topic in the UX research field over the last few years. While there are plenty of great resources that cover the process of selecting and configuring a repository from scratch, there is little information available about migrating from one platform to another. Having all your research in one tool is great, but what happens when you need to move it?
As a Research Ops Lead, last year I found myself in a situation where our previous repository tool was acquired, and changes to the contract terms prevented us from renewing the service. This presented an unplanned and complex challenge for our research team. Here are the things I learned after going through this process end-to-end.
Start with the end in mind (and work backwards)
With thousands of hours of recordings and transcripts and hundreds of research artifacts, we faced a hard deadline to move our previous repository before it was retired in just 11 months’ time. To tackle this challenge, we had to work backwards. As the sole team member responsible for operations, I knew I had to prioritize my time and work on multiple work streams simultaneously. I divided the work into rough quarters and quickly created a plan:
Working in a security-centric organization means that our procurement cycles are usually longer than other places. Although we quickly identified Dovetail as our new repository tool of choice, it would still take 3–4 months before we could begin the migration process in earnest. Given this constraint, it was crucial to make progress on more than one priority simultaneously. This meant working on tasks over which I had more direct control while waiting for security reviews, contract redlines, and signatures to be completed.
Know when (and where) to ask for help
The planning process was crucial for several reasons. For one, it made me realize that I couldn’t handle the volume of research to be migrated by myself. Since the migration needed to be done manually, one project and asset at a time, I initiated one of the first work streams with my DesignOps team to secure budget and resources for a small group of contractors to assist with the migration.
I then identified the essential documentation required by our researchers to work efficiently with the new tool, minimizing interruptions and ongoing technical debt from using two tools. Interestingly, the documentation I prepared for the contract migration team was as critical as the materials for the researchers, potentially saving us weeks of time.
Documentation is your friend
The introduction of an external team of contractors prompted me to manually migrate a few studies on my own, in order to anticipate any differences in data modeling that might exist between our old repository tool and our new one. I started by outlining all the necessary steps for exporting the data, as well as the general types of studies, raw assets, and tagging systems that the migration team could expect to encounter.
During the process of creating this guide, I learned a few important things:
- Our current tagging system was too fragmented to be effectively migrated;
- A new, simpler taxonomy would be necessary for the repository, along with a plan for ongoing maintenance;
- Tracking the migration on a study-by-study basis was crucial to ensure that no studies were missed.
So before the actual migration could begin, it became clear we needed to do some housekeeping first. Investing time in providing a clear organizational structure for our studies would not only make the migration process more straightforward, but it would also help our researchers get accustomed to the new repository by making data and insights easier to locate.
Tend your “data garden”
One of the most challenging parts of iterating on a new taxonomy was figuring out mappings: how to translate our old tagging system into a more streamlined version. Some groupings were obvious, while others were more complicated and required trial-and-error by referencing actual projects. Consulting the research team was also essential, and once a draft of the mappings was ready, I invited them into a spreadsheet I created to provide feedback and suggestions. As this system would define the organization of the new repository going forward, I wanted to ensure they had multiple opportunities to contribute to the outcome.
After the new mappings were prepared, they were included in both the repository as attributes in Dovetail and as steps in the migration documentation. Although it required a significant amount of effort, having a clear taxonomy made it much easier for the migration team to categorize studies and gain context quickly.
The actual migration
Once the planning steps were complete, it was time to get down to the business of migrating the studies. As the team of contractors was located in Australia and New Zealand (a 17 hour time difference from my location), planning was crucial; we used a combination of a group Trello board, Slack, and a “burn down” sheet in Google Sheets to track our progress. This combination of synchronous and asynchronous communication meant that we only needed to meet in real time once a week throughout the course of the project.
While we were moving off of our old repository, I was simultaneously onboarding the research team to Dovetail and providing documentation to acclimate them to the new experience. With two months to spare before our old repository was to be retired, all new research was taking place in Dovetail, which substantially reduced the amount of additional material that needed to be migrated.
What I’ve learned (and what I would have done differently)
By the end of the year, 11 months after we began the journey, we successfully migrated our content from our old repository into Dovetail. Since then, we have continued to add more members of our product team into the platform. While the migration was undoubtedly successful given the alternative of losing all of our precious insights, there are a few things I would do differently, knowing what I know now:
- Think about your communication plan from the very beginning. Making any significant adjustment to the way your team works involves a lot of change management, and communicating early and often is an important part of that process. Having clear document deliverables that are timed with milestones in the project from the outset would have saved time after the project was complete playing “catch up”.
- Build out an ongoing maintenance strategy as you go. Similarly, thinking ahead to the future about when and how to maintain our repository will be vital to ensuring it remains a reliable and trusted source of insight for years to come. Setting a cadence for taxonomy and asset management (e.g. monthly or quarterly) is a solid first step in this direction.
- Take time to celebrate achievements (and document them!). This one is often easy to overlook (and why I’m taking time to write this article). While there will always be more work to do, recording what has been accomplished and the benefit it will provide is an important part of turning the page on a project, even if it has no true end.
I hope this article has been helpful, in whatever stage of the repository journey you find yourself. Please feel free to reach out to me on LinkedIn or elsewhere if you have additional questions about my approach, or have any tips or suggestions!
