Why Your HubSpot Import Overwrote Records Instead of Adding to Them

The sentence that explains most bad HubSpot imports is short: there is no append.

HubSpot's import tool creates records or updates them. Those are the only two things it does. If a property already holds a value and your file maps a value to that property, the file wins. If your file contains the same record on eight rows, HubSpot does not gather those eight rows into one richer record; it applies them one after another, and the eighth row is what survives.

Once you hold that rule, the four most common import disasters stop being mysterious.

The association failure, which is the expensive one

The classic version: an agency needs to attach a list of child records to a set of parents, so they build a file with the parent repeated down column A and a different child on each row. Perfectly readable to a human. Wrong shape for the tool.

Because there is no append, each row that names the parent is an instruction about the parent, not an addition to it. You end up with the last relationship in the file and none of the others, and because the import reports success, nobody looks until a report comes back short.

The correct structure, per HubSpot's own guidance, is the reverse of what feels natural:

• One row per child record, not per parent.
• The parent's Record ID or domain in the association column on each of those rows.
• The parent records must already exist in the CRM before you import the children. Creating both in one pass is where people get caught.
• Association labels go in their own column, and only if you actually want labelled relationships.

For multi-object imports, HubSpot supports one or more files that create and update records and associate them, but the same principle governs: the association is expressed on the many side, pointing at the one side.

The tell that you have got this wrong is an import summary reporting the row count you expected with a record count you did not.

Email is the primary unique identifier, and it behaves accordingly

The second rule that surprises people: you can mark other properties as unique identifiers in HubSpot, but for contacts, email is the primary one. Deduplication resolves on it first.

That has a consequence nobody plans for. If a person submits a form again using the same email address and a different postal address, phone number or job title, the new values replace the old ones. Silently. There is no merge prompt, no conflict, no flag. The record is simply different afterwards.

We found this on a client's application flow where people were legitimately resubmitting with updated details, and the team had assumed HubSpot was keeping a history. It was not. The property held the most recent submission and the earlier value was gone.

Two designs prevent it, depending on what the client actually needs:

If you need the history, stop writing repeated submissions into the same properties. Send them to a separate object or to a record of the submission itself, and let the contact properties hold the current state deliberately rather than accidentally.

If you only need the current value but need to know it changed, add a date stamp property and a workflow that writes to it when the property changes. You lose the old value but you keep the fact of the change, which is often all the client wanted.

The four checks that prevent almost all of it

1. Export before you import. Every time, no exceptions, including the imports that are "just a small update." The pre-import export is the only rollback you can rely on. HubSpot does offer an import rollback, and it is genuinely useful for reversing record creation and property updates from a specific import, but it is not a general-purpose time machine for what a property held beforehand in every scenario. Two minutes of exporting is cheaper than the alternative on any file that matters.

2. Test ten rows. Not one, and not the whole file. Ten representative rows including at least one record that already exists, one with a missing value, and one edge case you are worried about. Then open the resulting records and look at them, rather than reading the import summary and assuming.

3. Map every column deliberately. The mapping screen guesses, and it guesses well enough to be dangerous. A column called "Owner" can map to something you did not intend. Anything you do not want written should be excluded from the file entirely rather than left unmapped, because unmapped columns are one accidental click from being mapped.

4. Know which properties you are about to blank. An empty cell in a mapped column can clear an existing value. If your export-and-edit workflow dropped a column of data somewhere in the middle, the import will faithfully write that emptiness into the CRM.

What this looks like at migration scale

On a single tidy-up import these rules are hygiene. On a migration they are the project.

The pattern we use on HubSpot migration work for partner agencies:

1. Establish the unique identifier per object before writing any file. Contacts resolve on email. Everything else needs a decision, and that decision has to be stable across every file in the migration. If the source system's identifier is not going to survive, create a property to hold it during the migration so you can join on something.
2. Import parents before children, always. Companies before contacts, deals after both. Every association depends on the other side already existing.
3. Import in passes rather than one wide file. Records first, then associations, then the enrichment properties. A single file trying to do all three is a single file that fails as a unit.
4. Reconcile after each pass. Record count, association count, and a spot check of ten records opened by hand. Do this at each stage rather than at the end, because at the end you cannot tell which pass caused the discrepancy.
5. Keep the source file, the mapping and the import ID. When someone asks in six weeks why a field looks wrong, that trio is the only way to answer.

Scope migrations by object count and history depth, not contact count. On one migration we imported roughly 14,000 objects to carry 508 contacts with 90 days of activity history. Quoting that job on the contact count would have under-priced it by an order of magnitude.

What to do when it has already gone wrong

Most people find this article after the import, not before. The recovery order matters, and the instinct to start fixing immediately is the wrong one.

1. Stop everything that writes. Pause any workflow, integration or scheduled import that touches the affected properties. If something else is still writing while you assess, you will not be able to tell what your import did from what has happened since.

2. Establish the blast radius before you repair anything. Which properties, how many records, and over what time window. The import history in HubSpot tells you the record count and the timestamp. Do not trust your memory of what was in the file; open the file.

3. Check whether the import rollback applies. HubSpot can reverse a recent import, undoing the records it created and the property updates it made. This is genuinely useful and it is the fastest path when it fits. It is not a universal restore of prior state in every scenario, so read what it says it will do before relying on it.

4. If rollback is not available, use your pre-import export. This is the moment the two minutes you spent exporting either saves the day or does not exist. Reconstruct the affected properties from it and re-import the correct values.

5. If you have no export, mine the property history. Every property change is recorded on the record. For a small number of records this is recoverable by hand. For thousands it is a data engineering exercise via the API, and it is expensive, which is the argument for step zero being an export.

6. Only then repair associations. Associations are the hardest thing to reconstruct because the evidence of what used to be associated is often gone entirely. If the source data still exists in the system you exported from, rebuild from there rather than from HubSpot.

7. Write down what happened. Not for ceremony. In six weeks somebody will find an odd record and the question will be whether it was the import. A dated note naming the import ID, the properties touched and the records affected answers that in thirty seconds.

The uncomfortable lesson from every one of these we have worked: the recovery is always more expensive than the prevention, usually by an order of magnitude, and the prevention is a two minute export.

Two smaller traps in the same tool

Long dropdowns have no type-ahead. If your import is populating a dropdown property with a large option list, the humans who maintain those records afterwards have to scroll. On properties with dozens of options this makes the field effectively unusable, and the fix is a cascading pair of dependent fields rather than one long list. Worth deciding before the import, because changing a property's structure afterwards means another import.

Import errors are per row, not per file. A file can report success with a meaningful number of rows skipped. Open the error report every time rather than reading the headline. HubSpot documents the common error types, and most of them are shaped like a data problem you can fix in the file in five minutes.

The bottom line

HubSpot imports create or update. There is no append, so repeated rows overwrite, and email is the identifier contacts resolve on, so a resubmission replaces rather than supplements. Structure association files one child per row with the parent's ID, import parents first, export before you run anything, and test ten rows.

If you are moving a client onto HubSpot and the data shape is the part keeping you awake, that is the work our white-label HubSpot migration team does under partner brands every week. Our step-by-step guide to importing data into HubSpot covers the mechanics of the tool itself in more depth.