Migration guide

Moving to DonorIntel is a chance to clean up decades of inherited codes, duplicate donors, and ambiguous gift types—but only if you treat migration as a data governance project, not a one-night import. This guide outlines phases: inventory, mapping, pilot loads, validation, and cutover, with pointers to tenant settings, custom fields, and access control you will touch along the way.

Database administrators and advancement leadership should read it together so scope, timeline, and “good enough for launch” are aligned before anyone touches production.

Overview

Begin with a source-of-truth audit: which system owns active pledges, which owns historical gifts, and where soft credits actually live. Map those entities to DonorIntel’s core model, then define custom fields only for attributes that cannot be expressed cleanly in standard columns.

Use incremental loads with reconciliation reports; never assume a single pass will deduplicate relationships or honor restricted balances. After data lands, validate with finance and frontline fundraisers, then freeze legacy entry points so you do not silently fork reality. Detailed field-by-field mappings will live in appendices as we publish importer templates and API recipes.