A new donation platform should change how you raise money, not just how you take it

Most nonprofits treat a donation platform switch as two jobs: build new forms, and point them at a new payment processor. Both matter, and neither is the reason to switch. The switches that pay off plan two things before anyone signs a contract: how the data moves without breaking, and what the organization will do differently with donors once it lands.

This guide covers both. It draws on donation platform go-lives we have run on HubSpot, and on a workshop we lead for nonprofit operators on replacing patchwork systems. If you are moving to Fundraise Up specifically, our Fundraise Up and HubSpot guide goes deeper on the integration decisions.

They treat it as a software swap instead of a change to how the organization raises and records money. The decisions about which system owns a gift, which one sends the receipt, and who looks after the setup still get made. They just get made by default, and the cost shows up after launch.

The patterns repeat:

Treating the platform as a payment processor. A card that clears is not a complete gift. The gift still needs a donor, a designation, a receipt, a recurring status and a place in the deposit it arrived in. And if the only thing that changes is where cards get processed, most of what you paid for sits unused.

Switching on the sync before deciding what owns the gift. The connection takes minutes, so it tends to happen first. Gifts start landing in the CRM before anyone has decided whether the CRM or accounting holds the record of truth, and within weeks the two disagree.

Letting two systems create gifts during the cutover. When the old platform and the new one both feed the CRM, even for a few weeks, duplicate gifts follow.

Configuring giving around the platform instead of the donor. A recurring-only form, a missing one-time option, or a fee-coverage setting finance never agreed to will quietly turn away gifts or break reconciliation.

Two systems sending receipts. If both the platform and the CRM are switched on to send them, donors get two, and one of them is usually wrong.

Testing only the successful donation. A $50 card gift that goes through proves very little. The failures are where launches break.

Launching in the busiest season. A small configuration error in March is a fix. The same error in the last week of December is lost revenue.

No owner after launch. A platform nobody is responsible for drifts. Forms multiply, designations get added one at a time, and matching rules go stale.

The rest of this guide is how to avoid each of these.

Pick one process that crosses more than one system or more than one person, and draw every handoff in it. The map shows you where a new platform will help and where it will not, before a vendor tells you.

Good processes to start with: a gift to its thank-you, a member to their renewal, an event ticket to the follow-up. Draw every system and every person as a box, and every handoff as an arrow. Then mark each arrow: done by hand, retyped from somewhere else, or the place where things get lost. Ask one question of every box: who owns this step?

Here is what one map looked like. A customer spends $1,000 at an organization's retail operation. The point-of-sale system records the sale. It emails the receipt. The totals reach the accounting system. And nobody in fundraising ever knows. Five boxes, four handoffs, and the person most likely to become a major donor never reaches the people whose job it is to ask. Nothing in that chain was broken. Every system did exactly what it was bought to do.

That is the value of the map. A platform demo shows you the form. The map shows you the handoffs, and the handoffs are where money and relationships leak.

Once you have the map, sort every problem on it into one of four kinds. A new platform solves one of them. Migrate without sorting the other three, and you pay to make your existing problems faster.

Technology: the systems genuinely cannot talk to each other. This is the one a new platform can fix.

Data: the records are wrong, duplicated or ambiguous. A new platform imports all of it faithfully.

Process: the workflow was never designed. It accreted, and it lives differently in three people's heads.

Ownership: nobody owns the record, the decision or the definition.

In most rooms we work with, technology is the smallest pile. Data is usually the largest, and the most underestimated. One organization we are working with now was sure its records were clean. After deduplication, 58,000 records became 36,000. That is the number to remember when someone tells you their data is fine.

If the only thing that changes is where the card gets processed, you paid for a migration and got a gateway. Decide before you sign what the new platform should let you do differently with donors, and plan for it as an organization, not as a fundraising project.

Platforms differ, so treat these as questions to put to any platform you evaluate, and to your own team:

Mobile giving. How does a gift work on a phone, start to finish? Can someone give in the time it takes to read a text?

More interactive giving pages. Can a page show progress toward a goal, let donors choose where their gift goes, or change what it asks based on who is giving?

Tribute and gift donations. Can a donor give in honor or memory of someone, or give a membership as a gift, and can both the giver and the recipient stay reachable afterward?

Matching gifts. Does the platform help donors find out whether their employer matches, and does anyone on your team follow up to claim it?

Recurring upgrades. Does the platform make monthly giving the easy choice, and can you ask existing monthly donors to increase?

Peer-to-peer and events. Can supporters raise money on your behalf, and can an event, a broadcast or an in-person ask run on the same platform as your everyday giving?

One record across online and offline giving. Do online gifts land next to checks, events and in-person gifts, so you see the whole donor?

None of those happen because a feature exists. They happen because someone owns them. So make it a whole-of-organization decision: ask development, marketing, events, finance and programs to each name one thing they will do differently once the platform is live. Then phase it. Go live with a core set that works, and put the rest on a schedule so it does not quietly slide into never.

This is where a switch pays for itself. Pinky Swear Foundation consolidated several giving tools, including text-to-give and peer-to-peer, into one platform on HubSpot. Recurring giving grew 64% year over year, and their annual Radiothon passed $400k as a hybrid giving experience. The new platform was the start of that. The change in how they asked was the rest.

The same thinking applies to the retail example above. With every transaction on one record, the organization designed a rule that surfaces retail customers who spend $1,000 or more as candidates for its annual giving society. That list was impossible to build before. It is designed, not yet running, and it is the kind of thing a switch should make possible.

Give every job one owner before the first gift arrives: the gift record, the tax receipt, the thank-you, the designation list and the recurring status. Two owners for any of them is how duplicates and wrong receipts start.

In most cases your accounting system stays authoritative for gift data, and the CRM receives gifts for visibility and segmentation without staff editing them there. One system sends the tax receipt. The thank-you can come from somewhere else, but decide where. The designation list is governed in one place, so the platform, the CRM and the ledger use the same codes. And recurring status lives somewhere structured, so a lapsed monthly donor shows as lapsed.

If you are on HubSpot, our Fundraise Up and HubSpot guide walks through each of these decisions in order.

Migrating a donor's record is not the same as migrating their recurring gift. Your monthly donors are your most valuable and most fragile segment in a switch, so plan them as their own project.

Whether donors have to re-enter their cards depends on the payment processor you are leaving, not the platform you are moving to. When we move donors to Fundraise Up, which runs on Stripe, we work to migrate their saved payment tokens so the switch is as painless as possible for them. Whether those tokens can move at all is entirely up to the processor you are coming from. Ask that question first, before the timeline is set, because the answer decides how much your donors will have to do.

Either way, tell recurring donors that something is changing. If nothing is needed from them, say so. If they will need to confirm or update their payment details, say that clearly and early. Transparency is always the better option.

Whatever the mechanics, three checks apply. Before cutover, list every active plan with its amount, frequency and next charge date. After cutover, count them again and reconcile the two lists line by line. And watch the first full billing cycle closely, because that is when a plan that did not move shows up as a gift that did not arrive.

Before launch, run one test gift all the way through the organization, then test the failures. The question is not whether the platform accepts donations. It is whether the organization can account for and act on every one after it does.

The full path: the donor gives, the gift succeeds, the receipt arrives, the donor record updates, the campaign and source are captured, the gift reaches accounting, the payout reconciles to the bank deposit, and the reports reflect it. If the gift is recurring, the next renewal works too.

Then break it on purpose. A declined card. A refund. A recurring renewal. A duplicate submission. A gift eligible for an employer match. A donor with no email address. A gift split across two designations. Each one should land where you expect, with the receipt you expect, or you have found a problem before a donor does.

Do not go live in the weeks before Giving Tuesday, year-end, a major appeal or your largest event. Launch when a mistake is a fix, not lost revenue, and leave room to run the old and new setups side by side for a short, defined period.

Most switches have a forcing function, and it is usually a contract end date. One organization we are working with learned its donor platform contract was ending with six months of runway. That is enough time, if the clock starts on day one and the launch date is set around the fundraising calendar rather than the contract.

Staff adopt a new platform when it matches how they actually work. Have them describe the work instead of the old tool, give the project four named roles, and keep everyone holding the same picture in writing.

Take the technology out of it. Staff will describe their requirements as whatever the old system did. Ask them to describe the work instead: how a gift comes in, who touches it, and what has to happen next. Then build the tool around that. It is the biggest staff buy-in lesson we have.

Name four roles. Someone in the weeds every day. A strategist. A bridge to the rest of staff. An executive sponsor. If you cannot name all four today, that is the first gap to close.

Prioritize ruthlessly. Decide what has to work on day one, usually gift processing, receipts and reporting, and let everything else wait its turn.

Write a weekly summary. Staff, board and leadership should be holding the same picture. When the timeline moves, say so, and say why.

If any of these are true, fix them before you sign. None of them are software problems, and any of them will sink a software project.

1. No internal owner.
2. Nobody who can explain how the work actually happens today.
3. Expecting the vendor to make your decisions.
4. No capacity during your busy season.
5. No final decision maker.

Measure two things after launch: whether the switch worked, and whether the platform is being used. Most teams only measure the first.

Did the switch work? Gift volume against the same period last year. Recurring donor retention through the first full billing cycle. The duplicate rate in new records. Receipt errors and donor complaints.

Is the platform being used? The share of gifts made on a phone. Matching gifts identified and claimed. Recurring upgrades. And progress on the list each team made in the planning stage: which of those new things are live, and which are still waiting.

If the second set is flat after 90 days, you have a new gateway. That is fixable, but only if someone is looking.

If you are moving to Fundraise Up on HubSpot, start with how the integration works and the decisions it leaves to you. And if you would rather have it built right the first time, see our Fundraise Up implementation for nonprofits.