Case study · An Australian community-care provider (with its Salesforce implementation partner)
Specialist data-migration lead on a community-care provider’s move from NPSP to Nonprofit Cloud: field-level mapping, sandbox rehearsals, then a staged production cutover by staff cohort while services kept running.
Quantified outcomes
The problem
The provider ran its client services — counselling, home visits and aged-care navigation — on Salesforce NPSP, customised over several years with its own objects for enquiries, risk assessments and client check-ins. Nonprofit Cloud changes the underlying data model: people become Person Accounts, and service delivery is tracked through Program Enrollments and Benefit Disbursements rather than tasks. The Salesforce partner running the implementation needed a specialist to own the data side of the move — map every field, carry years of client history across without losing context, and do it without stopping frontline staff from working.
The approach
A two-week analysis came first: a field-by-field audit of the NPSP objects (the Contact object alone had 314 fields, split across standard, NPSP-package and custom) and a mapping workbook to the Nonprofit Cloud model that the partner could take straight to the client. Every load was then rehearsed in a partial-copy sandbox and validated against source counts before anything touched production. The production cutover ran in a fixed order — organisations first, then people, cases, enquiries, relationships and tasks — with a check-in and sign-off between each step. Staff moved across in cohorts; after each cohort went live, delta loads brought over whatever had been created in the old system in the meantime (the second delta alone was around 3,500 records: client sessions, tasks, documents, check-ins and new risk assessments).
The outcome
All staff cohorts are now working in Nonprofit Cloud, with the final team — aged-care navigation — brought across with a last delta load in September 2026. Every load was reconciled against the source file before sign-off, and nothing was deleted from the old model until it had been archived. Issues raised by staff after go-live — task visibility, record-page layouts, emergency-contact details that had lived in a legacy field — were fixed through the same channel as the migration, usually the same day. The engagement ran on a transparent timesheet: 149 hours to the end of the initial production migration, split between discovery, mapping and QA (94 hours) and production loads (55 hours).
Stack used
Similar situation?
30 minutes, conversational, no commitment. We’ll come ready with questions specific to your industry and situation.