eTapestry earned its place. For small and mid-size nonprofits that needed a real donor database without a six-figure price tag, it delivered. Gifts tracked. Appeals managed. Donors organized. For a long time, that was enough.

Then organizations grew. Or their marketing team started living in a different system. Or leadership started asking questions that required pulling data from three places and reconciling it in a spreadsheet. The ceiling became visible.

HubSpot addresses all of that — but not automatically, and not without work. The organizations that come out of this migration in a stronger position than they started are the ones who understood going in that they weren't just moving data. They were redesigning how their organization manages donor relationships. Here's what that actually involves.

eTapestry and HubSpot Think About Data Differently, and That Gap Has to Be Bridged Deliberately

eTapestry is built around accounts and journals. A donor is an account. Everything that happens with that donor — a gift, a note, a contact report, a relationship — is a journal entry attached to that account. It's intuitive once you're in it, and it keeps a donor's full history in one place.

HubSpot doesn't work that way. Contacts, companies, deals, and activities are separate objects with defined relationships between them. There's no journal. There's no account-level rollup that works the way eTapestry does. The logic your team relied on — often without thinking about it — has to be consciously rebuilt.

What makes this tricky is that eTapestry's model is simpler than some other nonprofit CRMs, which leads organizations to assume the migration is more straightforward than it is. The gap is real. It just shows up in different places than people expect.

Key lesson: Don't let the relative simplicity of eTapestry's data model lower your guard on migration planning. The architecture decisions are still significant.

Your Fund Structure Is Central to Everything, and HubSpot Doesn't Know It Exists

Funds are how nonprofits track where money goes. Restricted gifts to an endowment. Unrestricted operating support. A capital campaign. A named scholarship. In eTapestry, the fund structure is woven into gift entry, reporting, and acknowledgement. It's fundamental.

HubSpot has no native fund object. No designation logic. No way to associate a gift with a fund out of the box. Building it requires custom objects, custom properties, and association logic that connects gift records to fund records in a way that supports reporting downstream.

And before any of that can be built, someone has to answer questions the organization may not have revisited in years: Which funds are still active? Which were consolidated or renamed? What are the reporting requirements for each? The migration forces that conversation. Organizations that do this work seriously come out with a cleaner, better-understood fund structure than they went in with.

Key lesson: Map your fund architecture completely before any data moves. What you build in HubSpot will reflect the decisions you make here.

Journal Entry Types Each Need Their Own Destination

In eTapestry, a journal entry is a catch-all. It might be a gift. A pledge payment. A contact report from a meeting. A note. A soft credit. They all live in the same structure, which makes eTapestry easy to navigate and hard to migrate.

In HubSpot, each of those things lives somewhere different. Gifts become deals. Notes stay notes. Contact reports might become a custom activity type or a note with structured properties. Pledge schedules require a different approach entirely. None of those decisions are automatic — each journal type needs a defined destination before migration work begins.

This is also where relationship intelligence lives. Years of contact reports, meeting notes, and stewardship history stored as journal entries have real value. How that history gets preserved — or doesn't — affects whether the new system is genuinely useful for major gift officers from day one.

Key lesson: Inventory your journal entry types before migration starts. Each one needs a conscious mapping decision.

Households Are Not a Feature You Configure, They're an Architecture You Build

eTapestry links individual accounts to household accounts and aggregates giving at the household level. It works because the structure is built into the system.

HubSpot has no household concept. What you have instead is a flexible association framework — the ability to link contacts to each other, label those relationships, and build calculated properties that aggregate data across them. That flexibility is genuinely powerful. It also means the household logic that feels automatic in eTapestry has to be designed from the ground up.

Before migration, that requires clear answers to questions like: How do you define a household? Who is the primary contact? How do you handle a gift made by one spouse that both spouses should receive recognition for? How do you calculate total household giving across multiple individuals?

The data coming out of eTapestry often surfaces inconsistencies that have accumulated over years — households with outdated members, relationships coded incorrectly, primary contacts that no longer reflect how the organization actually works. Cleaning that up before migration is the right call. Bringing it over as-is means inheriting problems that affect stewardship of your most important donors.

Key lesson: Household logic requires upfront design decisions, not post-migration cleanup.

Active Recurring Donors Need a Solution Before Go-Live, Not After

Recurring commitments are operationally sensitive in a way that other data types aren't. A major donor on a multi-year pledge or a monthly giving program is an active relationship with expectations on both sides. Staff need to see that commitment the moment they open a donor record — not after navigating through multiple objects.

eTapestry surfaces recurring gifts and pledge schedules within a donor's account. HubSpot doesn't do this natively for fundraising. Without a purpose-built solution, a gift entry staffer processing an incoming check would have to open a separate tab, search for the donor, locate any open deals, and manually determine whether the payment applies to an existing commitment. At volume, that's not sustainable.

The solution is a custom sidebar view that surfaces open commitments during gift processing. It's buildable, and it's worth building before anyone processes their first gift in the new system. Organizations that treat it as something to address after launch discover the problem at the worst possible moment.

Key lesson: Recurring gift visibility is a go-live requirement, not a nice-to-have.

Historical Giving Dates Are Easy to Get Wrong and Hard to Fix Later

When deal records are created in HubSpot, the close date defaults to the date the record was created — not the date the gift was originally made. For a nonprofit that runs year-over-year giving comparisons, retention analyses, or any report that depends on when gifts were made, this creates a dataset that looks complete and is silently wrong.

The fix is not complicated: map historical gift dates to the deal close date field explicitly, before the first migration run, and validate the output against a sample of known donor records before go-live. What makes it a risk is that it doesn't cause an obvious error. Everything imports cleanly. The problem only surfaces when someone runs a report and the numbers don't match what they expect.

Key lesson: Validate gift dates against source records before go-live. Your historical reporting depends on it.

Opt-Out Preferences Don't Enforce Themselves

eTapestry stores communication preferences at the account level — flags that indicate a donor's solicitation preferences. In practice, the system provides guardrails that make it harder to contact donors who have opted out. HubSpot provides tools, not guardrails.

Exclusion logic in HubSpot has to be manually applied as filters on every campaign, enrollment trigger, and workflow. There's no system-level block. If a staff member builds a campaign and forgets the exclusion filter, donors who asked not to be contacted will receive communications. That's a compliance issue and a relationship issue.

This is as much a training problem as a configuration problem. The right response is process documentation, a campaign launch checklist that includes exclusion verification, and reinforcement during the first months of operation when the new habits are still forming.

Key lesson: Solicitation compliance in HubSpot is a team discipline, not a system setting.

The Reports You Relied on Have to Be Rebuilt

LYBUNT and SYBUNT lists. Fund performance by quarter. Giving by appeal or campaign. Retention rates year over year. These reports exist in eTapestry because someone built them, and your team has come to depend on them.

None of them transfer to HubSpot automatically. They have to be reconstructed using HubSpot's reporting tools, custom properties, and — for more complex calculations like rolling 12-month totals — Operations Hub. The underlying data is there. The reports have to be built on top of it.

The organizations that handle this well identify their ten most critical reports before migration begins, build them in HubSpot during the migration project, and validate them against eTapestry output while both systems are still running in parallel. The ones that don't end up at go-live with a functional CRM and no way to answer the questions leadership asks every week.

Key lesson: Treat report rebuilding as a migration deliverable, not a post-launch project.

The Learning Curve Is Real, and It Doesn't End at Go-Live

Staff who have used eTapestry for years have internalized it. The navigation, the gift entry flow, the way a donor's history is laid out — it's automatic. HubSpot works differently in nearly every one of those moments, and the adjustment takes longer than a few training sessions.

That's not a knock on HubSpot's usability. It's actually better than eTapestry for most day-to-day tasks once staff are past the unfamiliarity. But getting there requires treating enablement as a sustained investment through the first several months of operation — not a one-time event at launch.

The organizations that do this well identify who's adapting quickly and put them in a position to support their colleagues. They build internal documentation that reflects how your specific instance works, not generic platform tutorials. They create space for staff to ask questions without feeling behind.

Key lesson: The transition period after go-live matters as much as the migration itself. Staff who feel supported through it become the system's strongest advocates.

The Bottom Line

eTapestry got a lot of nonprofits to where they are. HubSpot is where many of them need to go next — a platform where fundraising, donor relationships, and communications actually connect, rather than running in parallel and requiring manual reconciliation.

Getting there takes more than a data export. It takes deliberate decisions about architecture, operations, and how your team works. The organizations that make those decisions carefully, before the migration begins rather than during it, come out the other side with something worth the effort: a system their team actually wants to use, built around how they actually work.