Best way to import master sheet when some contacts and deals already exist in HubSpot?

Smart CRM & Sales Hub Tips, Tricks & Best Practices
,
1

Title: Best way to import master sheet when some contacts and deals already exist in HubSpot?

Hi everyone,

I’m working on a data import project and facing a challenge. The client shared a master sheet containing company, contact, and deal information (company name, contact name, email, lead source, account manager, deal stage, etc.).

However, the issue is that some of these contacts and deals already exist in HubSpot, because they were previously added manually by the sales team. Now the master sheet also contains those same contacts and deals.

My concerns are:

  • If I import the sheet directly, duplicate contacts or deals might be created.
  • Some deals in HubSpot are already associated with contacts, and I don’t want to break those relationships.
  • I also want to ensure that existing records are updated instead of duplicated where possible.

What would be the best approach to handle this import safely?

Specifically, I would appreciate guidance on:

  1. Best way to identify existing contacts and deals before import
  2. How to update existing records instead of creating duplicates
  3. Recommended import structure (Contacts → Companies → Deals or combined import?)
  4. Any best practices for large CRM data cleanup before importing a master sheet

If anyone has handled similar CRM migrations or master sheet imports, I’d really appreciate your advice.

Thanks in advance!

2

Hi @Arsath,

Do all contacts in your CRM and in the import file have an email address? If so, there’s no risk of duplicate contacts, HubSpot deduplicates by email address. Deduplicate records in HubSpot

If you don’t have an email address, things become tricky already. You’ll need find another way to safely match contacts in your file and in HubSpot. By first and last name could be an option, then again this can go wrong easily for common names.

If you go with first and last name, you would first have to export your contacts from HubSpot, then use VLOOKUP or similar to “enrich” your import file with the contact record IDs from your HubSpot export. When you re-import, you can then map the record ID and HubSpot will update those records in place.

If there are net new contacts in your import file, that would have to be a second, separate import.

For deals, there is no default identifier besides the record ID - so you’ll have to also first export your deals, and - likely by deal name - “enrich” your import file with the deal record IDs that you just exported. Upon import, you can then map the record ID.

Again, for net new deals, separate import.

If you update contacts and deals separately, no associations will be changed. Neither will new associations be established. If you want to update and create associations, one option is to import them together.

It’s also possible to later associate records via workflow, but this would require a matching property value on contact and deal. If that’s something you can guarantee during import, this lets you do separate imports, then associate once in HubSpot.

Overall, if you can dry-run this export/import in a sandbox, I strongly recommend it.

There is unfortunately no safe + easy + native way to do this. And if you do not have anything to safely match by (contact names, deal names), then the first and biggest task is going to be figure out what you could match by.

Best regards

3

Hi @Arsath,

If your master sheet contains a mix of new + existing contacts, companies, and deals, the safest and most reliable approach is to avoid a single bulk import when data is mixed at scale and instead control how records are updated and associated.

Step 1: Export existing data (critical)

Export existing records from HubSpot and include:

  • Record ID
  • Email (contacts)
  • Company domain (companies)

This ensures existing records are updated instead of duplicated.

Step 2: Split into structured imports

While HubSpot supports multi-object imports, splitting your data gives you better control when mixing new + existing records:

  1. Companies
    • Use the Company domain or the Record ID
  2. Contacts
    • Use Email
    • Include the Company domain for association
  3. Deals
    • Use Record ID for updates
    • For new deals, no ID is required
    • Include Contact Email or Company Domain for associations

Step 3: Import in order

  1. Companies
  2. Contacts
  3. Deals

This ensures associations are created correctly.

Step 4: Associations (if needed)

HubSpot can create associations during import if mapped correctly.
For more complex relationships, you can run a separate association import using Record IDs.

Avoid

  • Relying on names instead of unique identifiers
  • Mixing inconsistent identifiers (causes duplicates)
  • Importing large mixed datasets without validation

Use unique identifiers to control updates, and structure imports to maintain clean associations.

This approach minimizes duplicates and gives you full control over your CRM data.

4

The email dedup point is correct for contacts, but a few edge cases worth flagging:

1. Field mapping is the hidden risk. If your master sheet has column names that do not exactly match HubSpot property names (e.g. “Account Manager” vs “Contact Owner”, or “Lead Stage” vs “dealstage”), HubSpot either skips those columns or gives you a manual mapping step every time. For a one-time import manageable, but painful at scale.

2. Company dedup works differently from contacts. HubSpot uses Company Domain Name for dedup, not company name. If your sheet has company names but not domains, you can end up with duplicate company records even when contacts dedup cleanly.

3. Deal dedup has no native solution in HubSpot — every import creates new deal records. You need to filter carefully pre-import to exclude deals that already exist.

For the field mapping challenge specifically: I built a tool called Emport (emport.io) that auto-maps CSV columns to HubSpot properties using AI — handles non-standard column names without manual renaming. Still beta but built exactly for multi-object imports like this one.