Struggling for a bird’s eye view of your customer data? You’re not alone. We’ve worked with over 100 clients across multiple industries, and the same problem comes up in nearly every one: customer data is split across a CRM, an ERP, a billing platform and a support tool, and no single system shows the full record.
But here’s the good news… many of these systems can connect to HubSpot through its App Marketplace, which is essentially a directory of prebuilt connectors. But in some cases, such as core banking, practice management and legacy ERP, no prebuilt connector exists, so the integration has to be built.
Below, we cover the nine systems enterprise teams connect most often and what each integration requires.
In this blog, you will learn:
Providers that unify complex B2B tech stacks on HubSpot choose the right connection method for each system. Some systems have a prebuilt connector, while others need middleware or a custom build. They also decide which system holds the correct version of shared data. The table below shows how each of the nine systems connects to HubSpot.
Each entry ends with who owns the field. That means which system has the final say when two systems hold different versions of the same data, such as a customer’s address.
The defining question is whether the old system switches off. If it does, this is a migration with a temporary sync. If it stays, it's a permanent two-way integration that needs to be scoped as one.
Salesforce has a native HubSpot connector. Dynamics and most others do not, which turns the work into a custom build or a middleware route.
Blue & Co., a 17-office accounting firm across five states, had been on Microsoft Dynamics for more than five years alongside Maconomy, HubSync and IntroHive. The consolidation moved approximately 91,000 contacts, 97,000 companies, 22,000 deals and 31,000 master clients into a single model.
The failure point is the sync scope. Rehmann ran HubSpot and Salesforce in parallel with 99.7% of contacts syncing automatically, which produced more than 30,000 duplicates.
Who owned the field? During an overlap period, it was the system where the work happened. After cutover, it was HubSpot.
Nothing in this category is a long-term integration, which is why it is routinely under-scoped. The connection exists only to move contacts, engagement history and campaign structure once, and then it is retired.
What doesn't come across is the automation itself. GARP's migration required 129 Marketing Cloud email templates to be converted and 21 Marketing Cloud journeys to be rebuilt as HubSpot workflows. ACT, Inc. centralized three million contacts out of Marketo, Salesforce, On24 and Cvent.
The failure point lies in treating the journey and template rebuild as configuration rather than a project workstream with its own estimate.
Who owned the field? HubSpot does, from the first day of the transition. Running two marketing automation platforms against one contact database produces conflicting logic.
Almost always, this is a custom build because core banking platforms do not appear in connector marketplaces and rarely expose a modern API. The integration usually reads scheduled extract files rather than calling a service.
Pinnacle Bank, a $2 billion community bank, unified more than 10 systems, including Fiserv Precision, nCino, MortgageBot and Weiland treasury, across roughly 300 users at 28 branches. Thirteen Fiserv Precision extract files are consolidated nightly, and three custom objects hold the banking relationship structure.
The failure point is reconciliation. Nightly extracts arrive at different times, in different formats and with different account identifiers, and the matching logic must be designed rather than assumed.
Who owns the field? The core banking platform owns the account and balance data without exception. HubSpot owns relationship and engagement data. That boundary should never blur, and core banking data silos are what happens when it does.
Direction is the decision that matters most in this category, and it is genuinely two-way more often than any other system on this list. Sales needs to see invoices and payment status. Finance needs to see closed-won deals.
ZEF Energy moved off Copper CRM in 3.5 months while keeping Microsoft Business Central, connected to HubSpot through a bi-directional integration. The build included 90 custom reports and eight dashboards on the combined data, and quote-to-cash runs without a manual handoff.
The failure point happens when field ownership is left undecided. When both systems can write a customer name, an address or a contract value, the last write wins, and neither team trusts the record.
Who owns the field? Finance owns anything that appears on an invoice. HubSpot owns anything that describes the relationship before the invoice exists.
Access is the first obstacle rather than mapping. These systems are frequently on-premise, which means the integration needs a scheduled pipeline and somewhere to stage the data rather than a direct API call.
Weissman, an Atlanta real estate law firm with 20 offices and more than 30 closing attorneys, has a pipeline architected to run from SoftPro through a data warehouse, Power BI and Power Automate into HubSpot daily, replacing manual month-end uploads. Hill, Barth & King, a Top 100 CPA firm serving more than 20,000 clients across 20 states, syncs STAR practice management data into HubSpot nightly with a custom job object linked to deals.
The failure point is the object model. Practice management systems structure work as matters or jobs, which have no native HubSpot equivalent, so a custom object must be designed and associated to deals correctly.
Who owns the field? The practice management system owns matter and job data. HubSpot owns the client relationship and the originating source.
Property volume is the thing to size here before anything else. Billing systems carry a great deal of structured data per customer. Deciding how much of it belongs in the CRM is a scoping exercise.
Estech Systems connected Rev.io to HubSpot through a custom serverless function with 65 properties mapped and 35 custom fields created, as a one-way sync was completed in three months.
The failure point lies in over-mapping. Every property brought into HubSpot is a field someone must maintain and a potential reporting inconsistency. Bring in what sales and service actually use.
Who owns the field? The billing system does, always. This should be one-way. A CRM that can write to billing data creates a reconciliation problem with financial consequences.
Unlike every system above, here, HubSpot is the source rather than the destination. The integration exports CRM data into a warehouse where it can be joined with financial, operational or product data that will never live in a CRM.
GARP's build included nine data objects configured with real-time syncing, 24 custom dashboards and nine data studio reports. Weissman's architecture routes SoftPro data through a warehouse and Power BI before it reaches HubSpot, with 10 custom reports in the resulting daily dashboard.
The failure point is a definition mismatch. A warehouse counting customers by invoice and a CRM counting them by company record will disagree, and both would be right. This is the most common source of reporting gaps after a HubSpot data integration enterprise.
Who owns the field? The warehouse owns the reported figure. HubSpot owns the operational record. The definitions have to be reconciled explicitly, in writing.
This is the most straightforward category on the list. A native Zendesk connector handles ticket and contact sync without custom work for most configurations.
The complication is identity. A customer who raises a ticket from a personal address, a shared inbox or a second domain creates a second contact record, and support history fragments across both.
The failure point happens with contact identity matching. Decide the matching rule before connecting, not after the duplicates exist.
Who owns the field? The support platform owns ticket data. HubSpot owns the contact record, which means the matching logic has to resolve to HubSpot.
This is last on the list because the scope is narrow, although the volume can be substantial. GoToWebinar has a native connector; others require custom work. ACT, Inc.'s consolidation included both On24 and Cvent.
The data that matters is registration, attendance and duration, which drive lead scoring and follow-up routing.
The failure point is registration-to-contact mapping. Event platforms collect a name and email at registration with no company or lifecycle context, which creates thin contact records that enter nurture flows with nothing to personalize against.
Who owns the field? The event platform owns attendance. HubSpot owns everything else, including the enrichment that makes the registration useful.
Four questions resolve nearly every case:
Write the answers down before the build. An ownership map is a one-page document, and its absence is the most reliable predictor of a reporting dispute six months after go-live.
Every integration is a system that needs an owner after go-live. Source schemas change, credentials expire, extract formats get modified upstream without notice and API versions are deprecated.
The maintenance burden scales with the connection method rather than the record volume. Native connectors are maintained by the vendor. Middleware requires monitoring and occasional reconfiguration. Custom builds require someone who can read the code.
Hill, Barth & King's integration rebuild completed four testing rounds with 186 documented test cases, and one of its stated outcomes was removing dependency on a third-party integration tool to restore internal control. That is a maintenance decision as much as a technical one.
Budget for it explicitly. An integration with no named owner degrades, and the degradation is usually discovered through a reporting error rather than an alert.
Mole Street produces an ownership map during discovery, before any connection is built. The map lists every system, shared object and field that more than one system can write to, with a named owner for each.
The build sequence follows from that map. Native connectors go first because they are fastest to validate. Middleware goes next, and custom builds come last, since they depend on decisions that the earlier work surfaces. Across banking, accounting, legal, education and telecom stacks, the pattern holds. Roughly half of enterprise integration scope needs custom work, and nearly all the disputes are about ownership rather than connectivity.
The service detail is on the custom integrations page, and HubSpot CRM Integrations: The Ultimate Guide covers the broader marketplace landscape for teams at an earlier stage.
Almost any enterprise system can connect to HubSpot, but whether the customer data ends up unified depends on decisions made for each system before the build. This can be boiled down into three key decisions:
When these decisions are skipped, the systems still connect, but each one ends up holding a different version of the same customer data. That is how a customer appears as two contacts, or how a warehouse and a CRM report different customer counts.
Start with the systems in your own stack. Take note where two of them hold the same data, and decide which one has the final say. Achieve this and you will get a 360 view of your customer data.
Can HubSpot integrate with a core banking platform?
Yes, but almost always through a custom build rather than a connector. Core banking platforms such as Fiserv typically expose scheduled extract files rather than a modern API, so the integration reads and reconciles those files. Pinnacle Bank's build consolidates 13 Fiserv Precision extracts nightly.
Should HubSpot be the source of truth for all customer data?
No. HubSpot should own relationship and engagement data. Financial, billing and account data should stay owned by the system of record, with HubSpot reading it. Making a CRM the source of truth for invoice data creates reconciliation problems with financial consequences.
What is the difference between a native integration and a custom build?
A native integration is a vendor-maintained connector configured through the interface. A custom build is code written against the API, maintained by whoever wrote it. Native is faster and cheaper where it exists; custom is the only option for systems with no connector and the only route when the data needs transformation on the way through.
How many integrations can one HubSpot account support?
There is no practical cap on connections, but each one adds maintenance. The constraint in practice is how many integrations the team can monitor and repair, not how many the platform accepts.
Do you need Data Hub for enterprise integrations?
Not for custom builds. A private app runs against the API endpoints directly and needs no data sync seats. Data Hub, renamed from Operations Hub, becomes valuable when several systems need ongoing two-way sync and data quality automation is required across them.
How long does an enterprise HubSpot integration take to build?
Scope determines it more than complexity. Single-system integrations such as the Rev.io build are completed in three months. Multi-system programs including a migration, such as Pinnacle Bank's 10-plus system consolidation, run around five months.