Once you've reviewed the data sources you would like to centralize, it's time to look at your existing research. Maybe you have a few years of research reports accumulated on Google Drive or SharePoint, or perhaps you just got started last year. Either way, you need to check whether or not the research you did in the past is still valid. You can look at your decks, research summaries, and raw data and answer the following questions: Is this still true? How is this helpful? How much evidence/raw data do we need to keep/use? Are we legally able to keep this data? Any chances we will use these insights to complement further research on this topic? The outcome of this exercise is an inventory of the data worth keeping, worth revising, and a list of the data you will be migrating or centralizing in your research repository. After you've done your review, Let's say that you have lots of decks and research data from the past that you would like to migrate to the repository. Here are two approaches you can take to make that work as easy as possible for your team, we've seen all these approaches work well in different teams so you can pick that one you feel may fit better your current situation: 1. Big bang migration: Some teams feel like it's better to get it all done at once, normally driven by how much of a priority the research repository is in their organization. If it is a priority for the team, normally they can have multiple people focus on the migration during a given period of time. In this case, migration becomes a project that may take a week or two, with multiple people uploading and categorizing previous research insights and projects. 2. Migration as we go: This approach is for teams that can take things a little bit slower. These teams are normally spread thin with multiple projects and need to make progress on their insights management strategy without stopping everything else. In this case, teams may decide to just migrate research relevant to the next quarter's theme or migrate just the last year of research one hour a week. You can create a schedule where migration happens every week. but slowly and consistently. The key is not to let the migration process be too overwhelming. It needs to be strategic, and it needs to be done so you can make progress, whether it's very fast or slow.