Fundraising Vendor Selection, Contracts and SLA Playbook

Most nonprofit vendor problems don't show up during the demo. They show up eighteen months later, when you're trying to leave.

The CRM that promised "easy exports" turns out to export everything except the custom fields your major-gifts team spent three years building. The email platform that integrated beautifully now charges a "data migration fee" to hand back your own contact history. The payment processor holds your reconciliation data in a format that only makes sense inside their dashboard. None of this was hidden. It was all sitting in the contract nobody read closely because the thing everyone was actually evaluating was the feature list.

The contract is the product. The features are just what you see first. And for nonprofits — where switching costs come straight out of program budgets and a botched migration can corrupt donor history you legally need to keep — the clauses buried in the MSA matter more than the UI everyone argued about in the selection meeting.

This is a playbook for the part most teams skip: how to evaluate vendors through their contracts, which clauses are non-negotiable, how your leverage changes depending on org size, and how to score vendor risk before you sign instead of after you're stuck.

Why fundraising vendor selection breaks differently for nonprofits

A for-profit company switching vendors eats a one-time cost and moves on. A nonprofit switching vendors risks three things at once: donor data integrity, grant and audit compliance, and the trust of people who gave money partly because they believed you'd handle their information responsibly.

That changes the math. The feature comparison spreadsheet everyone builds — rows of checkmarks across four vendors — is answering the wrong question. It tells you what the tool does today. It tells you nothing about what happens when:

1. 1
   The vendor gets acquired and sunsets the product line you depend on
2. 2
   Their pricing jumps 40% at renewal because you're now locked in
3. 3
   They have a breach and you find out your contract puts the notification burden on you
4. 4
   You outgrow them and discover your three years of donor behavior data can't come with you

Vendors with the slickest sales process often have the weakest exit terms. That's not a coincidence. A frictionless entrance and a painful exit is a retention strategy. The contract is where that strategy lives.

So before any feature conversation, the real question is: if this relationship goes badly, how bad can it get, and how fast can we leave?

The three clauses that matter more than everything else

There are dozens of clauses in a vendor agreement. Most are boilerplate. Three are not — and these are the ones small nonprofits consistently fail to negotiate because they don't realize they're on the table.

1. Data portability (your data has to be genuinely yours)

"You own your data" is in nearly every contract. It's also nearly meaningless on its own. Owning data you can't extract in a usable format is like owning a car with no keys.

1. 1
   Format

   Exports in open, documented formats (CSV, JSON, SQL dump) — not a proprietary archive you can only re-import into the same vendor.

2. 2
   Completeness

   All data, including custom fields, tags, attachments, interaction history, soft-credit relationships, and audit logs — not just the "core contact record."

3. 3
   Timing and cost

   On-demand self-service export at no charge, available during the contract and for a defined window after termination.

A typical failure: a mid-size nonprofit exports their donor list when leaving a platform, gets a clean 40,000-row CSV, and feels fine — until they realize the recurring-gift schedules, the campaign source codes, and the relationship links between households all lived in structures that didn't export. The data is technically there. The meaning is gone.

“

Run a full export test annually and verify reconstructability during a low-risk period.

Sample clause language:

> Customer may export all Customer Data at any time during the Term and for a period of ninety (90) days following termination, at no additional cost, in a structured, machine-readable, and documented format (including but not limited to CSV and JSON). "Customer Data" includes all records, custom fields, tags, attachments, interaction and communication history, relationship associations, recurring transaction schedules, and system audit logs. Vendor shall provide a documented data schema upon request.

2. Incident response (who does what, and how fast, when there's a breach)

Most nonprofit vendor contracts handle security incidents with vague language about "commercially reasonable efforts" and notification "without undue delay." That phrasing protects the vendor, not you. When something goes wrong with donor PII, you're the one who has to notify donors, possibly regulators, and your board.

1. 1
   A notification deadline measured in hours, not "promptly" (72 hours is a reasonable floor; 48 is better).
2. 2
   A defined content requirement for the notice — what was accessed, when, which records, what remediation was taken.
3. 3
   A commitment to cooperate with your own notification obligations, including providing the affected record list.
4. 4
   Clarity on who bears costs of breach response when the vendor is at fault.

3. Termination and export testing (prove the exit works before you need it)

This is the clause almost nobody includes, and it's the one that prevents the worst-case scenario. A termination-and-export clause should give you the right to test your exit on a schedule — not just the theoretical right to leave someday.

The pattern that keeps repeating: an organization has a solid data portability clause, never tests it, and discovers at the worst possible moment — vendor going under, 30-day notice period ticking — that the export is broken, incomplete, or takes two weeks the vendor's support team doesn't have.

A good clause gives you the right to run a full export annually and verify it reconstructs your working data. If it doesn't, that's a contractual defect the vendor has to fix.

This diagram shows the export test and remediation workflow in simple steps.

Sample clause language:

> No more than once per contract year, Customer may request a complete test export of Customer Data to verify completeness and reconstructability. Vendor shall deliver the test export within ten (10) business days. If the export is incomplete or cannot reconstruct Customer's operational records, Vendor shall remediate the deficiency within thirty (30) days at no cost to Customer.

If you take nothing else from this article: a migration you haven't tested is a migration that doesn't exist. This connects directly to how you'd actually execute a move — the pre-migration audits and rollback criteria covered in our platform migration playbook assume you can get clean data out in the first place, and these clauses are what make that possible.

Negotiation priorities change with your org size

The single biggest mistake small nonprofits make is negotiating like a large one — spending leverage they don't have on terms that don't matter at their scale. Your size determines both how much you can push and what's actually worth pushing on.

If you're a small team (under ~$500K)

You'll mostly be on the vendor's standard terms, and that's okay — pick the battles that cost nothing to lose. Two things to never accept: an auto-renewal clause without a reasonable opt-out window, and any early-termination penalty. Also scrutinize per-record or per-contact pricing. It feels cheap at 5,000 donors and becomes a trap at 25,000.

You probably can't get custom SLA credits, but you can get the data portability clause confirmed in writing, even if it's just an email from your account rep acknowledging the standard export capability. Save that email.

If you're mid-size (~$500K–$5M)

This is where leverage starts to exist and where most teams leave it on the table. A multi-year commitment is worth real concessions — use it to lock in price caps at renewal (the single most valuable term at this stage) and SLA credits for downtime. Mid-size orgs get burned most often by renewal pricing, not initial pricing. The quote that won the deal was the bait; the renewal is where the vendor recovers margin.

If you're large ($5M+)

Run a real competitive process and push for a custom MSA. The mistake at this level isn't lack of leverage — it's scope creep across bundled products. When one vendor provides your CRM, email, payments, and events, a problem in one product can hold the whole stack hostage. Negotiate severability so you can terminate one module without unwinding everything else.

A vendor-risk scoring template you can actually use

Feature spreadsheets reward whoever wrote the best sales copy. A risk score forces you to evaluate the things that actually determine how the relationship ages. Score each dimension 1–5 (5 = lowest risk), then weight.

The scoring dimensions:

1. 1
   Data portability (weight ×3) — Can you get complete, usable data out, on demand, for free? This gets the heaviest weight because it governs every future decision.
2. 2
   Financial stability (weight ×2) — Is the vendor profitable, well-funded, or at risk of acquisition or shutdown? For a small vendor, ask directly. For a startup, assume acquisition risk.
3. 3
   Security and incident terms (weight ×2) — Concrete notification deadlines, breach cost allocation, relevant certifications (SOC 2, etc.).
4. 4
   Pricing predictability (weight ×2) — Are renewal increases capped? Is pricing per-record (scales against you) or flat?
5. 5
   Integration openness (weight ×1) — Documented, stable API vs. walled garden.
6. 6
   Exit friction (weight ×2) — Termination notice period, penalties, export cost.
7. 7
   Support responsiveness (weight ×1) — Real SLA on response times, or best-effort?

Score every finalist on all seven dimensions, multiply by weights, and total. The reason for weighting portability and exit friction so heavily is straightforward: those are the dimensions you cannot fix later. A weak API you can work around. A locked-in data format you cannot.

One thing worth watching: vendors tend to score high on features and support — the stuff they sell on — and low on portability and exit friction, which is what keeps you captive. If two finalists are close on features but one scores a 4 on exit friction and the other a 2, that gap is worth more than any feature difference.

A quick pre-signature checklist

Before anyone signs, walk through this:

1. 1
   [ ] Can we export all data (including custom fields, history, relationships) ourselves, for free, on demand?
2. 2
   [ ] Is there a post-termination export window of at least 60–90 days?
3. 3
   [ ] Do we have the right to test the export at least annually?
4. 4
   [ ] Is the breach notification deadline defined in hours, not vague language?
5. 5
   [ ] Is renewal pricing capped, or at least bounded to a stated percentage?
6. 6
   [ ] What is the auto-renewal opt-out window, and is it on our calendar?
7. 7
   [ ] Are there early-termination penalties? (If yes, why?)
8. 8
   [ ] Is pricing per-record in a way that punishes growth?
9. 9
   [ ] If this vendor bundles products, can we terminate one module without the others?
10. 10
    [ ] Have we saved written confirmation of key terms from the account rep?

That last box matters more than it looks. Sales reps make verbal promises that don't appear in the contract. Email them a summary — "confirming our understanding that exports are free and self-service" — and keep the reply.

A real scenario

A regional environmental nonprofit, roughly $1.8M annual budget, ran its donor database and email on a single bundled platform for about four years. The initial deal was attractive — somewhere around $14k/year all-in. Nobody on the team had read the auto-renewal or export terms closely.

At the first major renewal, pricing jumped to roughly $23k because their contact count crossed a tier threshold and the intro discount expired. When they looked into switching, two things surfaced: the contract had already auto-renewed with a 60-day opt-out window they'd blown past, and the export didn't include the campaign attribution data their grant reports depended on. Reconstructing that history manually would have taken their two-person ops team weeks.

They stayed another full cycle — not because the platform was good, but because leaving was too expensive. The real cost wasn't the extra $9k per year. It was twelve months locked into a tool they'd already decided to leave.

The following year they did it right: scored three vendors on risk rather than features, negotiated a renewal price cap and a tested export clause into the new contract, and ran a full export test in the first 30 days to confirm everything came out clean. When they eventually consolidated their stack, the migration took days instead of weeks — because the exit was contractually guaranteed and verified before they ever depended on it.

When this level of rigor makes sense — and when it doesn't

When it's worth it: Any vendor holding donor PII, payment data, or records you need for audit and grant compliance. Any contract over roughly $5k/year. Any system that would be painful to leave — which, in practice, is most of your core fundraising stack.

When it's overkill: A $40/month single-purpose tool with trivial data, easy to replace in an afternoon, holding nothing sensitive. Don't negotiate a custom MSA for your survey tool. Apply the risk score, see it comes back low-stakes, and move on.

A note for very small teams: Organizations under ~$500K with no legal support can over-rotate on contract perfectionism and stall decisions for months. If a vendor won't budge on standard terms, the right move is usually to accept the terms and mitigate — calendar the opt-out, test the export yourself, keep your data backed up — rather than burn weeks fighting a contract you can't change.

How this connects to the rest of your operations

Vendor selection isn't a standalone event. The contracts you sign shape every downstream workflow — how data flows between systems, how cleanly you can migrate, how much manual reconciliation your team eats every month. A vendor with a closed API doesn't just annoy your integrations person; it quietly determines how much of your stack has to be stitched together by hand.

This is why vendor evaluation and integration architecture are really the same conversation. The portability and API terms you negotiate directly enable — or block — the kind of clean, documented data flow described in our vendor-neutral integration roadmap. A strong contract makes that architecture possible; a weak one makes it a permanent workaround.

The nonprofits that handle this well treat the contract as an operational document, not a legal formality. They know their opt-out dates. They've tested their exports. They've scored their vendors on the dimensions that age badly. And when a vendor relationship eventually goes sideways — some will — they can actually leave, with their data, their history, and their donor trust intact.

That's the whole point. You're not negotiating against a vendor. You're protecting your future ability to make a different choice.