HubSpot + Skyvia integration

Skyvia earns its place when the data already sits somewhere structured and the only real question is scheduling. A manufacturer whose orders live in a point of sale database, a distributor with an order table nobody outside finance can read, a wholesaler whose sales team retypes account numbers into the CRM: all of them want customers, orders and lines visible beside the deal record, and none of them want to commission a service, host it and watch it.

The other half of the appeal is ownership. A custom integration is an asset until the person who wrote it leaves, at which point it is a liability with a deployment pipeline. A managed sync is a mapping, a schedule and a run history, all of which a second engineer can pick up in an afternoon. That matters more than it sounds to a forty person business with no in-house developer.

The trade is explicit, and we say it before anyone signs anything. You get a mapping and a schedule. You do not get a webhook, a queue, or a place to put business rules that branch per record. When the mapping is stable, that trade is a bargain that pays for itself in the first month. When the rules shift every quarter, the same trade turns into a monthly bill for work that keeps needing a human.

Other pages on this site point here when they say a managed sync is the honest answer, because the decision below holds whatever the source system is.

A working workspace usually carries six or seven objects, and the order they load in matters as much as the mapping. Customers become companies, contacts become contacts, orders become deals, order lines become line items, items become products, and anything that is neither a company nor a deal, a delivery location for example, becomes a custom object.

Every object keys on the identifier the source already uses. Customer number, order number, stock keeping unit. Where the source has no single column to key on, an expression builds a composite: an order number joined to a line sequence, a customer number joined to a location code. Names are never keys, because a tidy-up in the source renames a company and splits it into two records in the portal.

Orders flow one way. HubSpot is a good place to see an order beside the relationship and a poor place to edit one, so the source system stays the system of record and the portal stays a read surface for it.

The shape is a managed SQL sync. An agent inside the client network holds the database connection and talks outbound only, so nothing needs a public address or an inbound firewall rule. Packages read the source views, apply expression and lookup mapping, and upsert into HubSpot on the business key.

Load order is as much of the design as the mapping. Parents load before children, because lookup mapping resolves an association by reading a HubSpot record that has to exist already: companies and products first, then deals and locations, then lines, then anything that updates a deal in place. Skyvia’s own guidance is to enforce that with an orchestration package rather than staggered start times, since a queued run can start late and invert the order.

The last step in the chain is usually a reconciliation of counts, because a sync that runs green and loads nothing looks exactly like a sync that worked.

Three questions settle it, in this order. How often does the data have to move? Hourly or slower keeps you on a packaged sync; anything approaching real time does not. How many records change in a month? Up to a few hundred thousand is comfortable; millions push you into a plan and a schedule that need real thought. Does the flow involve more than one source, parallel triggers, or logic that passes through several systems before it produces an answer?

One yes on the last question does not rule out a managed sync. Two usually does, and at that point the honest comparison is against 70 to 150 hours of custom build rather than against a cheaper subscription.

1. Scope. We read the source views, count the rows, and check every object for a modified timestamp, because that one fact decides the schedule.
2. Architect. We agree the keys, the load order and which side owns each field, then write the mapping down where the client can read it.
3. Build. Packages in a fixed order with expression and lookup mapping, pointed at a HubSpot sandbox portal first.
4. Validate. A full load into the sandbox, counts compared object by object, then a spot check of records that we know are awkward.
5. Operate. A monthly rhythm of watching the chain, re-running failed steps, and adjusting the mapping as the source system changes underneath it.