Moving from Salesforce NPSP to a Microsoft-Based CRM: What to Keep, What to Leave Behind
Why this decision is showing up now
For many nonprofits, NPSP has been the familiar home for donor management. Salesforce has also introduced Nonprofit Cloud as the newer nonprofit solution path, and there are official guides to help plan that move.
At the same time, more nonprofits are evaluating Microsoft-based CRM architectures because they want:
- simpler day-to-day operations
- reporting that is easier to trust
- workflows that feel less like “CRM maintenance” and more like “fundraising execution”
If you’re moving from NPSP into a Microsoft-based CRM environment, the biggest question is not “How do we migrate?”
It’s “What should we bring with us?”
The “Keep, Leave, Rebuild” framework
Use this framework to avoid recreating the old system in a new tool.
Keep: the data that drives decisions
Bring forward the data you actually use:
- Constituent core fields you rely on
- Giving history needed for reporting and segmentation
- Relationships that affect stewardship
- Current pipelines and active tasks
Be careful with fields that exist only because “we might use them.” They become clutter fast.
Leave behind: clutter disguised as comfort
Most nonprofits carry data baggage like:
- duplicate records with conflicting truth
- legacy custom fields created for one campaign years ago
- half-used automations that nobody trusts
- report filters that only one person understands
This is the perfect time to retire them.
If you want a system that people adopt, reduce the number of ways the system can be wrong.
Rebuild: workflows that should be simpler
This is where Microsoft-based CRM shines, because you can design processes on a modern platform and build around nonprofit scenarios (fundraising, program delivery, and more).
Instead of migrating old workflow logic, rebuild the routines:
- major gift pipeline stages with clear next steps
- renewals with reminders and accountability
- stewardship touches with a standard cadence
- gift processing with fewer “side spreadsheets”
Your goal is not to preserve complexity. Your goal is to preserve outcomes.
Five migration decisions that prevent pain later
1) Decide your constituent model early
Households, relationships, and giving attribution can be modeled in different ways. Decide it before migration work begins, or you will redo reporting later.
2) Agree on definitions
Donor, lapsed, retained, pipeline, pledge, soft credit. Define them once, publish them, train them.
3) Rationalize custom fields
Create a simple policy:
- Keep it if it supports a current workflow or board report
- Archive it if it does not
4) Treat deduplication like a governance project
Deduping is not a one-time clean. It’s a new set of rules and owners.
5) Plan reporting as a deliverable, not an afterthought
If you wait until after go-live to rebuild reporting, the team loses confidence. Build board-ready reporting early, even if it is version 1.
“But we’ll lose history”
This fear is common and valid.
The answer is not “migrate everything.” The answer is:
- migrate operational and reporting history
- archive what is legally needed but rarely used
- document how to access archived history if needed
This keeps the CRM usable while protecting institutional memory.
Closing thought
A platform move is a rare chance to simplify.
Salesforce provides guidance for moving from NPSP to Nonprofit Cloud.
If you are choosing a Microsoft-based CRM direction instead, you still need the same kind of discipline: clear definitions, clean data, and workflows designed for how your team actually works.
