Choosing a Nonprofit CMS for Donor Engagement: A 9-Step Guide

Sasha Shevelev
Sasha Shevelev 21 October 2026

Here's a question worth asking before you book a single demo: who's going to change the donation form at four o'clock on the last Thursday of June? Not in theory. By name.

It's easy to choose a CMS the wrong way round: platforms first, a polished demo, and only later the discovery that the donation form lives in another system and the person who'll edit the site was never in the room.

This guide is a process, not a shortlist. Nine steps a small not-for-profit team can run over a few weeks, which is how you answer "what's the best CMS for a not-for-profit?" for your own organisation. (My honest answer is "it depends", which I know is irritating. The steps are how you find out what it depends on.)

Key Takeaways

  • Map the supporter journey before you look at a platform. Every handover to your CRM, payment gateway or email tool is where a gift or consent flag can go missing.
  • Plenty of "CMS problems" are CRM or donation-platform jobs in disguise.
  • Your editors drive the demos. Not the vendor.
  • Cost it over five years, including the edits you'll be paying someone else to make.
  • Small site, embedded donation form, no logins? You might not need a CMS project at all, and that's fine.

Before You Start: Four People and a Notebook

Four people's plenty: someone from fundraising, someone who actually edits the site, whoever owns the CRM, and one person who can sign off the budget. One of them keeps the notes; step nine needs them.

Then pick a realistic decision date. Say your communications lead is also running the end of financial year appeal. Book demos into that fortnight and you'll be deciding on half-watched presentations.

Step 1: Map the Supporter Journey

Start with people, not platforms.

List every way someone becomes or stays a supporter: a first gift, regular giving, volunteering, membership, events, bequest enquiries. Write the steps each one takes on your website. Sticky notes or a spreadsheet, I don't mind which.

Then mark every handover to another system, noting what moves, who owns the receiving system and what happens when it fails. That last column's tempting to leave blank. Don't.

If nobody can say where a regular giving sign-up ends up, stop. That isn't a CMS problem yet. It will be.

The Tresillian site, built on Umbraco for a not-for-profit that supports new parents, combines a Google Maps centre finder, events and ecommerce. Three journeys, one site. That's what your map should surface.

Step 2: Who Actually Edits the Site?

Not who's supposed to. Who does.

List every person, their weekly hours on it, and how confident they are. Imagine the honest version: a part-time communications coordinator, two volunteers who help out on Tuesdays, and a developer you ring when something breaks. Nothing wrong with that. Pretending it's a three-person digital team is the problem.

Then list the ten most common edits from the past few months. (I'd bet on the homepage banner topping it.) Circle the ones that need a developer. They're your most expensive edits, and you'll need the list again in steps five and seven.

Step 3: Split the Requirements, Then Split Them Again

This step is tedious, and it's the one people skip. It's also where the money gets saved.

Sort everything into must, should and could. Then, and this is the bit that matters, decide which system each item belongs to: the CMS, the CRM, the donation platform or the email platform. "Donors can update their direct debit details" is usually a donation-platform or CRM job. "Fundraising can build a campaign landing page without a developer" is a CMS job. My view is that your website CMS should do the jobs a website CMS is good at and stop there.

Some requirements genuinely cross the line. The St Vincent de Paul Member and Volunteers Hub keeps member details in a custom CRM with an integrated user database for login, then shows personalised news and events based on each profile. Decide which system owns which part before anyone quotes, or you'll get three quotes for three different projects.

And keep the must list short. If everything's a must, nothing is.

Step 4: Shortlist on Evidence

Feature lists are marketing. Case studies and live sites are evidence.

Aim for three or four options, each a platform plus the partner who'd build it, with work that resembles your map. Then look at how each partner starts a project. The JMC Academy project began with deep UX discovery (surveys, interviews, user testing and user journeys), and MA Financial Group started with UX discovery workshops. A partner who wants to skip straight to the visual design is telling you something, and it isn't good.

If licence fees worry you, put an open-source option on the list. Umbraco CMS is MIT-licensed with no licence fee, and JMC Academy moved from a costly CMS onto free, open-source software with significant savings.

Step 5: Your Editors Drive the Demos

If you only keep one step, keep this one.

Give every shortlisted vendor the same five scenarios, using your content:

  1. Publish a new appeal page with an image, a story and a donate button.
  2. Change a donation form, such as the suggested amounts or a new field.
  3. Add an event with a date, location and registration link.
  4. Build a landing page for a campaign from existing components.
  5. Replace a policy PDF and check the old link still works.

Your actual editors sit at the keyboard. Not the vendor's trainer, not your most technical staff member, and definitely not the CEO. The vendor talks; they don't touch the mouse. Time every task and note where people hesitate. I'd treat each hesitation as a preview of a phone call you'll be making later.

Be wary of a vendor who insists on driving, or a donation form change that somehow becomes "we'd raise a ticket for that". The outcome you're testing for is the one described in the UTS College case study, where the site was configured for non-developer editing and, once the team was trained, Webcoda barely heard from them.

Step 6: Make a Test Gift. Then Break It.

Ask each finalist for a sandbox, make one test donation, and open the CRM record. Right contact? Right amount, right campaign code? Did the consent flags arrive the way the supporter set them? Did a receipt go out?

Then try to break it. Use an email address that's already in the CRM. Use a declined card. Ask who's alerted when the sync fails. If it's "nobody, until a donor rings up", you've learned more than the whole demo told you.

If the integration is the riskiest part, there's a good argument for doing it first. Sydney Zoo was migrated in phases, integration first while the old site stayed live, with its ticketing linked through to HubSpot CRM. Our systems integration page covers how we connect websites to CRMs and payment gateways.

Step 7: Cost It Over Five Years

Licence fees are the easy bit, and they're rarely the whole story. Add hosting, partner retainers or support arrangements (ask every partner exactly what happens after launch), training for new staff each year, and keeping the step-six integrations healthy.

Then the line that's easiest to miss: the developer-only edits from step two, multiplied by how often they happen in a year. A small bill, every time, for five years. Staff time counts too. The Metropolitan Memorial Parks site uses marketing automation for event registrations and CRM integration, and its case study reports a 30% decrease in administrative tasks. Admin hours are a real cost, even when they never turn up on an invoice.

Step 8: Accessibility and Governance

Short step. Big consequences.

Write WCAG 2.2 Level AA into the scope, as that is the minimum recommended in the Australian Human Rights Commission's 2025 guidelines on equal access to digital goods and services, and confirm which version each vendor is quoting against, because older documents still cite 2.1. Under the Disability Discrimination Act 1992, a contract with a supplier does not transfer your organisation's duty to provide an accessible service.

Ask how editors will be trained, because a site can launch accessible and drift the day someone uploads a scanned PDF. Ask about approval workflows. Who can publish an appeal page? Who signs off a policy change? And if a vendor calls their product "compliant" without naming a version, they haven't answered the question.

Step 9: Score It, and Write Down Why

Turn the must list into four or five weighted categories: say, editing ease, data flow, five-year cost, accessibility and governance, and partner fit. Score each finalist from your step five and six notes. Not from memory. (Memories of a good presenter don't fade nearly fast enough.)

Then write one page: what you chose, what you rejected, and why. It feels like bureaucracy. It isn't. When the people who ran the selection move on, that page is what stops the next team reopening the whole decision.

When You Don't Need a CMS Project at All

Sometimes step three hands you a short, anticlimactic list. A few dozen pages. One or two editors. No logins. A donation platform with an embedded form that already handles receipts and CRM sync.

If that's you, a bigger CMS won't raise more money, and I'd say so even though we build them. Spend on the donation experience and editor training, and come back to this process when you add logins, membership or personalisation. I don't think anyone gets this decision perfectly right. Teams change and maps go stale, which is why the written reasoning matters more than the scorecard.

Where Webcoda Fits

Webcoda has worked with not-for-profits including Tresillian, St Vincent de Paul, CMRI and Jeans for Genes. We're an Umbraco Gold Partner, a Gold partner for Xperience by Kentico and a HubSpot Solutions Partner, which matters at step four: a CMS developer in Sydney that builds on more than one platform can recommend the one that fits your map. Our CMS page covers how we approach selection, and on Umbraco we offer structured, low-risk migrations that preserve your content, SEO value, and editorial workflows.

Frequently Asked Questions

There isn't one best CMS for every not-for-profit. The right choice depends on your supporter journeys, who edits the site and which jobs belong to your CRM and donation platform instead. Mapping those first, then running scripted demos with your own editors, gives you an answer you can defend.

For most small teams, a few weeks is realistic if you run the steps in order and keep the working group small. Plan around your appeal calendar so demos and sandbox testing don't collide with your busiest fundraising period.

Usually a separate donation platform, connected to your CRM. The CMS presents the appeal and hosts or embeds the form, while payments, receipts and recurring gift management sit with systems built for them. Test the full flow from form to CRM record before you sign.

The same handful of real tasks for every vendor, using your own content: publishing an appeal page, changing a donation form, adding an event, building a campaign landing page and replacing a policy PDF. Your editors should do the tasks themselves while you time them.

Often not. If you have a small site, one or two editors, no member or volunteer logins and an embedded donation form that already syncs to your CRM, investing in the donation experience and editor training is likely to do more than a new platform.

Talk to Webcoda

Webcoda is a Sydney-based, B Corp certified digital agency that has been building websites and enterprise web applications since 2005, for organisations including Sony, BridgeClimb, the Australian Federal Government and NSW Health. We are an Umbraco Gold Partner, a Gold partner for Xperience by Kentico and a HubSpot Solutions Partner, so platform advice comes without a single-vendor agenda.

Get in touch to talk through your project, or browse our full range of services and platforms.