How to synthesize research from acquired companies into a unified insights repository after mergers

Mergers and acquisitions bring together products, teams, and customers. They also bring together research—user interviews, usability studies, survey data, competitive analyses, and years of accumulated insights that informed the acquired company's product decisions.

This research is one of the most undervalued assets in any acquisition. It represents real knowledge about users, their problems, and what has already been tried. But in practice, it is often the first thing to get lost. Research files sit in tools nobody at the parent company has access to. Key findings live in slide decks buried in someone's Google Drive. Tribal knowledge walks out the door when employees leave during the transition.

Synthesizing research from acquired companies into a unified insights repository is not a glamorous post-merger activity, but it is one of the most impactful. Here is how to approach it.

Why research gets lost after acquisitions

Before getting into the how, it helps to understand why this problem is so common.

Different tools and systems. The acquired company likely used different research tools, file storage systems, and documentation practices. Their interview recordings might be in one platform, their synthesis in another, and their recruitment panels in a spreadsheet.

No single owner. During a merger, research operations rarely have a dedicated transition plan. Engineering systems get migrated. Customer data gets merged. Research is often treated as an afterthought because it does not have an obvious system of record the way code or CRM data does.

People leave. Acquisitions frequently lead to turnover. When the researchers or product managers who conducted the original studies leave, they take context with them—why certain decisions were made, what was tested but never shipped, and which findings were considered most important.

Urgency is elsewhere. Post-merger integration teams are focused on shipping combined products, consolidating infrastructure, and retaining customers. Research synthesis feels like a task that can wait. By the time someone gets to it, the trail has gone cold.

Step 1: Audit what exists before you migrate anything

The first step is not moving files. It is understanding what research the acquired company actually has, where it lives, and what state it is in.

Identify the research landscape

Talk to researchers, product managers, designers, and anyone else who conducted or commissioned research at the acquired company. Ask:

• What research tools and platforms did you use?
• Where are interview recordings, notes, and synthesis documents stored?
• Is there a central repository, or is research scattered across personal drives and project folders?
• What were the most important studies from the past 12 months?
• Are there ongoing studies or panels that need to be transitioned?

You are not trying to evaluate the quality of the research at this stage. You are trying to build a map of what exists and where it lives.

Assess documentation quality

Research documentation quality varies enormously between organizations. Some teams write detailed research reports with clear methodology, participant information, and tagged findings. Others work from raw notes and verbal debriefs with little written synthesis.

Understanding the documentation quality helps you plan how much effort the synthesis phase will require. Well-documented research can be migrated and retagged relatively quickly. Poorly documented research may need to be reviewed, re-synthesized, or even deprioritized if the original context is unrecoverable.

Create a research inventory

Build a simple inventory—a spreadsheet is fine at this stage—that catalogs each study or research artifact. Include:

• Study name or description
• Date conducted
• Research method (interviews, survey, usability test, etc.)
• Product area or feature it relates to
• Where the original files are stored
• Documentation quality (high, medium, low)
• Relevance to the combined organization's current priorities

This inventory becomes your working document for prioritization and migration planning.

Step 2: Define the structure of your unified repository

Before migrating anything, decide how the combined organization's research repository will be structured. Dumping files from two companies into one folder is not synthesis—it is a bigger mess in a single location.

Align on taxonomy and tagging

A useful insights repository needs a consistent taxonomy so people can find research when they need it. Common dimensions include:

• Product area or feature — What part of the product does this research relate to?
• User segment or persona — Who was studied?
• Research method — How was the data collected?
• Theme or topic — What broad question does this research address (e.g., onboarding, pricing, accessibility)?
• Date and recency — When was this research conducted?

If the parent company already has an established taxonomy, use it as the starting point and extend it to accommodate the acquired company's product areas and user segments. If neither company has a clear taxonomy, this is an opportunity to build one properly.

Choose a single platform

Consolidating into a single platform is essential. Running parallel research tools creates exactly the kind of fragmentation you are trying to eliminate.

This is where a dedicated research repository like Dovetail can be particularly useful. Rather than storing insights across slide decks, wikis, and various analysis tools, a centralized platform lets you tag, search, and connect findings across the entire organization. When research from both companies lives in the same system with consistent tagging, anyone on the combined team can discover relevant past work before starting a new study.

Whatever platform you choose, commit to it as the single source of truth for research insights going forward.

Step 3: Prioritize what to migrate

You will rarely have the resources to migrate and re-synthesize every piece of research from the acquired company. Prioritization is necessary.

Start with high-relevance, high-quality research

Use your inventory to identify research that is both highly relevant to the combined organization's current priorities and well-documented enough to migrate without extensive rework. This is your first wave.

Examples might include:

• Foundational user research on the acquired product's core audience
• Usability studies on features that will be integrated into the parent product
• Customer segmentation or persona research
• Competitive research on markets the acquisition was meant to enter

Defer or archive low-priority research

Research that relates to deprecated features, markets the combined company is exiting, or products that will be sunset can be archived rather than actively migrated. Archive it in a way that preserves access—someone may need it later—but do not spend time re-synthesizing it.

Flag research that needs re-synthesis

Some research will be relevant but poorly documented. Flag these studies for re-synthesis if the original researchers are still available to provide context. If they are not, make a judgment call about whether the raw data (recordings, notes) is rich enough to synthesize from scratch.

Step 4: Synthesize across company boundaries

Migration is not the same as synthesis. Moving files into a shared repository is a logistics task. Synthesis is the intellectual work of connecting findings across the two organizations to surface patterns, contradictions, and gaps.

Look for overlapping user segments

If both companies served similar user segments, compare what each learned about those users. Where do findings align? Where do they diverge? Divergent findings are not errors—they often reflect differences in product maturity, market positioning, or research methodology. Document these differences explicitly so future teams understand the nuance.

Identify compounding insights

Sometimes the most valuable outcome of merging research is discovering that two independent teams arrived at similar conclusions from different angles. These compounding insights carry more weight than either finding alone and can accelerate product decisions that were previously stalled for lack of evidence.

Surface knowledge gaps

Overlaying the research from both companies will also reveal gaps—user segments that neither team has studied, product areas with no research foundation, or critical questions that were never formally investigated. Document these gaps as a research backlog for the combined team.

Maintain provenance

When synthesizing, always preserve the provenance of each finding. Tag or annotate where each insight came from—which company, which study, which researcher, which time period. This context is critical for evaluating the reliability and applicability of findings, especially as time passes and the people who conducted the original research move on.

Step 5: Make the repository usable, not just complete

A repository that nobody uses is a waste of the effort you put into building it. Once you have migrated and synthesized the research, invest in making it discoverable and integrated into how teams actually work.

Onboard teams to the repository

Run onboarding sessions for product managers, designers, and engineers from both the parent and acquired companies. Show them how to search for existing research, how findings are tagged, and how to contribute new research. The goal is to make checking the repository a habit before kicking off any new study.

Create entry points for common questions

Build curated collections or summary pages around the most common questions teams ask. For example, "What do we know about enterprise onboarding?" or "What research exists on pricing sensitivity in the SMB segment?" These entry points reduce the barrier to using the repository and help people who were not involved in the original research quickly get up to speed.

Establish contribution norms

Define clear expectations for how new research should be added to the repository going forward. If everyone follows the same tagging conventions and documentation standards, the repository stays useful as it grows. If contribution is ad hoc, it degrades quickly.

Common mistakes to avoid

Treating migration as a one-time project. Research synthesis after a merger is not a project with a clean end date. New context will emerge, additional research will be discovered, and taxonomy will need to evolve. Plan for ongoing curation.

Over-indexing on volume. The goal is not to have the most research in your repository. It is to have the most useful research, well-organized and easy to find. Be willing to archive or exclude research that does not serve the combined organization.

Ignoring cultural differences in research practice. Acquired teams may have different standards for what counts as research, how rigorous it needs to be, or who is qualified to conduct it. These differences need to be acknowledged and reconciled, not steamrolled. Align on shared standards going forward, but respect the context in which past research was conducted.

Waiting too long to start. The longer you wait, the more context you lose. People leave, tools get decommissioned, and institutional memory fades. Start the audit within the first few weeks of the acquisition closing, even if full migration takes months.

Building a research culture that survives the next merger

If your organization acquires companies regularly, the process described here should become a repeatable playbook rather than a one-off scramble. Standardize your research audit template, establish a default taxonomy that can accommodate new product areas, and choose tools that scale across teams and business units.

A platform like Dovetail can serve as this connective layer—a single place where research from any team, product, or acquired company can be stored, tagged, searched, and built upon. When insights are centralized and structured, they compound over time rather than decaying.

The real value of synthesizing research after a merger is not just preserving what was learned. It is making the combined organization smarter than either company was alone. That only happens when insights are accessible, connected, and actively used to inform decisions.