> For the complete documentation index, see [llms.txt](https://support.pears.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.pears.io/engage/partners/migrate-from-legacy.md).

# Migrate from Partnerships and Coalitions

Bring your legacy Partnership and Coalition records into the Partners module using the export, review, and import process.

The [Partners](/engage/partners.md) module can replace two older modules: [Partnerships](/engage/partnerships.md) and [Coalitions](/engage/coalitions.md). Both keep working, and nothing in them is changed or deleted by this process — but organizations that want their history in one place can bring their legacy records across.

Migration happens in three steps, all driven from the PEARS interface by someone at your organization.

{% stepper %}
{% step %}

#### [Export to Partners](/engage/partners/migrate-from-legacy/export-to-partners.md)

From the Partnerships or Coalitions list, run **Export to Partners**. This produces an Excel workbook with the legacy records already reshaped into the structure Partners expects.
{% endstep %}

{% step %}

#### [Review the Workbook](/engage/partners/migrate-from-legacy/review-the-workbook.md)

Open the workbook in Excel, check the proposed records, and correct anything that needs a human decision.
{% endstep %}

{% step %}

#### [Import the Workbook](/engage/partners/migrate-from-legacy/import-the-workbook.md)

Upload the reviewed workbook through the **Partner Importer**. PEARS creates the Partners, Partner Reports, activities, contacts, and links.
{% endstep %}
{% endstepper %}

The workbook is the handoff point between PEARS and the person doing the migration. Everything PEARS can work out on its own is already filled in; everything that needs judgment is visible in a spreadsheet before any records are created.

## What Changes Structurally

This is the single most important thing to understand before looking at the workbook.

In the legacy modules, a record is tied to a reporting period. If a county worked with the same food pantry for four years, that is four separate Partnership records — each one re-entering the pantry's name, site, type, and collaborators, and each carrying that year's evaluation and accomplishments.

In Partners, the relationship and the reporting are separated:

* A **Partner** is the relationship itself — a name, a type, a site, an owning unit, and a span of time. It has no reporting period.
* A **Partner Report** is one reporting period's account of that relationship — program areas, responsible unit, depth of relationship, assessments, accomplishments, and lessons.

So the migration collapses records: several legacy records become one Partner plus one Partner Report each. Four years of that food pantry partnership become one Partner with four Partner Reports.

| Legacy structure                                          | New structure                                                             |
| --------------------------------------------------------- | ------------------------------------------------------------------------- |
| One Partnership or Coalition record per reporting period  | One Partner, spanning all of them                                         |
| The same name, site, and type re-entered every year       | Recorded once on the Partner                                              |
| Evaluation, accomplishments, program areas on each record | One Partner Report per reporting period                                   |
| Meetings and events on each record                        | Activities on the Partner, selected onto the report they were reported in |
| Collaborators re-added each year                          | One sharing grant per person on the Partner                               |
| Coalition members re-entered each year                    | One CRM contact per member, linked to the Partner                         |

## Before You Begin

### Requirements

* The **Partners** module must be turned on for your organization. Without it, **Export to Partners** does not appear. See [Organization Settings](/administration/administration/organization-settings.md).
* The person running the migration must be an **Organization Administrator** or **Data Manager**.
* The same permission gates both halves — the export and the import — so one person can carry a migration through end to end.

### Plan It as One Coordinated Pass

A migration can reach across every record in the list, not just the ones a given user owns. That is deliberate, and it is why the permission is limited. A few consequences worth planning around:

* **Export the full history in one pass where possible.** A Partner's start and end dates are derived only from the reporting periods included in the export. Exporting one reporting period at a time produces Partners whose date spans cover only that period.
* **The importer never matches against existing records.** Every import creates new Partners. Importing the same workbook twice produces two sets. Import each workbook once, and confirm the result before running another.
* **Tidy the legacy data first if you can.** The migration groups records by name, so a partner entered as "Acme Food Bank" one year and "Acme Foodbank" the next becomes two Partners. Correcting the legacy names before exporting is far easier than merging afterward.

## The Process at a Glance

| Step                  | Where it happens                                                                | What comes out                                                 |
| --------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| 1. Export to Partners | Partnerships list or Coalitions list → **Export** menu                          | An Excel workbook, one sheet per record type                   |
| 2. Review             | Excel, on the reviewer's computer                                               | The same workbook, corrected                                   |
| 3. Import             | Administration (**gear**) menu in the top navigation bar → **Partner Importer** | New Partners, Partner Reports, activities, contacts, and links |

{% hint style="warning" %}
**NOTE:** Steps 1 and 3 are separate exports and imports for the two legacy modules. If your organization uses both Partnerships and Coalitions, run the process twice — once from each list.
{% endhint %}

## Things to Watch For

| Watch for                                               | What happens                                                                        | What to do                                                                 |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| A filtered export                                       | Partner start and end dates only cover the reporting periods included               | Export the full history in one pass, or accept the narrower span knowingly |
| A partner's name typed differently across years         | Two Partners instead of one                                                         | Fix the legacy names and re-export; merging afterward is much harder       |
| A meeting dated outside the period it was reported in   | The activity is created on the Partner but not attached to that report              | Correct the date in the workbook if the attachment matters                 |
| Blank **Depth of relationship**                         | The report imports but cannot be marked complete                                    | Fill it in in the workbook, or leave it for the reporting user to complete |
| Blank assessment **result**, blank **Responsible Unit** | Cell errors; the whole import is rolled back                                        | Fill them in and re-upload the error file                                  |
| Importing the same workbook twice                       | A second, duplicate set of Partners — there is no matching against existing records | Import once; verify before running anything else                           |
| Someone in a different time zone running the export     | Meeting dates and times are converted to that user's time zone                      | Have the export run by someone in your organization's usual time zone      |
| Assuming migration moves the records                    | It does not — the legacy records remain, unchanged, with their files still attached | Decide separately how and when the legacy modules are retired              |

## Reference

* [Mapping Reference](/engage/partners/migrate-from-legacy/mapping-reference.md) — What becomes what, including the per-module differences and what does not carry over.
* [Workbook Columns](/engage/partners/migrate-from-legacy/workbook-columns.md) — Every worksheet and its columns, in order.