The Five Things That Break in Every HubSpot Migration

The interesting failures in a migration are not the ones where data goes missing. Those get caught, because somebody counts.

The expensive ones are where everything arrives, reconciles, and then behaves wrongly. Five of these recur so reliably that we check for all of them on every project, whatever the client is coming from.

1. Matching, which either duplicates or collapses

The governing behaviour: HubSpot imports create or update. They never append.

Every downstream surprise follows from that sentence, and it fails in two opposite directions.

Too many records. Rows without a usable matching identifier create new records rather than updating existing ones. A file keyed on email will not match contacts that have no email address, and those are exactly the records a migration carries in bulk: historical contacts, imported lists, records created by an integration that never captured one.

Too few records. Rows sharing an identifier collapse into a single record. Two genuinely different people at the same company sharing a shared inbox address become one contact, and the second row silently overwrites the first rather than sitting alongside it.

Both are invisible in a total count that happens to look plausible, which is why counting alone does not prove a migration worked.

What we do instead, before the real import:

1. Profile the identifier column in the source file. How many rows are blank, how many are duplicated, and what does the duplication look like.
2. Decide the matching strategy per object explicitly, and write it down. Email, a source record ID stored in a custom property, or a composite. Not whatever the tool defaults to.
3. Run the import on a subset first and read the results, rather than running it on everything and reading the summary.
4. Keep the source record ID on the record permanently. It costs one property and it is the only thing that makes reconciliation possible afterwards.

Point four is the one people skip and regret. Without a stable link back to the source system you cannot answer "did this record come across" except by eye.

2. Dates, which land a day early

This one produces the support ticket that reads "all our dates are wrong by one day," and the cause is arithmetic rather than a bug.

HubSpot's default date properties, including Create date and Last modified date, are date and time properties, and a date resolves to midnight UTC. HubSpot's own worked example: 1 May 2015 is stored as 01 May 2015 00:00:00 UTC, and an account set to UTC-04:00 Eastern Time displays that as 30 April 2015 at 20:00.

Every date in the file shifts backwards by the account's offset. On a portal in a negative offset, that is every date landing on the previous day.

Usually cosmetic. Occasionally not:

• Date-based workflow triggers phrased as a number of days ago now evaluate against a different day, and those triggers are checked at the start of the day rather than continuously, so the error compounds with a delay.
• Contract, renewal and anniversary dates used to drive customer communication go out a day early, which clients notice.
• Reporting periods built on month boundaries move records into the wrong month. A deal closed on 1 April reports in March.

Check it deliberately: import ten records with known dates, open them, and compare against the source before the full run. Then check the account timezone setting is what the client actually operates in, which on an inherited portal is often not the case.

3. Nobody you are allowed to email

The first campaign after the migration goes to nobody, because HubSpot's import tool creates contacts as non-marketing by default and a multi-file import always does. Non-marketing contacts do not receive marketing email.

Since a migration is almost always a multi-file import, this catches nearly everyone once. It is worth its own treatment, and we have written it up in why you cannot email the contacts you just migrated, including the opt-out list sequencing that stops a suppression file inflating the billable database.

The short version for a checklist: confirm the marketing contact count against the number you expected before the first send is scheduled.

4. Automations, failing in both directions

The symptom is either silence or a catastrophe, and the same setting causes both.

Records enrol in a HubSpot workflow the first time they meet the triggers, and re-enrollment is off by default. After a migration, every record met the criteria before the workflow existed. So when the workflow is switched on and told to enrol only records that qualify afterwards, it never sees the database at all.

Answer that prompt the other way without auditing the actions, and every action executes against the whole loaded set at once: marketing emails sent, tasks created, owners notified, forty thousand times.

The full set of causes, including merged records and list membership timing, is in why HubSpot workflows do not enroll migrated contacts.

The rule that covers both directions: load with automations off, and decide per workflow whether the existing database should be enrolled at all. Many should not. A welcome sequence rebuilt for future signups has no business running against four years of migrated history.

5. Something still pointed at the old system

The last one is not a data problem, and it is the one that produces the most awkward phone call, because it surfaces weeks later.

The systems that keep talking to the platform the client just left:

• Embedded forms on the website, still posting to the old platform. Leads keep arriving somewhere nobody is looking.
• Tracking scripts, still firing, still recording behaviour into a system nobody reads.
• Billing, ERP or finance feeds that read customer records from the old system on a schedule.
• Scheduled exports and reporting extracts feeding a spreadsheet or a warehouse, which keep running and keep producing plausible, stale numbers.
• Calendar and meeting links on email signatures, in documents and on the site, pointing at the old scheduler.
• Anything with an API key issued years ago by somebody who has left.

What makes these hard is that none of them break. They carry on working, quietly, against the wrong system. A broken integration announces itself; a correct integration pointed at a dead platform does not.

The inventory has to be built by asking rather than by scanning, because the ones that matter are usually undocumented. The questions that surface them: what reads customer data on a schedule, what writes into it, and what has a form on it. Then walk the website, because embedded forms are the single most common survivor.

The reconciliation habit

The check that catches most of the five, and the one skipped under deadline pressure:

Reconcile after every pass, not at the end. Record counts per object, association counts, and ten records opened and read by a person.

Reconciling only at the end tells you that the totals are wrong without telling you which pass caused it, and by then the passes have run in sequence and the causes have compounded. Reconciling per pass costs a few minutes and turns a forensic exercise into a correction.

The ten records read by hand matter more than the counts. Counts confirm quantity. Only a person opening a record notices that the dates are a day out, the company association points at the wrong parent, or the notes came across without their authors.

The bottom line

Imports create or update and never append, so matching either duplicates or collapses records. Dates resolve to midnight UTC and land a day early on a negative offset. Migrated contacts are loaded as non-marketing and cannot be emailed. Workflows either enrol nobody or enrol everybody. And something on the website is still posting to the old platform.

Profile the identifiers before importing, keep the source record ID permanently, check ten dates by hand, confirm the marketing count before the first send, load with automations off, and build the integration inventory by asking rather than scanning.

If your agency would rather hand the whole sequence to someone who has run it before, our white-label HubSpot migration team scopes and delivers these under partner brands, and our portal audit work finds the ones that were missed on somebody else's project.