How to audit and clean up a legacy research repository before migrating to a new platform

Most research teams that move to a new repository bring a backlog with them. It's usually years of interview recordings, transcripts, and notes spread across shared drives, wikis, spreadsheets, and old tools. Much of it is untagged. Some of it is duplicated. A portion of it probably shouldn't exist anymore.

Moving all of that into a new platform as-is just relocates the mess. Searching for "onboarding friction" still returns nothing useful, and stakeholders still give up and run their own surveys. A new tool only helps if what goes into it is findable, trustworthy, and compliant.

This guide covers how to audit, triage, and clean up a legacy research repository before migration. The goal isn't perfection. It's a repository your team will actually use.

Why clean up before you migrate

You could move everything first and sort it out later. Teams that try this tend to regret it, for a few reasons.

Migration is your best chance to reset. Once data is in a new system, inertia takes over. The structure you start with is the one you'll live with for years.

Bad data erodes trust fast. If the first few searches in a new repository turn up outdated findings, broken files, or duplicate studies, people stop using it. First impressions matter for adoption.

You may be holding data you shouldn't. Legacy repositories often contain recordings with expired consent, unredacted personal information, or files past their retention date. Migrating them copies that risk into a new system.

Storage and licensing often scale with volume. Moving terabytes of unused video can cost real money, both in the migration itself and in ongoing storage.

Step 1: Define what the new repository is for

Before you open a single folder, agree on what the new repository needs to do. This decides what's worth keeping and how much effort to put into cleanup.

Ask your team and key stakeholders:

• Who will use the repository? Researchers only, or product managers, designers, and leadership too?
• What questions should it answer? For example: "What do we know about enterprise admins?" or "Have we tested this flow before?"
• How far back does research stay relevant in your context? A fast-moving consumer app may find two-year-old usability findings mostly obsolete. Foundational research on customer needs can stay useful far longer.
• What compliance requirements apply? Think GDPR, HIPAA, internal retention policies, and customer contracts.

Write the answers down. They become your criteria for every keep-or-cut decision later.

Step 2: Build a complete inventory

You can't clean up what you can't see. The first real task is a full inventory of every piece of research, wherever it lives.

Find everything

Legacy research is rarely in one place. Check:

• Shared drives and cloud storage folders
• Old research or note-taking tools
• Wikis and internal documentation
• Video conferencing cloud recordings
• Personal drives of current and former researchers
• Slack or Teams channels where findings were shared
• Slide decks and readouts saved by product teams

Former team members' files are a common blind spot. Talk to IT about accounts that may hold research before they're deleted.

Record it in a spreadsheet

Create one row per study, not per file. Studies are the unit people search for, and working at that level keeps the inventory manageable. Useful columns include:

• Study name and a short description
• Date conducted
• Researcher or owner
• Method (interview, usability test, diary study, survey)
• Participant type or segment
• Product area or feature
• Assets available (recordings, transcripts, notes, synthesis, final report)
• File locations
• Consent status and consent form location
• Contains sensitive data? (yes / no / unknown)
• Proposed action (keep, archive, delete)

You won't be able to fill in every field for every study. That's fine. Gaps are useful signals. A study with no owner, no date, and no consent record is a strong candidate for archiving or deletion.

Step 3: Triage into keep, archive, and delete

With the inventory in hand, sort each study into one of three buckets.

Keep

Research that is relevant, usable, and compliant. It typically has:

• Valid consent covering storage and internal reuse
• Findings still relevant to your current product, users, or strategy
• Enough supporting material (transcript, notes, or synthesis) for someone to understand it without the original researcher

Archive

Research you might need someday but that shouldn't clutter the new repository. Examples include studies on retired products, early-stage explorations superseded by later work, and research with historical value but little current relevance. Move these to low-cost cold storage with a simple index so they can be retrieved if needed.

Delete

Research you shouldn't keep, or that has no value. This includes:

• Recordings with missing, expired, or insufficient consent
• Data past your organization's retention period
• Exact duplicates
• Corrupted or unplayable files
• Abandoned studies with no usable notes or outcomes

When you're unsure, archive rather than delete. But be honest about it. A huge archive bucket often means the team is avoiding hard decisions.

Step 4: Check consent and sensitive data

This deserves its own step because it's the one teams skip most often, and it carries the most risk.

For every study in the "keep" bucket, confirm:

Consent covers what you plan to do. If participants agreed to have their recording used "for this study," that may not cover storing it in a searchable repository open to the whole company. Check your consent language and talk to your legal or privacy team if it's unclear.

Personal information is handled properly. Look for full names, email addresses, phone numbers, account IDs, and health or financial details in transcripts and notes. Decide whether to redact, pseudonymize, or restrict access.

Retention periods are respected. Many organizations have policies limiting how long participant data can be held. Flag anything approaching its limit.

Access levels are defined. Some research, such as interviews with enterprise customers under NDA, may need restricted visibility in the new platform. Note this in your inventory so permissions can be set during migration.

This is tedious work, but it protects participants and your organization. It also builds credibility for the research function.

Step 5: Design a taxonomy before you tag anything

The heart of the problem is usually untagged interviews. The instinct is to start tagging right away. Resist it. Tagging without an agreed taxonomy produces inconsistent tags that are just as hard to search as no tags at all.

Separate study-level metadata from content tags

There are two kinds of labels:

• Study-level metadata describes the study as a whole: date, method, product area, participant segment, researcher. It's relatively easy to apply and gives you a lot of value. Being able to filter "all interviews with enterprise admins from the last 18 months" is already a big improvement.
• Content tags are applied to specific moments or highlights inside an interview. Examples are "pricing confusion," "workaround," or "integration request." They're more powerful but much more effort to apply.

For legacy data, study-level metadata should be your first priority. It's the fastest path to a searchable repository.

Keep the content taxonomy small

A good starting taxonomy for content tags usually has a few broad groups with a manageable number of tags in each. Common groupings include:

• Product area (onboarding, billing, reporting)
• Experience type (pain point, need, delight, workaround)
• User goal or job (the task the participant was trying to complete)
• Segment or persona (if not already captured at study level)

Aim for tags that are mutually understandable. Two researchers should apply the same tag to the same quote most of the time. Write a one-sentence definition and an example for each tag. If you can't define a tag clearly, merge or drop it.

Mine old tags and reports for vocabulary

Even "untagged" repositories usually contain some structure. Look at old spreadsheets, partial tags, slide headings, and the language stakeholders use when they ask research questions. Building your taxonomy from terms people already use makes it more likely to stick.

Step 6: Tier your cleanup effort

Not every interview deserves the same attention. A tiered approach keeps the project from stalling.

Tier 1: High value, deep cleanup. Recent studies, foundational research, and work tied to current strategic priorities. These get full study metadata, clean transcripts, and content-level tags. Aim for this tier to be a small fraction of your total volume.

Tier 2: Useful, light cleanup. Relevant studies that are less central. These get complete study-level metadata and perhaps a short summary of key findings, but no detailed highlight tagging yet.

Tier 3: Keep for completeness. Older but still valid research. These get minimal metadata: date, method, product area, owner. They're findable but not deeply indexed.

You can always move studies up a tier later, when a new project makes them relevant.

Step 7: Tag efficiently

Once you have a taxonomy and a tiered plan, the actual tagging can begin. A few practices make it faster and more consistent.

Calibrate first. Have two or three researchers tag the same two interviews independently, then compare. Where they disagree, refine tag definitions. An hour of calibration saves days of inconsistent work.

Batch by theme or product area. Tagging all the onboarding interviews together is faster than jumping between topics. Researchers build context and spot patterns across studies.

Fix transcripts selectively. Old auto-generated transcripts can be poor. Correct them fully for Tier 1 studies. For others, fix only errors that would break search, such as product names, feature names, and key terms.

Use AI assistance where it fits, but review it. Many modern research platforms, including Dovetail, can transcribe recordings, suggest highlights, and help apply tags. This speeds up work on large backlogs considerably. Treat the output as a first draft. Someone who knows the taxonomy should spot-check for accuracy, especially on Tier 1 material.

Track progress visibly. Add a status column to your inventory, such as "not started," "metadata done," or "fully tagged." Visible progress keeps momentum up and helps you report to stakeholders.

Step 8: Plan and pilot the migration

With a cleaned inventory and taxonomy, you're ready to plan the move itself.

Map old structure to new

Document how each field in your inventory maps to the new platform. That covers study metadata to project fields, tags to the new tagging structure, and file types to supported formats. Look for anything that won't transfer cleanly, such as comments, embedded links, or custom fields.

Run a pilot

Migrate a small, representative batch first. Include a mix of tiers, file types, and studies with access restrictions. Then test:

• Can people find what they expect through search and filters?
• Are permissions working correctly?
• Did recordings, transcripts, and timestamps come through intact?
• Do links in old reports still point somewhere sensible?

Fix problems at pilot scale, where they're cheap, before running the full migration.

Communicate the cutover

Tell stakeholders when the old system goes read-only, where to find research going forward, and who to contact with questions. Redirect old links where you can. If people can't find research in the first week, many won't come back to look again.

Set up governance so you don't end up here again

A clean repository decays quickly without basic upkeep. Before you finish, agree on:

• Required metadata for new studies. Make a small set of fields mandatory at project creation.
• Taxonomy ownership. Name one person or a small group who approves new tags and merges duplicates.
• Regular reviews. A quarterly check for unused tags, stale studies, and approaching retention limits keeps things healthy.
• Onboarding for new researchers. A short guide to the taxonomy and repository conventions prevents drift.

Common mistakes to avoid

• Trying to tag everything to the same depth. This is the main reason cleanup projects stall. Tier your effort.
• Building an overly detailed taxonomy. Hundreds of tags look thorough but get applied inconsistently. Start small and expand based on real use.
• Skipping consent checks. Migrating noncompliant data creates risk that's harder to unwind later.
• Doing it alone. Involve other researchers and a few stakeholders. They'll catch gaps and be more invested in the result.
• Treating migration as the finish line. The repository's value comes from ongoing use and maintenance, not the move itself.

Final thoughts

Cleaning up a legacy research repository is unglamorous work. It also has some of the highest leverage of anything a research team can do. Years of past interviews hold insights that can save teams from repeating studies, settle debates with evidence, and show patterns no single project could reveal. Those insights only help if people can find and trust them.

Start with a clear purpose, take an honest inventory, make firm triage decisions, and put structure in place before tagging. Whether you're moving to Dovetail or another platform, that groundwork is what turns a pile of old recordings into a research repository your organization actually relies on.

In most cases, finalize your taxonomy before migrating and do most of the detailed tagging after. Agreeing on tags, study-level metadata, and naming conventions ahead of time means your new platform starts with a consistent structure. Detailed highlight-level tagging is usually faster in the new tool, especially if it offers search, bulk actions, or AI-assisted suggestions. The exception is a small set of high-value studies that stakeholders will look for on day one. Tag those before launch so the new repository feels useful right away.

Delete material you can't legally or ethically keep. That includes recordings with expired or missing consent, data past your retention period, and files with sensitive personal information you have no reason to hold. Next, look at research that is both outdated and low quality, such as abandoned studies with no notes or recordings of features that no longer exist. If you're unsure, archive rather than delete. Cold storage costs little, and it keeps your new repository focused on research people will actually use.

It depends on volume, file sprawl, and how much consent checking is needed, but many teams finish a focused cleanup in four to eight weeks. The inventory and triage phases tend to take longest because files are often scattered across drives, folders, and personal accounts. Splitting the work into tiers, with deep cleanup for high-value studies and light metadata for everything else, keeps the timeline realistic. Trying to tag every interview to the same depth is the most common reason these projects stall.