Switching to HubSpot: What Nonprofits Need to Know Before They Migrate

If you’ve been through a CRM migration before, you know it often takes weeks after you go live for everyone to fully trust the data. This guide is written to make that stretch shorter. It covers what a HubSpot CRM migration involves end to end: what data moves, what gets rebuilt rather than transferred, what the work costs, and the structural decisions that determine whether the system still holds up three months later. It applies whether you’re moving from Salesforce Nonprofit Cloud, Dynamics 365, or a donor database like Raiser’s Edge or Bloomerang.

Migrations fail in predictable ways. Reports stop reconciling against the old system. Giving or pipeline totals come out wrong after cutover, and nobody can trace why. Automation fires against half-imported records and emails people it shouldn’t have. When staff go back to the spreadsheets they were using before, that’s the clearest signal that a migration didn’t land.

The export file is rarely the cause. A migration is a sequence of decisions about structure, ownership, and what deserves to come with you, and most of those decisions get made weeks before anyone touches the data. This blog will cover the decisions you need to make and the order in which you’ll face them.

What You Need to Decide Before You Migrate

Here are five questions to consider before you request a single export.

1. What are you not migrating? Settle the exclusions before the inclusions.
2. How do your current records map to HubSpot objects? This determines every report you’ll build afterward.
3. Who owns the cleanup, and can they delete things? Cleanup without delete authority stalls.
4. Will you run a parallel period? And if so, which system is the source of truth during it?
5. What does success look like at 90 days? Define it now, in a number, while nobody is defensive about it.

A Migration Does Not Move Your Reporting

A HubSpot CRM migration moves records, relationships, and history from an existing system into HubSpot’s object model. That includes contacts, companies, deals, tickets, activity history, and custom properties. It doesn’t include your workflows, reports, dashboards, or integrations. Those are rebuilt inside HubSpot, and that rebuild usually takes more project time than the data import.

HubSpot organizes everything around a handful of standard objects and the associations between them. Contacts are people. Companies are organizations. Deals are revenue in motion. Tickets are service requests. Anything that doesn’t fit one of those becomes a custom object or gets flattened into properties on an existing record.

That distinction is important: when you flatten a record type into properties, you lose the ability to have more than one of them per contact. A single annual gift works as a property. Twelve years of giving history does not.

The thing to internalize before you scope anything is that your data transfers, but your logic gets rebuilt. If your current system runs 40 automation rules, someone is going to have to recreate all 40 of them in HubSpot workflows, and that person needs to understand what each rule was for. (It’ll probably turn out that half of them exist for reasons nobody remembers.)

What HubSpot Migrations Cost and How Long They Take

Most HubSpot CRM migrations run 6-12 weeks. A single clean source system with standard objects and no custom integrations can finish in 3-5 weeks. Multi-system consolidations involving custom objects, deep historical records, and several live integrations can run three to six months. The cost tracks the complexity of your data model far more closely than the number of records you have.

Five factors that drive the cost:

• Source System Count: Consolidating three systems is more than three times the work of migrating one, since you also have to resolve conflicts between them.
• Custom Object Requirements: Every custom object adds schema design, import sequencing, and association mapping.
• Integration Rebuild: Custom API work can run into five figures on its own and rarely appears in a first-pass scope.
• Historical Depth: Ten years of activity history costs more to validate than it usually returns in value.
• Pre-Existing Data Quality: This is a variable people rarely consider before signing, and it can move the timeline substantially.

You’ll also want to check what testing environment your subscription includes. Sandbox availability depends on your HubSpot tier; teams without a sandbox test in a temporary portal instead. That changes your testing plan, so confirm it during scoping rather than the week before go-live.

If you’re still weighing platforms rather than planning the move, our blog comparing HubSpot and Salesforce covers the decision that comes before this one. Full disclosure: we’re a HubSpot Platinum Solutions Partner and work with many nonprofit and higher ed organizations on the platform, so we’re inclined to see its benefits. That said, we’re happy to advise you on which CRM would work best for your organization, whatever platform you’re looking at.

Decide What You’re Not Migrating First

Moving is a chance to decide what you really need. When you’re migrating CRMs, the default instinct is to bring everything, since deleting feels risky and nobody wants to be the person who threw out the record that mattered. But the result is a new database stuffed with the same dead weight that made the old one hard to use, plus the extra cost of migrating and validating it all.

HubSpot’s own database decay simulation puts contact data degradation at roughly 22.5% per year. A five-year-old database has already lost most of its accuracy through job changes, email changes, and people who stopped engaging. You’re not preserving history when you migrate those records. You’re paying to move stale data into a system where it will worsen your segmentation.

Set your cut criteria before you look at the data, so the thresholds aren’t negotiated record by record. Here are some reasonable starting points:

• Contacts with no engagement in 24 months
• Closed-lost deals older than three years
• Custom fields populated on fewer than 5% of records
• Duplicate records with no clear survivor

Archive the source system as a read-only reference instead of migrating defensively. You keep the history, you keep the audit trail, and you stop paying to maintain it in a live CRM.

Two exceptions deserve a full migration. Multi-year giving and payment history have to come across intact, since the whole point of a fundraising database is longitudinal donor behavior. Likewise, anything under a compliance retention requirement moves regardless of how it scores against your criteria.

Map Your Source System to HubSpot’s Object Model

Your source records map to HubSpot contacts, companies, deals, and tickets. Anything that doesn’t fit becomes a custom object or gets flattened into properties. Here’s a quick reference for what maps onto HubSpot cleanly depending on where you’re coming from:

Source System	What Maps Cleanly	Which Records Cause Trouble
Salesforce Sales Cloud	Accounts, contacts, opportunities	Leads have no direct equivalent, and record types collapse
Salesforce NPSP / Nonprofit Cloud	Contacts, opportunities as gifts	Household accounts, General Accounting Units, recurring donation schedules
Dynamics 365	Accounts, contacts, opportunities	Custom entities need HubSpot custom objects
Raiser’s Edge / RE NXT	Constituents to contacts	Households, soft credits, relationship codes
eTapestry	Accounts to contacts	Journal entries do not map to deals one-to-one
Bloomerang / Kindful	Constituents, transactions	Recurring giving schedules and interaction types
DonorPerfect / Neon	Donors, gifts	Pledges, installments, membership records
Little Green Light	Constituents, gifts	Flexible custom fields with no underlying schema

Three structures break in almost every migration out of a donor system, and each needs a deliberate decision rather than a default.

• Households and Family Groupings: HubSpot gives you contacts and companies. A household is neither. You can model it as a company record, as an association label, or as a custom object, but all three have downstream consequences for reporting and email sending.
• Soft Credits and Shared Attribution: When a gift is credited to a foundation and to the board member who introduced you, HubSpot has no native concept for that second credit. You have to build it.
• Recurring Commitments with a Payment Schedule: A pledge paid in installments over three years isn’t one deal, and it isn’t thirty. Pick a structure, write it down, and make sure whoever builds your reports knows which one you picked.

Gift date mapping also deserves attention. If you map a gift’s date to HubSpot’s deal close date without checking how your fiscal calendar works, every year-over-year comparison you run will be subtly wrong, but you won’t find out until annual report season. Teams working through this for the first time usually benefit from seeing how HubSpot handles nonprofit data structures before committing to a mapping.

Clean the Data Before It Moves, Not After

Cleanup belongs in the source system or in a staging file, before import. If you wait to clean once it’s inside HubSpot, you do the work twice: once during the import and again after your automation has already fired against bad records.

Run four passes in this order:

1. Deduplicate: Decide the survivor rule before you start, since merging later loses associations.
2. Standardize Formats: Standardize phone numbers, state abbreviations, and date formats, so your import file validates on the first attempt.
3. Fill Required Fields: Anything your HubSpot workflows will branch on has to be populated before those workflows turn on.
4. Assign Owners: Unowned records fall out of every pipeline report you build.

The constraint here is usually staffing. NTEN’s 2025 Data Empowerment Report found that, based on job titles, 42% of nonprofits have no staff member specifically assigned to work with data, and 70% named internal technical capacity as their single biggest barrier to adopting new technology.

Give one person ownership of each object type and give them authority to delete. If every cleanup step needs to be routed through a committee, it will take forever to finish.

Test with Your Worst Records, Not Your Cleanest

Import a representative sample first, validate it against the source system, then import in full. However, the operative word here is “representative.” Most teams test with their best 100 records, confirm everything looks right, and discover the problems after the full import has already fired a thousand workflow enrollments.

Pull your messiest 5% instead. Records with missing fields, duplicate-looking names, and weird legacy associations are the ones that are most likely to test your import.

Validate four things before you go further: record counts by object, association counts, total pipeline or giving value, and one standard report built side by side in both systems. If those four reconcile, your mapping holds. If the association count is off, something in your relationship structure didn’t survive, and finding it now will cost hours rather than months.

Then run parallel for two to four weeks. Name one system as the source of truth for new records during that window, and set a hard date after which the old system becomes read-only. (Parallel periods without an end date turn into permanent dual entry.)

Turn on Automation Only After the Records Land

Here’s the order of operations: core objects, then associations, then integrations, then automation. Audit every system currently touching your CRM and sort each one into rebuild, replace, or retire. A surprising share of integrations exist to patch a gap that HubSpot covers natively, and those are worth retiring rather than rebuilding. Nonprofit integration options have expanded enough that some connectors you’ve been paying for are probably now redundant.

Hold your email sending until contact properties and subscription status are fully validated. Sending to a half-migrated list is a very visible migration mistake.

Once the core data is stable, the automation layer is where the move starts paying for itself. A lapsed donor re-engagement workflow or an AI-assisted process only works on clean, well-structured records, which is the argument for doing the unglamorous parts first.

When HubSpot Is the Wrong System for Your Data

Some data doesn’t belong in HubSpot, and recognizing that early can save you a six-figure mistake.

Complex product catalogs with configure-price-quote requirements strain against HubSpot’s product library. Grant and program management with multi-level reporting hierarchies usually needs a purpose-built system. Organizations whose daily operations run through a vertical platform, such as a case management or student information system, are generally better served integrating with HubSpot than migrating into it.

Here’s a useful test: if your structure requires more than three custom objects with multi-level associations between them, the implementation cost may exceed the value of consolidating. Keeping a system of record for one function, then syncing it with HubSpot, is a legitimate way to structure your data if it better serves your purposes. Not everything needs to live in the new CRM.

Sector context helps here too. The patterns differ meaningfully across higher education and other cultural institutions, where the records that matter most are students or members rather than donors.

What to Do in Your First 90 Days on HubSpot

Go-live is the start of the project, not the end of it. Set three checkpoints and stick to them.

At 30 days, measure logged activity per user. If a quarter of your team isn’t creating or updating records directly in HubSpot, you have an adoption problem that no amount of configuration will fix.

At 60 days, rebuild your three most important reports and reconcile them against the legacy system. Discrepancies at this stage are mapping problems, and they’re still cheap to correct.

At 90 days, retire the redundant tools and move the source system to read-only archive. Teams that skip this step keep paying for both, and keep giving staff a place to hide from the new process.

In the past 11 years we’ve partnered with HubSpot, we’ve found that the organizations that get the most out of it at the start treat the migration as the floor, not the finish. Once your data is trustworthy, you can start incorporating content strategy tooling, AI search visibility tracking, and all the other features that make the platform stand out. See what that looks like in practice across a range of nonprofit HubSpot implementations we’ve worked on.

Whether you’ve made your decision to migrate to HubSpot and you need technical help implementing the system or you’re not certain whether a migration is worth it in the first place, our team has the experience to advise you on the choice and work with you to improve and refine your donor data, regardless of which system you use.

FAQs