HubSpot + Dynamics GP integration

A company still on Dynamics GP is running software with a known end. Microsoft stopped selling GP to new customers, perpetual licences from April 2025 and subscriptions from April 2026, and ends product enhancements, tax updates and technical support at the end of December 2029, with security updates continuing to April 2031. Microsoft points GP customers toward Business Central. For a company still on GP the move is coming, and its timing is the company’s own decision.

Meanwhile sales has moved to HubSpot, and the questions it cannot answer are the usual ones for an ERP that runs on its own SQL Server: what this customer owes, what they have on order, whether the last invoice posted. GP answers them in SmartLists and reports that sellers never open, and a seller who asks finance gets the answer after the call.

So the decision on this page is less about capability than about time and money. The managed sync and the custom integration below both work. The question is how much to spend connecting a system with a few years of support left, and how to build the HubSpot side so that it outlives GP. Our answer is to spend little on the GP end, keep the feed one way, and put the care into the keys and properties HubSpot will keep after the move.

Every object in the table moves one way, and there are six. The customer master becomes the HubSpot company. The balance comes from a separate table rather than the master, which is why GP’s own integration tools treat the customer balance as a document type of its own. Items become products.

Contacts need care, because GP keeps them on addresses. Each customer address carries a single contact person and an internet-address record holding the email that documents are sent to. HubSpot contacts are built from those address rows, keyed on the customer ID plus the address ID, with email as the match where one exists.

Sales documents are split by state. Unposted documents sit in the sales work table, and a posted document belongs in the history table; Microsoft treats the same document in both as a fault. The feed reads both, keys every document on its type plus its number, the pair Microsoft’s own queries match on, and treats the move from work to history as a change of status, never a deletion. Open orders become deals, and posted invoices land on a custom object associated to the company.

The runtime is a managed sync over SQL, run on Skyvia. The Skyvia Agent is installed on a machine inside your network that can reach both the GP SQL Server and the internet, and it exchanges data with Skyvia in encrypted form with no public address or open port. In its alias mode, the SQL connection details stay in a file on that machine and never reach Skyvia’s servers.

GP already publishes its data for reporting through SQL views, which is what its Excel refreshable reports read. We add a small set of read-only views of our own, one per object, over the customer master, balances, addresses, open and posted sales documents and items, under a read-only SQL login.

Packages run on a schedule in load order: companies, then contacts, then deals and invoices, then the association pass. Each upserts on the GP key held in a custom HubSpot property, found by a lookup that returns nothing for a new record, so a new GP customer inserts and a known one updates. Every run ends with a count check against the views, and rows that fail validation go to an exceptions report.

The deciding factor on GP is the time left, and whether HubSpot must ever write into it. For a one-way feed, a managed sync on Skyvia is the smallest thing that works, and it is switched off on the day Business Central goes live.

A custom integration is the route when HubSpot has to create customers or orders in GP. Microsoft names Web Services for Microsoft Dynamics GP as the preferred tool for integrating data, with eConnect for objects the web services do not cover. Both run on your servers, and Microsoft has said it is not actively fixing issues found in some eConnect procedures, because of the product’s lifecycle. That is a lot of new machinery for a system with a few years left.

Nothing in the HubSpot App Marketplace covers GP. HubSpot’s Business Central app installs as an extension inside Business Central, and its Dynamics 365 app connects to a Dynamics 365 instance by its subdomain.

1. Scope. We confirm how many company databases feed HubSpot, the GP release, the date of any Business Central move, and who can grant a read-only SQL login and a machine for the agent.
2. Architect. We write the views, fix the keys, document type plus number included, and decide which HubSpot properties must outlive GP.
3. Build. Packages are built against a test company restored from a copy of the live database, writing to a HubSpot sandbox until cutover.
4. Validate. We reconcile customers, open documents and balances against GP reports, then walk the exceptions with whoever owns receivables.
5. Operate. We watch run history and the exceptions report, and at the Business Central cutover we freeze GP-sourced invoices as history and switch the feed off.