> For the complete documentation index, see [llms.txt](https://docs.nested-knowledge.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nested-knowledge.com/get-started/migrate-to-nk.md).

# Migrate To NK

Learn how to import your existing reviews into Nested Knowledge.

If your review began elsewhere, import its existing work into a nest to maintain as a living review. Import records, screening decisions, and tags. You can then continue the review without repeating completed work, add additional modules and create living outputs from your current data.

### What You Can Bring Into A Nest

Import these three layers as separate files in order:

1. **Records** are the imported items from your search. Import these first through [**Import Search Files**](/review-workflow/literature-search/add-search/import-search-files.md). Other imported data attaches to these records.
2. **Screening decisions** record included and excluded studies, plus exclusion reasons. See [**Import Screening Decisions**](/review-workflow/screening/import-screening-decisions.md).
3. **Tags** capture review data. A tag is a datapoint or a set of datapoints. It can include text excerpts or table data. See [**Import Applied Tags**](/review-workflow/tagging/import-applied-tags.md).

Nested Knowledge matches layers by DOI, title, PubMed ID, Ref ID, or External ID. Keep at least one identifier consistent across every file. Unmatched rows return in a spreadsheet for correction and re-upload.

### What You'll Rebuild In Nested Knowledge

You can't import [**Meta-Analytical Extraction**](/review-workflow/meta-analytical-extraction.md), [**Critical Appraisal**](/review-workflow/critical-appraisal.md), or export templates. Each depends on configuration stored inside your nest. Rebuild these layers after migration. This makes the data filterable and available in **Synthesis**, Dashboards, PRISMA reporting, and exports.

### Prepare Your Export From Your Current Platform

Export the data from your current platform. Then reshape its columns to match the import templates:

* Import records from a RIS or NBIB file. You can also use a spreadsheet with a DOI or PubMed ID column.
* Import screening decisions and tags from spreadsheets matching the templates. Download templates from **Nest Settings** → **Import**.

<figure><img src="https://305208404-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxb7uNGATUgwQAjDVQRXG%2Fuploads%2FBhRJqMn4lPL2bztPshIY%2Fimport.png?alt=media&amp;token=de2f3305-e016-4c1f-8250-6b3f6e1bae5c" alt="Nest Settings Import screen showing import templates."><figcaption><p>Download import templates from Nest Settings → Import.</p></figcaption></figure>

The export process differs by platform. The template reshaping step stays the same.

<details>

<summary>From Covidence</summary>

Covidence exports citation lists from the review summary's **Export** tool. Export a list, then choose its format.

Export the complete reference set as RIS for records. Export included and excluded lists as CSV for decisions. The excluded list includes exclusion reasons.

Covidence CSV exports also include reference tags and notes. Reshape their identifier, decision, reason, and tag columns to match the templates.

</details>

<details>

<summary>From Rayyan</summary>

Rayyan exports from **Export** in the review's upper-right menu. Choose a format and include decisions, exclusion reasons, labels, and notes. If you screened as a team, turn off Blind Mode first. Otherwise, the export includes only your decisions.

Export references as RIS. For decisions and tags, export a CSV with decisions, exclusion reasons, and labels.

Rayyan places decisions, labels, and notes in one notes column. Markers include `RAYYAN-INCLUSION` and `RAYYAN-LABELS`. Split this column into the screening and tag templates. Rayyan labels map to tags. Rayyan exclusion reasons map to screening decisions.

</details>

<details>

<summary>From DistillerSR</summary>

DistillerSR uses configurable reports. Export your reference set. Then use **Reports** and Datarama to create a CSV report with a DOI, PubMed ID, or Ref ID alongside screening-form results.

If screening and tagging questions use separate forms, merge data by reference. Map the screening outcome to the exclusion reason column. Leave the cell blank for included records. Map classification fields to tag columns.

</details>

<details>

<summary>From Another Platform</summary>

Most platforms follow the same pattern. Export references as RIS or NBIB. Export a separate spreadsheet with each study's identifier, decision, exclusion reason, and tags.

If your platform only provides a reference-manager export, use EndNote, Zotero, or Mendeley to create a RIS file. Choose the format intended for reference managers when needed.

</details>

<details>

<summary>From A Manual Spreadsheet</summary>

A spreadsheet-based review already contains columnar data. Rename and rearrange columns to match the templates.

First, import a record spreadsheet with a DOI or PubMed ID column. Add available bibliographic columns, such as title, year, and authors.

Then create two spreadsheets from the same data. Use the screening template for decisions and reasons. Use the tag template with one column per tag. Include a matching identifier in every spreadsheet.

</details>

### A Couple Of Things To Expect Before You Import

Review each import's settings before you upload. An import can create missing exclusion reasons or tags. New tags have no parent, so assign parents in [Configure Tagging](/review-workflow/tagging/configure-tagging.md) afterward.

The overwrite setting replaces existing decisions or tags without a change report. Select it only when you intend to replace existing data.

### FAQs

<details>

<summary>Can I import screening decisions and tags in the same spreadsheet?</summary>

No. Import screening decisions and tags as separate spreadsheets, and import tag text contents and table contents as separate steps. Download the templates for each from **Nest Settings** → **Import**.

</details>

<details>

<summary>Do imported tags keep their original hierarchy?</summary>

Not automatically. Imported tags arrive without a parent, so the hierarchy from your previous platform doesn't carry over. Assign parents to the newly created tags in [**Configure Tagging**](/review-workflow/tagging/configure-tagging.md) after import.

</details>

<details>

<summary>Which identifier should I use to match records across my import files?</summary>

Use whichever identifier your platform exports consistently: DOI, title, PubMed ID, Ref ID, or External ID. Nested Knowledge matches records, screening decisions, and tags by this identifier, so keep the same one in every file you upload. Rows that don't match return in a spreadsheet for correction and re-upload.

</details>

<details>

<summary>Why can't I import my Meta-Analytical Extraction or Critical Appraisal data?</summary>

Both depend on configuration that lives inside the nest, not in your exported spreadsheet. **Meta-Analytical Extraction** uses the interventions and data elements you configure for the nest, and **Critical Appraisal** uses your chosen appraisal framework. Set these up after migration, then rebuild the extraction and appraisal work using your imported records, decisions, and tags as a starting point.

</details>

<details>

<summary>What does the overwrite setting do, and when should I use it?</summary>

It replaces existing decisions or tags with the data in your import file, and it doesn't generate a change report. Use it only when you intend to replace data already in the nest—for a first migration, leave it off so nothing is overwritten unexpectedly.

</details>

<details>

<summary>My current platform isn't listed here—how do I migrate?</summary>

Most platforms follow the same pattern. Export your references as a RIS or NBIB file, then export a separate spreadsheet with each study's identifier, decision, exclusion reason, and tags. If your platform only offers a reference-manager export, open it in EndNote, Zotero, or Mendeley and export a RIS file from there.

</details>

### Next Steps

Continue migration by importing each layer, then configure the workflows you will use next.

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><i class="fa-file-import">:file-import:</i><br><strong>Import Search Files</strong></td><td>Import records from searches you ran outside Nested Knowledge.</td><td><a href="/review-workflow/literature-search/add-search/import-search-files.md">Import Search Files</a></td></tr><tr><td><i class="fa-sliders">:sliders:</i><br><strong>Configure Screening</strong></td><td>Choose your screening mode before importing decisions.</td><td><a href="/review-workflow/screening/configure-screening.md">Configure Screening</a></td></tr><tr><td><i class="fa-file-circle-check">:file-circle-check:</i><br><strong>Import Screening Decisions</strong></td><td>Import included and excluded decisions from your previous review.</td><td><a href="/review-workflow/screening/import-screening-decisions.md">Import Screening Decisions</a></td></tr><tr><td><i class="fa-file-arrow-up">:file-arrow-up:</i><br><strong>Import Applied Tags</strong></td><td>Import tag data captured outside Nested Knowledge.</td><td><a href="/review-workflow/tagging/import-applied-tags.md">Import Applied Tags</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.nested-knowledge.com/get-started/migrate-to-nk.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
