The HubSpot Salesforce Sync Does Not Backfill History

The most expensive misunderstanding in a Salesforce to HubSpot project is treating the integration as the migration.

They are different things. The HubSpot Salesforce integration is an ongoing two-way sync designed to keep two live systems in step. A migration is a one-time move of history from one system to another. The integration does the first job well and does not do the second at all, and the sentence in HubSpot's own documentation that establishes this is easy to read past.

The sentence that governs the whole project

HubSpot documents that sales emails, tasks, meetings, notes and sales content views sync between the two systems, and then adds the qualifier: activities from prior to the contact sync will not be synced retroactively.

Read that carefully, because it is the difference between a two week project and a two month one.

Turn the integration on today, and a contact who starts syncing today brings nothing behind them. Their HubSpot timeline begins now. Every call logged in Salesforce over the previous four years stays in Salesforce.

For a client running both systems side by side, that is completely fine and often desirable. For a client moving off Salesforce, it means the thing they care most about, the history, is not covered by the tool they assumed covered it.

Establish which project you are doing in the first conversation. "Are we connecting two systems that will both keep running, or are we leaving one behind?" The answer changes the architecture, the quote and the timeline.

What genuinely needs separate work

Assuming you are migrating rather than connecting, four categories need explicit scope, and each one gets missed.

Historical activity. Calls, meetings, emails and notes that predate the sync. This is usually the largest single component and it is the one clients assume is free. Decide with them how much history is genuinely needed, because the honest answer is rarely "all of it." Ninety days of activity covers almost every operational need; four years covers a feeling. That conversation, held early, is worth more to the budget than any technical optimisation.

Attachments and files. Attachments are not among the activity types documented as syncing. Treat file migration as its own workstream with its own decision about what actually matters. Contracts and signed documents usually do. Screenshots from 2019 usually do not.

Association structure. This is the one that produces silent data loss, because a flat export and import creates all the records and none of the relationships. The reliable method is unglamorous: export both objects, build the parent and child mapping in a spreadsheet keyed on stable identifiers, and import the associations as their own pass once both sets of records exist in HubSpot. Remember that HubSpot imports create or update and never append, so the association file needs one child per row with the parent's identifier on it, and the parents have to exist first.

Web analytics history. This one never moves, from any system, and it is worth saying plainly to the client before they discover it. HubSpot's page view and visitor data is generated by its own tracking code. A contact's browsing history in HubSpot starts on the day the code goes live on the site. There is no import for it and no vendor who can supply one.

Scope by objects, not by contacts

The estimating error we see most often on migration quotes is pricing from the contact count.

Contacts are the smallest part of the job. Every note, call, email, meeting, task and association is a separate object that has to be extracted, mapped, transformed and loaded, and each carries its own failure modes.

On one migration we ran, moving 508 contacts with 90 days of activity history came to roughly 14,000 objects, kept in real-time sync during the transition. Quoted on the contact count, that job is trivial. Quoted on the object count, it is a real project, and the object count is the one that predicts the hours.

The three scoping questions that actually move a migration estimate:

1. How many records, per object type? Not just contacts.
2. How much history, in months? And which activity types within that window.
3. How many custom fields, and how many of them are still used? A field with a two percent fill rate is a decision, not a mapping.

The third question routinely removes more work than the first two combined. Clients migrate fields because they exist, not because anyone uses them, and asking for the fill rate per field is the cheapest scope reduction available.

The fields question, done properly

The single highest-leverage hour on any migration is the one spent deciding which fields do not come across, and almost nobody spends it.

The default behaviour is to migrate everything, because deleting things feels risky and mapping a field costs only a few minutes. Multiply a few minutes by four hundred fields, add the testing, the reporting rebuild and the ongoing maintenance of properties nobody fills in, and it is the largest avoidable cost in the project.

The method:

1. Export the field list with fill rates. For every field, what percentage of records have a value. This is the entire basis of the conversation and it takes minutes to produce.

2. Sort ascending and draw a line. Fields under a few percent fill are candidates for the cut. Some will be legitimately rare and important, and the client will tell you which. Most will be fields somebody created for a project that ended in 2021.

3. Ask what reads it, not what it holds. The useful question is never "do we need this field," to which the answer is always yes. It is "which report, list, workflow or integration would break if this field did not exist." A field nothing reads is a field nothing needs.

4. Archive rather than discard. Keep the full source export somewhere retrievable. It costs nothing and it converts "we deleted your data" into "it is in the archive if you ever need it," which is a much easier sentence.

5. Put the cut list in the mapping document and get it signed. In writing, before the migration runs. This is the document you will point at in month three when somebody asks where a field went, and it turns a potential dispute into a decision the client made.

On a portal we audited, 101 custom properties had under one percent fill and 44 had never been used at all. Migrating those would have been billable work producing nothing but future confusion.

Sequence, because order is not negotiable

The pass structure we use, and the reason for each:

1. Field and object mapping, agreed in writing. Before any data moves. This is the document you will refer back to when someone asks in month three why a field is empty.
2. Companies. Parents before children.
3. Contacts, associated to companies on import.
4. Deals, associated to both.
5. Activity history, as its own pass against records that already exist.
6. Associations that could not be expressed inline, from the mapping spreadsheet.
7. Reconciliation after every pass, not at the end. Record counts, association counts, and ten records opened by hand.

Steps two through four cannot be reordered, because an association can only be created if the record on the other end already exists. Step seven is the one people skip under time pressure, and skipping it means that when the totals are wrong at the end you cannot tell which pass caused it.

Run both systems for a period

For any migration with a live sales team attached, plan a parallel period rather than a cutover moment. The integration is genuinely useful here, in the role it was designed for: keeping both systems current while people move over.

Two things to accept during that window.

You will have duplicate data, and that is the correct trade. Tag records in both environments so you can tell later what came from where. Duplicated data you can identify is recoverable; missing data is not.

Decide the system of record explicitly, and put a date on it. "Salesforce is authoritative until the fifteenth, HubSpot after." Ambiguity here is what produces two versions of the truth and a very unhappy sales director.

What to tell the client before they sign

Four sentences that prevent most migration disappointment, and they are better said in the sales conversation than in week six:

• "The integration keeps two live systems in step. It does not bring your history across. Moving history is separate work and here is what it costs."
• "Your website visitor history starts the day we install the tracking code. Nothing can bring that across, from any platform."
• "We are going to ask you which fields you actually use, and the answer will make this project cheaper."
• "You will run both systems for a few weeks and you will see some duplicate data during that period. That is deliberate."

None of these are bad news if said early. All of them are bad news if said late.

The bottom line

The HubSpot Salesforce integration syncs going forward and does not backfill history. Historical activity, attachments, association structure and web analytics all need separate treatment, and web analytics cannot be moved at all. Scope by object count and history depth, sequence parents before children and associations last, and reconcile after every pass.

For the field-by-field version of what does and does not come across, including the objects the connector syncs and the items that always get rebuilt by hand, we keep that on our Salesforce to HubSpot migration page.

If you are quoting a client off Salesforce and want the object-count version of the estimate rather than the contact-count version, our white-label HubSpot migration team scopes and delivers these under partner brands.