6 min read
Migrating from eTapestry to HubSpot: What Nonprofit Leaders Need to Know Before They Start
eTapestry earned its place. For small and mid-size nonprofits that needed a real donor database without a six-figure...
Updated: June 10, 2026
Intro: the five-minute switch
Connecting Fundraise Up to HubSpot for your nonprofit takes about five minutes. Fundraise Up will tell you the integration is code-free, needs no developer, and is done in a few clicks, and that is true. You authorize the connection, and donations start flowing into HubSpot on their own.
Everything that makes that data useful happens after you flip the switch.
We have implemented this integration across migrations off legacy platforms and inside live fundraising operations, and the pattern is always the same. The connection is the easy part. What flips on is a stream of donation data, and whether that data becomes fundraising intelligence or a reconciliation headache comes down to a handful of architecture decisions that nobody tells you to make. This guide walks through those decisions, in plain language, so you know what good looks like before you turn it on, or so you can fix it if you already have.
A donation platform that syncs to your CRM is not the same as a giving system. The sync gives you data. A system gives you decisions. This guide is about closing that gap.
New to Fundraise Up? See it in action.
What the Fundraise Up and HubSpot integration actually does
Start with the mechanics, because they matter and they are genuinely good.
Fundraise Up was the first online donation platform to natively integrate with HubSpot, and the integration is API-based and real-time. When a supporter gives, their information is sent to HubSpot the moment the donation succeeds. The integration creates a Deal in HubSpot to represent each one-time donation and each installment of a recurring donation, and it places those Deals in a dedicated "Fundraise Up Donations" pipeline that it creates in your account. It matches each donation to an existing Contact based on rules you set (by email, name, address, or phone), or creates a new Contact if it cannot find a match. It also represents recurring giving so it can be tracked over time rather than appearing as a series of disconnected one-time gifts.
Only successful donations sync. The integration can map donation, campaign, designation, recurring, and UTM data to HubSpot fields, including custom properties. And it is free to use; there is no added cost from Fundraise Up for the connection itself.
So far, so good. If all you needed was donations appearing in HubSpot, you would be done.
What it does not do for you
Here is what the documentation does not tell you.
The integration gives you raw donation data in a deals pipeline. It does not decide which system owns your gift records. It does not build the designation structure that lets you report on an appeal. It does not model your memberships, separate your pledges from your paid gifts, dedupe your contacts, or reconcile against your accounting. It hands you the ingredients. The meal is up to you.
Most of the trouble nonprofits run into with Fundraise Up and HubSpot is not the integration failing. It is the integration working exactly as designed, pouring data into a structure that was never set up to receive it. The rest of this guide is the structure.
The decisions that determine success
here are seven decisions to get right, and an eighth that is the payoff. Work through them in order. The last one, reporting, only works if the first six are sound.
1. Source of truth: what owns your gift data
The first question is the one finance teams care about most: when a gift lives in both your accounting system and HubSpot, which one is right?
If you skip this decision, here is what happens. Donations sync into HubSpot automatically. Fundraisers start editing them there. Meanwhile accounting maintains the ledger. Within a month the two disagree, finance loses trust in the numbers, and someone asks to turn the integration off.
The fix is to decide deliberately. In almost every case, your accounting system stays the authoritative source for gift data, and HubSpot receives gifts for fundraising visibility and segmentation, but HubSpot users do not edit gift records. Gifts are something fundraisers see and act on, not something they change. Once you make that call, the sync direction follows from it.
We worked with one foundation that runs its books in Xero and wanted gifts visible in HubSpot so fundraisers could see who gave and to what, without anyone double-entering data or creating discrepancies. The model we landed on: income enters the accounting system (checks, wires, and ACH manually, online gifts via Fundraise Up), and flows to HubSpot for visibility, while the gift record stays owned by accounting. The point of HubSpot here is to give the fundraising team something to act on, not a second place to edit financial records.
There is a quieter problem this decision surfaces, and it is worth naming. On more than one engagement, the real source of truth turned out to be someone's memory. The logic for which gift goes to which fund, which donor gave for what reason, lived in a development director's head. The scariest version of this is the two-week-vacation test: if your key person were out for two weeks, would anyone else know how to code an incoming gift? Part of the value of doing this right is getting that knowledge out of people's heads and into a system.
2. Designation and fund architecture
Fundraise Up sends each gift tagged with campaign and designation IDs. Out of the box, those tend to land as a flat list. A flat list cannot answer the questions that matter: how much did the spring appeal raise, how much went to the building fund, how do we split a gift that supports three things at once.
The answer is a designation hierarchy. Structure your designations so they roll up (for example Campaign to Fund to Appeal to Package, or Event to Sponsorship Tier), and model each gift's allocations as splits underneath it, with each split mapped to where it lands in your ledger. A single $1,000 gift might split across four designations, each a separate allocation tied back to a designation that tells accounting exactly where the money goes.
The flip side is to slim the list where the ledger does not need the detail. We worked with a membership-based organization whose accounting system had exactly one concept of "membership" that posted to a single unrestricted account. There was no reason to carry ten membership designations in HubSpot when the membership detail already lived on the subscription record. We collapsed the designations and let the subscription object hold the nuance, which made both reporting and accounting cleaner.
3. Recurring gifts and memberships
Recurring donations are where the native integration gets thin, and memberships built on recurring giving expose every edge.
The move is to map Fundraise Up recurring plans to HubSpot's subscription object, so you get real lifecycle visibility (active, expired, cancelled) and can automate stewardship around it. For one client, mapping recurring donation data to the subscription object unlocked donor lifecycle automation that simply was not possible before, because the recurring relationship finally lived somewhere structured.
Then there are the edges. Fundraise Up only auto-creates a subscription for gifts that recur on a schedule. If someone pays once but the gift is really a membership, no subscription gets created, and that membership has no clean way to lapse. For a membership-driven client we built a background process that creates the subscription anyway, with a frequency of "once" and an end date, so it correctly shows as expired when the term runs out instead of sitting as "active" forever. We also modeled complimentary and gifted memberships, so a sponsor's gifted memberships attach to the sponsor correctly while the people who received them stay reachable for appeals.
A word of warning here, because we have seen it cost real money. One membership organization had Fundraise Up configured to force recurring-only giving, with no one-time option. They were losing members who wanted to give once and could not. The platform configuration has to match how your supporters actually give. Set it up wrong and it quietly turns away donations.
4. Prospective gifts versus actual gifts
This one corrupts reports silently, so it is worth understanding before it bites you.
Pledges, asks, and verbal commitments live in the same HubSpot gift object as actual donations. If you view them together, a $400,000 pledge plus the $400,000 payment that fulfills it reads as $800,000 raised. Every revenue number that includes both is wrong.
The fix is to separate the sales motion from the record of payment. Prospective gifts (the pledges and asks you are actively working) live in a prospecting pipeline where your team logs activity, moves them through stages like verbal commitment, and sets follow-up tasks. Actual donations are the record of payment, in their own view. The two never sum together. Then you define the reconciliation step: when a pledge is fulfilled by an incoming gift, you close out the prospective record so it is not counted twice.
We built exactly this for one organization, with a prospecting pipeline for gifts being cultivated and a separate view for gifts actually received, specifically so the team could see real revenue without inflating it with commitments that had not landed yet.
5. Deduplication and data hygiene
Fundraise Up will create Contacts that have no email address, for example when a gift is entered through its virtual terminal. Contacts without a reliable match key generate duplicates. So do migration windows, when a legacy platform and Fundraise Up are both feeding HubSpot during a cutover. And HubSpot's habit of auto-creating companies from email domains can spawn duplicate company records even when the domain is supposed to be unique.
Treat deduplication and matching as part of the build, not a cleanup you do later. Set the Fundraise Up contact-matching rules deliberately. Plan the migration so legacy data and Fundraise Up data do not overlap and create duplicate gifts. And accept that hygiene is ongoing; one of our implementers calls duplication "the never-ending demon," and the orgs that stay clean are the ones that build the guardrails up front.
The migration version of this is the one that hurts. On a Blackbaud-to-HubSpot project, an overlap window where both Blackbaud and Fundraise Up were syncing created duplicate gifts, and some of the legacy records had been pulled from uncommitted batches that lacked the accounting strings needed to close out deposits. The cleanup meant prioritizing the higher-quality, direct-from-Fundraise Up data over the legacy duplicates. None of that is visible until you try to reconcile a deposit and the numbers will not tie.
6. Gift dates and reporting accuracy
Fundraise Up has more than one date on a gift, including the donation date and the success date. If you map the wrong one to HubSpot's gift date, your donor segmentation, your cohorts, and your year-end totals all skew, and you usually do not notice until the numbers look off.
Decide on purpose which Fundraise Up date becomes the HubSpot gift date, and keep the others as their own properties so you do not lose them. When you change the mapping, backfill the historical data so old and new gifts are consistent. On one engagement, inconsistent gift dates carried over from a migration were enough to block accurate donor segmentation and the year's goal-setting until they were resolved. Dates feel like a detail. They are load-bearing.
7. Receipting, deposits, and accounting reconciliation
The native receipting is fine for simple cases. It is not enough for organizations that enter gifts in batches, have donors without email addresses, handle several deposit types, or have specific rules about who covers payment fees. And because Stripe (which Fundraise Up uses) pays out in batches, individual gifts have to reconcile against batch deposits.
The receipting and deposit layer is real work: automated receipts that fire on deposit close, a print queue for donors who have no email, batch gift entry, deposit types (ACH and EFT, wire, stock, gifts in kind), soft-credit handling, refunds, and routing for general ledger export. We have built this layer, including a receipt manager and batch entry tooling, for clients whose needs outgrew the defaults.
Fees deserve a specific mention because they are easy to get wrong. One foundation offers donors the option to cover processing fees, but passes the full intended amount to the designated program regardless and absorbs the fees as an operating expense. The reconciliation has to reflect that, and the Stripe batch payout has to be matched back to the individual gifts inside it. If your setup assumes one gift equals one deposit, it will not survive contact with a real Stripe payout.
8. Campaign and appeal reporting: the payoff
This is the whole reason to run Fundraise Up on HubSpot instead of standalone, and it is the thing that breaks if any of the decisions above are wrong.
Fundraise Up sends campaign IDs, designation data, and UTMs into HubSpot. But raw IDs sitting on Deals do not answer the questions a development director actually asks: what did the spring appeal raise, how is the year-end campaign tracking against goal, which email or page drove the gift, how much is recurring versus one-time, and how does this year compare to last. And Fundraise Up's "campaign" is not the same thing as a HubSpot campaign, so marketing effort and giving results do not line up on their own.
Done right, the reporting layer has three pieces:
First, appeal-level rollup through the designation hierarchy. Because your designations are structured and your gifts carry allocations, you can roll revenue up by appeal, by campaign, by fund, and report on it by month. This is what turns a pile of gift records into "the spring appeal raised this much across this many donors."
Second, campaign attribution that ties effort to dollars. Map the Fundraise Up campaign IDs and UTMs into HubSpot and use HubSpot's own source and campaign reporting, so a giving result connects back to the email, ad, or page that drove it. This is the closed loop, and it is the core argument for the combo: marketing and fundraising effort on one side, dollars raised on the other, in one system, with no separate analytics tool bolted on.
Third, expected versus actual reporting. Because you separated prospective gifts from actual gifts, you can report on how accurately your team forecasts, not just what came in. That turns your pipeline into a tool for getting better at fundraising, not just a list.
Notice that all of this is downstream. Reporting depends on source of truth, the designation hierarchy, recurring modeling, the prospective-versus-actual split, clean deduplication, and correct gift dates. Get those right and your dashboards are almost free. Get any of them wrong and every dashboard lies. That dependency is the entire argument for doing the unglamorous work first.
When the combo is a great fit, and when it is not
We would rather tell you up front.
Fundraise Up and HubSpot are a strong fit when you have meaningful online giving, you want higher conversion on your donation forms, and you want your giving data to live in the same place as your marketing and stewardship so it can drive decisions. The combo is especially strong if you are on HubSpot already or moving to it, and if recurring giving matters to you.
It is a weaker fit in a few cases. If your online giving volume is very low, the setup effort may outpace the near-term return; start simpler and grow into it. If no one on your team can own the system after launch, even a flawless setup will drift. And if your supporters strongly prefer a giving option your configuration does not allow, you will lose gifts, so the platform has to be set up around how people actually give, not how it is easiest to configure.
When the fit is right, this combination is hard to beat. When it is not, the honest move is to say so.
What a real implementation looks like
If you read all of that and thought "this is more than a five-minute switch," you are right, and that is the point. A real Fundraise Up and HubSpot implementation is a data architecture project: decide source of truth, build the designation structure, model recurring giving and memberships, separate pledges from paid gifts, set up deduplication and matching, map your dates, build receipting and reconciliation, and stand up the reporting that makes it all worth it.
You can do this yourself if you have the time and the HubSpot depth. If you would rather have it built right the first time, this is the work we do. See our Fundraise Up implementation for nonprofits page for how we approach it, or get in touch.