HubSpot + sales-i and Pronto Xi integration

Distributors rarely start this conversation wanting an integration. They want to leave a tool. Years of account history, quotes and call logs have accumulated in a sales intelligence layer that reads the order book, the business has decided HubSpot is where selling will happen from now on, and somebody has to get the history across without losing the thread of a customer relationship that goes back a decade.

What makes it awkward is the shape of the data. A distributor’s account list is mostly dormant: web ordering accounts that have never spoken to a person, prospects created and forgotten, branches of the same customer recorded separately. Contacts are thin, because most accounts are just an account number. The call log, on the other hand, is thick and genuinely valuable: tens of thousands of records with a type, an outcome and a duration, which is the only written record of who has been looking after which customer.

Behind both sits the ERP. The sales intelligence layer has no database of its own to speak of, so an export from it is a snapshot of the ERP with a sales view applied. That matters for scoping, because the things a sales team asks for next, product history, live pricing, stock, are not in the export and never were. They are a second project against the ERP, and saying so early stops the migration from quietly turning into an integration halfway through.

Four objects move in the migration and a fifth follows later. Customers become companies, contacts become contacts, opportunities become deals, call notes become call engagements, and order and line history comes afterwards from the ERP.

Every object keys on its own source identifier, stored in a HubSpot property marked unique. The account number is the backbone: contacts, opportunities and notes all carry it, and it resolves cleanly, which is what makes the load order safe. Contacts never key on email. A distributor’s export routinely has thousands of contacts with no email and hundreds sharing a branch address, so an email key would merge unrelated people and discard the rest.

Calls are the exception to everything. HubSpot activities have no unique property, so a call cannot be upserted at all. They are created once, deduplicated against what is already in the portal, and they cannot be edited afterwards, which makes the first production run of calls the one moment in the project with no second chance.

The pattern is a batch migration. A transform step reads the export, applies the cleanup rules and writes HubSpot shaped records to disk. A load step creates the custom properties and the deal pipeline, then upserts each object in batches keyed on its source identifier, then runs a separate associations pass once every parent record exists. HubSpot API paths are pinned to version 2026-03.

Load order is a chain of gates: companies, then contacts, then deals, then calls, then associations, then reconciliation. Nothing advances until the count of records created plus updated matches the source and the failure count is zero or explained. Object identifiers are stable across re-runs, so the association pass resolves source keys to HubSpot records deterministically.

Every record carries a batch marker and a source system stamp. Those two fields are what makes the load reversible: they identify the cohort precisely, so it can be archived and reloaded after a transform fix without touching anything a user has since created.

The import screen is the route most teams try first, and it is the wrong tool for a load this shape. It caps a job at roughly two objects, which turns four objects and six association types into a chain of manual steps nobody can repeat identically in a second portal. A scripted batch upsert runs the same way twice: one credential swap between the sandbox rehearsal and the production run, against code that has already proven itself. The managed sync question arrives later, for the ongoing ERP feed over Pronto Connect, where a stable mapping on a schedule is exactly what a packaged tool is good at.

On a migration like this, three of the four failures are data problems rather than API ones.

1. Scope. We profile the export before promising anything: row counts, key uniqueness, how many fields are actually populated, and which columns are dead on arrival. That report is the scoping document.
2. Architect. We agree the object model, the unique keys, the pipeline and the cleanup rules in writing, because every one of them is expensive to change once records exist.
3. Build. Transform and load as separate steps, batch upserts keyed on source identifiers, a separate associations pass, and a batch marker on every record.
4. Validate. The full chain runs against a sandbox portal behind a fail closed allowlist, is re-run to prove idempotency, and is reconciled object by object before production is scheduled.
5. Operate. After the load we reconcile counts, spot check records against the source, and hand over the rollback path along with the code.