The mid-market nonprofit migration done local-first. Bloomerang's flat donor model walked into NPSP's household + soft-credit + recurring-plan graph, with pre-flight gates and a signed chain so the auditor doesn't need to take anyone's word for it.
Bloomerang is a flat, donor-centric model. NPSP is a household graph with Opportunities, OCRs, Recurring Donation plans, Allocations, and General Accounting Units that all reference each other. Five places the move quietly breaks:
npe03__Recurring_Donation__c with child Opportunity rows on a schedule. Half of "missing donations" complaints post-migration trace to this single mis-mapping.Same five gates as every CDM migration, with Bloomerang-specific rules wired in:
UPPER($Fund) doesn't compile.schema_snapshot rows. The detector classifies diffs as info / warn / block. Block halts migration approval, a custom Bloomerang field added Friday doesn't quietly truncate Monday's load.Your migration runs on the laptop of the person doing the work. The Keychain ACL boundary holds the credentials. Your donor PII never touches our infrastructure. The vendor, including us, isn't in the chain of custody.
Start with a 30-minute discovery call. You describe the move, I ask questions, we determine fit. Project-based engagement, scope determines pricing.