Replacing Constituent IDs When Switching CRMs

Overview

When your institution migrates to a new CRM, the constituent IDs in GiveCampus remain linked to your previous system. Simply importing new IDs on top of existing records creates duplicate constituent records. This article explains the correct process for replacing constituent IDs during a CRM transition.

Why the Constituent ID Backfill Tool is not Suitable

The Constituent ID Backfill Tool links past gift records to constituent IDs by matching on email address. It works on a separate email-to-ID mapping table and does not update the constituent record directly. This makes it unsuitable for a CRM migration because:

• It updates gift-to-ID links, not the constituent record. The tool maps email addresses to external IDs to associate gifts, but it does not replace the constituent ID on the record.
• Email matching is unreliable. Multiple emails or shared email addresses can cause incorrect matching.

The Correct Approach: Constituent ID Replacement

Replace constituent IDs with a direct ID-to-ID swap using a two-column CSV file. This approach does not rely on email matching and preserves all associated giving history.

What the replacement does

• Replaces the old constituent ID with the new one in constituent records, relationships, and gift history.
• Maintains all giving history linked to each constituent.
• Avoids data loss that would occur if constituent records were deleted and reimported.

Validation before applying changes

Before the swap, the system validates your CSV file. It will:

• Reject the file if any new constituent ID appears more than once.
• Abort the process if the mapping would result in duplicate IDs in GiveCampus.

No changes are made until the file passes all validation checks.

Preparing Your File

Create a CSV file with exactly two columns:

Include one row per constituent whose ID is changing. Do not repeat any constituent or new IDs within the file.

Include only constituencies already in GiveCampus. Cross-reference your CRM data with your existing GiveCampus records to identify overlapping entries. This focused list speeds up processing and yields more accurate validation results.

Step-by-Step Process

1. Prepare your CSV. Create a two-column file of old-to-new constituent ID mappings.
2. Submit the file to GiveCampus. This process must be performed by GiveCampus staff. Send your CSV to your GiveCampus contact to begin the procedure.
3. The system validates and executes the swap. GiveCampus verifies the file and replaces all old IDs with the new IDs across constituent records, relationships, and gift history if validation is successful.
4. Update your Data Importer configuration. After the swap, adjust your Data Importer to map the constituent ID column from your new CRM's file to the Constituents ID field in GiveCampus.
5. Upload your updated constituent file. Complete the migration by importing the full constituent file with new IDs.

Frequently Asked Questions

Will giving history be lost? No. The swap is performed in place, so all giving history remains attached to each record.

What if I delete and reimport constituent records instead? Deleting and reimporting results in the permanent loss of giving history. The replacement process is preferred to maintain data integrity.

What happens if the file fails validation? No changes are made. Correct the file errors (such as duplicate new IDs) and resubmit.

Does this work if constituents share an email address? Yes. The process matches on constituent ID rather than email address, so shared emails do not affect the outcome.

FAQ — Should our swap CSV include our entire CRM export, or only the constituents already in GiveCampus?

• Short answer: Include only the constituents already in GiveCampus. Create a focused two-column CSV (old-ID → new-ID) that lists only the records in the system. This ensures faster processing and more targeted error reports.

• Why this matters: A full CRM export may include many records not in GiveCampus. Using a trimmed list reduces processing time, minimizes validation errors, and highlights issues with existing records.

• Who runs the swap: GiveCampus staff perform the swap. Send your prepared CSV to your GiveCampus contact for the in-place replacement of constituent IDs.

• File rules and validation checks:

  • Each new constituent ID must appear only once. The system checks for duplicate new IDs at upload and again before applying changes.
  • The system verifies that the mappings do not result in duplicate IDs among existing constituents. If duplicates are found, no changes are made until the file is corrected.

• What the process matches on: The swap uses constituent IDs exclusively. Issues like shared or multiple emails do not affect the operation.

• After the swap: Update your Data Importer mapping. Point it to your new CRM’s constituent ID column and map it to the GiveCampus Constituent ID field before running your first full import using the new IDs.

• How to identify which constituents are already in GiveCampus: Export your current constituent IDs from GiveCampus to create an accurate list. Use this list to build your focused CSV, including only matching records.

• Practical checklist before submitting your swap CSV:

  1. Export your current GiveCampus constituent IDs to determine which records exist.
  2. Create a two-column CSV with old_constituent_id and new_constituent_id for only those constituents.
  3. Check that each new ID appears only once, removing any duplicates.
  4. Send the CSV to your GiveCampus contact to initiate the replacement process.
  5. After confirmation from GiveCampus, update your Data Importer and perform your first full import with the new IDs.