Ask anyone at a small nonprofit how they ended up on the donor database they use, and you get some version of the same answer: it was already here.
Somebody chose it, once. That person wrote the grant that paid for the first year, or sat on the board in 2019, or was simply the only person on staff who had used anything like it before. Then they left. What stayed behind was a login, an invoice that renews itself every year whether or not anyone looks at it, and a slowly growing pile of things everybody has learned to work around.
That situation produces a very specific complaint, and I hear it constantly: our CRM is terrible. It is almost never a complete sentence.
What “our CRM is terrible” usually means
Three different problems hide inside that phrase, and they need three different fixes. Sorting out which one you have is most of the work.
The first is that nobody was ever really trained on it. The person who chose the system understood it, taught nobody, and left. Everyone since has learned it by watching someone else guess. That isn’t a software problem and no migration will fix it; you’ll simply be untrained on something new, at considerable expense.
The second is that the data going in is bad, so everything coming out is bad, and the software takes the blame for faithfully reporting what it was handed. I’ve written about that one already, you can’t clean your way out of a bad form, and in my experience it’s the most common of the three by a wide margin.
The third is the real one, and it’s the reason evaluations exist. Nobody has ever written down what this organization needs the system to answer. Without that list, no CRM can be judged, because “good” has no definition. You cannot be let down by a tool you never gave a job description to.
What an evaluation actually looks at
A CRM review isn’t a feature comparison. Feature comparisons are free, they’re on every vendor’s website, and they have never once helped a small nonprofit decide anything. What’s useful is a look at your organization, not the market.
- What you pay, against what you use. Not the sticker price: the tier you’re on, versus the tier your actual usage would put you on. Organizations routinely pay for constituent counts and modules they stopped using two years ago and never downgraded.
- How much of the system you touch at all. If your staff uses four screens out of forty, the other thirty-six aren’t value you’re getting. They’re complexity you’re paying to navigate around.
- Where constituent data enters, and whether anything checks it on the way in. Every entry point is a place records get created twice under slightly different names.
- Which reports your board asks for, and which of those actually exist in the system. The gap between those two lists is where somebody’s quarter disappears, rebuilding by hand what the software was supposed to produce.
- What else is holding constituent data. The spreadsheet on the development director’s desktop. The Mailchimp audience. Last year’s event registration platform that nobody cancelled. Then the uncomfortable question: do any of them agree with the CRM, or with each other?
That last one is usually where the room goes quiet, and it’s usually where the money is. A great many “we need a new CRM” conversations turn out to be “we need these four systems to stop disagreeing about who our donors are.”
The arithmetic of switching
If a migration is genuinely the answer, I’ll say so. But it should be said with the real number attached, and the license fee is the smallest part of it.
A migration costs you the data cleanup you were going to have to do anyway, done under deadline. It costs retraining every person who touches the system. It costs a stretch of running both platforms at once, because no one sensible cuts over in a single weekend during appeal season. It costs the year afterward in which every routine task takes twice as long because nobody knows where anything is yet. And it costs whatever history doesn’t survive the move, which is never zero and is often the soft-credit relationships and the notes fields, exactly the institutional memory a small organization can least afford to lose.
None of that argues against switching. It argues against switching for reasons that a week of work and a rebuilt intake form would have solved for a fraction of the cost.
Three honest verdicts
Reviews land in one of three places, and I’d put the odds roughly in this order.
Stay where you are and fix these things. The platform is fine. The intake is leaky, the duplicate rules were never configured, three staff members were never trained, and two of the reports the board wants are twenty minutes of setup away. This is the cheapest outcome by a distance and it is the most common one.
Stay, but consolidate. The CRM is fine; it’s the four other places constituent data lives that are killing you. The work is deciding which system is the source of truth for what, and then making the others follow it instead of quietly competing with it.
Move. Sometimes the fit is genuinely wrong: the platform was built for an organization ten times your size, or a tenth of it, or for a fundamentally different kind of program. When that’s true it’s usually obvious within a day, and the review turns into a migration plan with a real timeline and a real number.
On the two I work in most
I administer both Little Green Light and Bloomerang, and I’ll tell you plainly which way I lean, because a recommendation from someone with no opinion isn’t worth much.
For most of the organizations VCA works with (small staff, no dedicated database person, a few thousand constituents), I reach for Little Green Light first. It asks less of you. A system that does fewer things, in a way a part-time person can hold in their head, beats a more capable system nobody has time to learn. That’s not a knock on capability; it’s a statement about who is actually going to sit down and use the thing on a Tuesday.
Bloomerang is the right answer for plenty of organizations, and I’m comfortable working in it and happy to keep you there. But if you’re choosing from scratch and you’re small, I’d want a specific reason before pointing you at the heavier option, and “it’s the one everybody’s heard of” isn’t one.
Before you hire anyone
You can get a surprisingly long way on your own, and I’d rather you tried. Three questions, in this order.
- What are the five questions your board or your funders ask about your constituents every year? Write them down as questions, not as report names. If your system can’t answer them without someone exporting to Excel first, you’ve found your gap, and you now have the job description the software never got.
- Pull your last invoice and find the tier you’re on. Then find your actual constituent count and your actual active users. If those don’t match, you’ve found money, and you found it without hiring anybody.
- Export the same twenty donors from your CRM and from your email platform. Do the names, addresses and giving histories agree? If they don’t, the problem you’ve been calling a CRM problem lives in the space between your systems, and replacing one of them will not close that space.
A donor CRM is not a decision you get to make once and forget. It’s a piece of infrastructure that quietly stops fitting as an organization changes shape around it. The point of a review isn’t to find something to blame. It’s to give the thing a job description at last, and then find out honestly whether it’s doing the job.