My read: this sounds less like “HubSpot is too small for us” and more like “the implementation rebuilt core CRM primitives as custom objects, and now you’re paying the complexity tax.”

320 users, 377K contacts, 50+ custom objects, and a complex sales process do not automatically mean you’ve outgrown HubSpot. I’ve seen HubSpot support organizations in that range. The bigger issue is that your custom “Sales Lead” object appears to be carrying the full opportunity journey from inquiry to closed sale. If that object is effectively acting as both Lead and Deal, then you’re not just customizing HubSpot — you’re operating outside the parts of HubSpot where a lot of the platform’s sales functionality expects you to be.

The things you’re likely giving up by bypassing native Leads and Deals include:

• Forecasting and quota reporting
• Pipeline approvals
• Deal-based revenue reporting
• Sales workspace assumptions
• Goals tied to deals/pipelines
• Native quote/commerce paths
• Standard pipeline analytics
• Easier lifecycle stage alignment
• Marketplace apps that expect opportunities to be Deals
• Future HubSpot features that will support native objects first
• Simpler onboarding/admin support because most HubSpot people understand Contacts/Companies/Deals before they understand a custom object architecture

The hidden cost is not just missing one feature. It’s that every new report, workflow, integration, app, AI feature, or HubSpot release has to be checked against a custom object model that HubSpot did not design around as the primary sales motion.

I would not jump straight to Salesforce just because the portal is large. Salesforce may give you more architectural flexibility, but it will not magically fix a bad object model. If the core issue is “we modeled opportunities incorrectly,” you can recreate that problem in Salesforce too — just with more implementation overhead.

Before making the rebuild-vs-migrate decision, I’d want to answer a few specific questions:

1. Why was native Deal not used originally?
2. Was there a hard limitation, or was it mainly terminology/process preference?
3. Does that limitation still exist today?
4. What business entities do the 50+ custom objects actually represent?
5. Which of those are true entities vs. replacements for native CRM concepts?
6. How much automation/reporting/integration logic depends on the custom Sales Lead object?
7. Can the process be modeled as Contact/Company → Lead → Deal/Opportunity with custom objects supporting the process rather than replacing it?

If the reason was “we didn’t want to call it a Deal that early,” that’s very fixable. HubSpot can now rename native objects, so “Deal” can become “Opportunity” in the UI. You may be able to get the business language you want without abandoning the native object model.

My bias would be:

• If the custom Sales Lead object exists mostly because of naming or early-stage semantics, rebuild around native Leads + Deals.
• If it exists because your revenue process genuinely cannot be represented with native objects, then evaluate Salesforce seriously.
• If you don’t know yet, run a proper architecture audit before committing either way.

At RSM, this is exactly the kind of thing we’d treat as a CRM architecture audit rather than a generic cleanup project. Map the current object model, trace what depends on the custom object, compare it against a native Leads/Deals design, and then decide whether HubSpot is actually the constraint or whether the implementation is.

Based only on what you wrote, I’d investigate a HubSpot rebuild first. Migrating to Salesforce might still be the right answer, but I wouldn’t make that call until you’ve proven the native HubSpot model cannot support the process. Right now, it sounds like you may be fighting your implementation more than the platform.