Most go-to-market teams treat the CRM decision as a rite of passage. You start on HubSpot, you grow, and eventually you "graduate" to Salesforce. The assumption is so embedded in RevOps institutional memory that some operators have their migration roadmap sketched out before they've logged into the new company's system. But what if that narrative is mostly mythology — and the real limitation isn't the platform, but the processes and data architecture sitting on top of it?
In a recent RevOps Co-op webinar, Matthew Volm, CEO and Founder of RevOps Co-op, brought together three operators with hands-on experience across both sides of this debate: Ed King, Founder and CPO at Openprise; Georgina Tsioutsiouli, Group Manager of Sales Operations at Foxit; and Amani Phipps, Revenue Architect at Bonusly. Together, they challenged the received wisdom about HubSpot's enterprise ceiling, unpacked where the platform genuinely struggles at scale, and made the case for a data orchestration layer as the missing piece that makes HubSpot viable — and often preferable — for complex organizations.
Before the session could challenge the graduation myth, the panel needed to interrogate the word "enterprise" itself. A live audience poll asked attendees how they define it: by revenue threshold, headcount, number of systems, data volume, process complexity, or simply vibes. The majority landed on headcount — but the panelists pushed back immediately.
"Revenue and headcount are mostly marketing indicators. It's not RevOps or SalesOps indicators of what's enterprise ready." — Georgina Tsioutsiouli
Tsioutsiouli's argument is structural: a construction company with 1,000 employees might need access for only 50 users. A 50-person company doing something uniquely complex might need enterprise-grade infrastructure from day one. The number of bodies in seats tells you almost nothing about the system demands on your CRM.
King framed his answer around system of records — the number of distinct platforms your business runs on, not the headcount it employs. As organizations grow, they accumulate more systems, more data silos, and more human effort stitching them together. That accumulation is a more reliable signal than any org chart metric.
Phipps offered the most operational definition: enterprise is when the motion — the buyer journey, the commission structure, the customer success handoff — becomes fundamentally more complex and demands more of your infrastructure. At Bonusly, "enterprise" means navigating users across 15 countries, managing deal splits, and coordinating tightly between account executives and customer success managers. That complexity, not the headcount driving it, is what determines whether your current stack is adequate.
The practical implication for RevOps teams: stop borrowing someone else's definition of enterprise and start measuring your own operational complexity. As the RevOps Co-op community has explored in discussions about process complexity and governance, the tipping point is rarely a clean number — it's a felt experience of your infrastructure starting to strain.
King was direct about what he sees most often in practice: migration decisions driven not by careful analysis, but by received wisdom.
"We had this customer — he was a multi-time customer. He accepted this new job at a new place. Three months before he even started, he was talking to me, he's like, 'I know the next nine months, my first nine months on the job is going to be a Marketo migration.' The guy never even touched HubSpot in his life." — Ed King
The story has a better-than-usual ending. The new hire actually did the homework — talked to internal users, identified where the real pain was concentrated, and brought in Openprise to handle the back-end data and automation gaps. The HubSpot instance stayed. His marketing and sales users, who genuinely liked the platform, never had to go through a disruptive migration.
The instinct to graduate, King argues, often ignores a fundamental trade-off: more extensible platforms like Salesforce and Marketo carry substantially higher administrative and technical burdens. There is no free lunch. The configurability that makes Salesforce appealing at scale also demands more skilled administrators, more implementation overhead, and a steeper learning curve for every end user on the system.
Phipps traced the mythology back to its origins. Salesforce became shorthand for "mature RevOps" over years of industry pattern-matching — advanced teams used it, so using it signaled advancement. That story got written, and then it stayed on the shelf, referenced by default rather than re-evaluated as platforms evolved. As she put it, "Eventually, once their story was written, it just stayed on the shelf. It continued to become the book that we refer everybody to go and read, as opposed to seeing that the world is changing."
This is a version of the same challenge covered in Episode 48 of the RevOps Co-op podcast on rebuilding a tech stack — the hardest part isn't choosing the tool, it's letting go of the assumption that the current conventional answer is still the right one.
The panel didn't argue that HubSpot is limitless. There are genuine areas where the platform has historically struggled — and some where it still does. The audience poll on HubSpot limitations pointed toward ecosystem integrations as the top friction point, and the panelists elaborated from direct experience.
Phipps named three recurring pain points. First, deduplication at scale: for years, HubSpot's answer to large-scale duplicate management was essentially "go one by one manually," which is untenable at half a million records. Second, audit logging and property history: the ability to restore a prior version of a record and meaningfully interact with historical property data only arrived in HubSpot within the last few months. Third, workflow complexity that historically required patching in tools like Zapier to make the platform behave like operators needed.
What's notable about this list is the category it falls into. These are infrastructure and back-end concerns — not end-user-facing limitations. As King observed, "You don't hear people talking about the more user-end-user-facing capabilities." Reps and marketers aren't filing tickets about deduplication logic. They're filing tickets about UI friction — and HubSpot tends to win that battle handily.
Phipps also traced how HubSpot's improvements over roughly three years changed her own calculus. Custom objects — which Bonusly now uses to push Gong transcripts directly into HubSpot and use them to auto-populate deal properties — were a meaningful expansion. API improvements. The predictive lead scoring capabilities. The shift from PandaDoc to HubSpot Quotes as the CPQ layer matured. Revenue Hub. The Snowflake connector via DataHub. Each improvement independently is incremental. Cumulatively, they've redrawn the line of what's genuinely missing versus what's been assumed to be missing.
"I would do worse if I went to Salesforce today compared to if I did two years ago. On top of the administrative burden to migrate to a Salesforce, HubSpot does most of what we need at this point, which is great." — Amani Phipps
The most concrete case study of the session came from Tsioutsiouli, who is living through the reverse of the assumed graduation path in real time: Foxit, a global PDF and eSign software company with roughly 1,000 employees, is migrating from Salesforce — a 15-year-old instance that has passed through dozens of administrators — to HubSpot.
But Tsioutsiouli insisted from the outset on getting the framing right.
"This is not a migration. It's more of a transformation project, I would put it, and how we build our GTM tech stack for the years to come." — Georgina Tsioutsiouli
The first principle Foxit established was a diagnostic question for every pain point: would this problem disappear if you changed the CRM? In almost every case, the answer was no. The Salesforce instance held approximately 5.5 million records — many with duplicates, inconsistencies, and legacy data whose provenance nobody could trace. Moving those records as-is into HubSpot wouldn't solve the data problem. It would just give it a new address. As Tsioutsiouli summarized: "If the data is bad, changing CRM won't fix it. If the process has too many steps, changing CRM won't fix that either."
The second principle was separating the data problem, the process problem, and the technology problem — and solving them in that order. Foxit's commercial complexity is real: direct deals, channel deals, distributors, resellers, subscription products, perpetual products, multiple approval layers, varying discount structures, global operations. No CRM swap eliminates that complexity. What HubSpot offers Foxit is the opportunity to rebuild that complexity intentionally, from the ground up, rather than inheriting 15 years of accumulated workarounds.
The third principle was the most operationally demanding: every validation rule, workflow, and approval encountered during the migration process had to be interrogated. Why does it exist? Who uses it? If we were designing this today, would we build it the same way? The answer was most frequently a version of "we've always done it this way" — which is not a design principle, it's institutional inertia. The 9 Best Practices for Better Change Management framework applies directly here: the process of challenging entrenched conventions is itself a change management exercise, not just a technical one.
The AI dimension matters here too. Foxit is incorporating AI into the implementation, but Tsioutsiouli was clear-eyed about sequencing: "If the process is unnecessarily complex, AI won't solve this. It will execute faster, but just about it." Simplify first. Automate where it makes sense. Add AI where it creates genuine value. Anything else is just accelerating the wrong thing.
King's argument for how to close HubSpot's enterprise readiness gaps centered on a single architectural addition: a data orchestration layer. This is where Openprise operates, and King walked through the component structure of what that layer actually does.
The starting point is a shared data layer — the ability to connect to all the systems in your stack and create a single, unified data repository. Connecting systems is table stakes; matching records across those systems is the harder, more consequential step. The same company showing up in your CRM, your intent data feed, and your engagement records needs to be recognized as the same company before any of that data becomes useful for decision-making.
From there, the orchestration layer handles data cleaning, deduplication, and what King described as "data firewalls" — automated gatekeeping that prevents bad data from continuously re-entering the system. Data management for RevOps professionals has long been foundational work, but the difference at scale is that manual hygiene becomes impossible. The orchestration layer is what makes hygiene sustainable.
The workflow and automation capabilities within an orchestration platform address many of the back-end limitations that have historically driven operators toward Salesforce. Multi-vendor enrichment, sophisticated segmentation, advanced scoring, and centralized logging and monitoring — all areas where HubSpot has struggled at enterprise scale — become manageable when handled by a purpose-built orchestration layer rather than bolted-on point solutions. The alternative King described is accumulating 20 different pieces of technology to patch individual gaps, which creates its own integration and maintenance burden.
"Instead of bolting on 20 different pieces of technologies, having one single platform is very beneficial." — Ed King
The enablement piece of the orchestration stack is where King sees the most underappreciated value. Self-service applications that let end users load and build their own lists without submitting ops tickets. API and webhook connectivity that extends HubSpot's capabilities to adjacent tools. And, increasingly, Model Context Protocol (MCP) servers that allow AI agents to interact with back-end systems beyond the CRM itself. This is the architecture that gets RevOps teams out of the helpdesk cycle — a challenge explored in depth in Episode 67 of the RevOps Co-op podcast — and back into strategic work.
King noted that Forrester Research is preparing a landscape report on the data orchestration market, which suggests this category is reaching enough maturity to attract formal analyst attention. For RevOps teams evaluating their HubSpot infrastructure, this framing — platform plus orchestration layer rather than platform replacement — is increasingly the architecture worth building toward. The Openprise platform is built specifically to provide this orchestration capability across complex GTM stacks.
Phipps introduced a reframe from revenue operations as a service to revenue operations as a product team that the panel found broadly resonant. The real question behind the platform debate isn't which CRM is more capable. It's what identity your RevOps team is trying to hold.
Phipps pointed out that too many RevOps teams define themselves by busyness rather than impact. Tickets flowing in, systems getting maintained, requests getting serviced. The operational work is visible and justifiable. But it crowds out the work that actually moves revenue.
"RevOps is a product team. Every user at this organization is a customer. Every department shares a new ICP, and they need a different thing, but I need to have the time and space to think about what I'm doing and building." — Amani Phipps
The product team analogy extends to roadmap discipline: finish what you start, reduce scope aggressively, and protect the space to do meaningful work rather than filling every hour with maintenance. At Bonusly, this meant moving from Gainsight to a simpler customer success platform, investing in Snowflake integration, and leveraging HubSpot's DataHub connector to bring warehouse data directly into the CRM at a per-record cost that made economic sense — not because these moves were the obvious choices, but because they reduced the operational drag that kept the team in firefighting mode.
This connects to a broader principle that surfaces consistently across RevOps conversations: the teams that have the most strategic impact are not the ones with the most sophisticated tool stacks. They're the ones who've done the unglamorous architectural work to make their infrastructure reliable enough that they're no longer needed as human glue between systems. As covered in Episode 94 of the RevOps Co-op podcast on the boring work behind great AI, the prerequisite for doing anything interesting is getting the foundational layer right.
The platform decision, in this framing, is downstream of identity. Decide what your team is for. Then choose the tools that give you the most capacity to be that thing — not the tools that your peers migrated to three years ago for reasons that may no longer apply.
The case being built across this session isn't that HubSpot is the right answer for every organization. It's that the assumption it can't be the right answer past a certain scale deserves far more scrutiny than it typically receives. The teams getting enterprise-grade outcomes from HubSpot are the ones who've paired the platform with the right orchestration infrastructure and asked, before every migration conversation, whether the problem they're trying to solve is actually a platform problem at all.
Learn more about how Openprise helps revenue operations teams manage data orchestration, enrichment, governance, and automation across complex GTM stacks — so your CRM investment, whatever platform it sits on, actually delivers on its promise.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
