Migrate from DonorPerfect

DonorPerfect to Salesforce migration.

DonorPerfect Online (DPO) to NPSP done local-first. Every organization's UDFs are different, every pledge schedule has a quirk, and the migration that lands cleanly is the one where the gates ran before the load did.

Book a discovery call See Migration Services

Why the DonorPerfect → Salesforce migration goes wrong

DonorPerfect's strength is its flexibility. Its migration cost is the same flexibility. Five places it quietly breaks:

User-defined fields (UDFs). Every DonorPerfect org has its own UDF dictionary. Pickliststyle UDFs, free-text UDFs, computed UDFs, and Smart Action triggers. Most off-the-shelf tools stuff them all into a single NPSP Notes field. The history they encode — first-gift vs. mid-major vs. planned-giving signals — vanishes.

Pledge schedules. Multi-year pledges with installment schedules don't have a clean NPSP equivalent. RD2 handles recurring but not pledge-with-balance. Either you build the model as Opportunities-with-Allocations + a custom Pledge object, or balance reports stop working post-migration. The decision has to be made up front, not on the third Tuesday.

Gift codes + solicitation codes. DonorPerfect's Solicit Code, Gift Type, Gift Code, and Sub-Solicit fields don't map 1:1 to NPSP's Campaign + Opportunity Record Type + Type fields. The mapping decides whether year-end mailing-list segmentation still works.

Screen flow customizations. DonorPerfect lets admins reorder fields per screen. The order encodes implicit field importance. NPSP page layouts don't auto-derive that — it needs an admin to re-layout consciously, informed by what the source actually used.

Tribute gifts + acknowledgment templates. Honor and memorial gifts in DPO use the Tribute table + Notification table. NPSP's equivalent (Honoree Contact + Notification Contact on Opportunity) requires deterministic mapping or tribute-letter generation breaks for the first big year-end run.

Pre-flight gates tuned to DonorPerfect

Same five gates as every CDM migration, with DonorPerfect-specific rules wired in:

UDF dictionary capture. Discovery extracts the full UDF dictionary — not just the values — into schema_snapshot. Drift detection on the dictionary means a UDF added Friday doesn't quietly truncate Monday's load.

Transform typechecker. Every UDF mapping, gift code transform, and pledge installment rule passes HM-lite type check. UPPER($Code) doesn't compile; TEXT(InstallmentAmount) with a zero-truncation bug doesn't save.

Deterministic dry-run. Reservoir-sampled real DonorPerfect rows run through every transform. The one pledge with a null first-installment date that takes down the load? You see it before you click run.

Golden datasets. Pin known-good (DPO gift + UDFs, expected NPSP Opportunity + Allocations + custom Pledge fields) tuples. CI for mappings.

Identity scoring. Fellegi-Sunter on constituent duplicates and household assignments. Survivorship rules with the math on the page.

Your migration runs on your hardware. DonorPerfect credentials sit in the macOS Keychain. Donor PII never touches our infrastructure. The vendor — including us — isn't in the chain of custody.

Deliverables

Workspace archive at completion. Your data, packaged. DonorPerfect exports, UDF dictionary capture, gift-code resolutions, every transform mapping, every dry-run trace, every gate decision.

Signed audit chain. Every record movement chained via SHA-256, sealed every 256 leaves with Ed25519. Your auditor verifies the chain on her own laptop. Protocol published →

NPSP-aware mapping. Households, RD2 recurring plans, GAU Allocations, OCRs with soft credit, custom Pledge object where needed — the model your reports can actually consume.

Replay manifest. Every migration is replayable. The compliance-review conversation that used to take six weeks runs in forty minutes.

DonorPerfect to Salesforce migration.

Why the DonorPerfect → Salesforce migration goes wrong

Pre-flight gates tuned to DonorPerfect

Deliverables

Ready to plan the DonorPerfect move?