Why You Cannot Email the Contacts You Just Migrated

The migration went well. Records reconciled, associations held, the client signed off. Two days later marketing scheduled the first send to the newly migrated list, and it went to nobody.

Nothing is broken. The contacts are there, the email addresses are correct, and the list is populated. They are simply not marketing contacts, and HubSpot will not send marketing email to a contact that is not one.

The default that causes it

HubSpot's import tool creates contacts as non-marketing by default. On a single object import you can change that: the Details step carries a checkbox to set the contacts as marketing, and you confirm the estimated count before the import runs.

On a multiple object or multiple file import, there is no checkbox. Those contacts are always created as non-marketing.

That is the whole problem, because a migration is almost never a single object import. You are moving companies, contacts, deals and activities, usually as several related files in one job so the associations resolve. That is precisely the shape of import that has no marketing option.

So the setting most likely to matter is the one the migration path cannot reach.

It is not just the import tool

The same default applies to the routes people use when they are trying to avoid the import tool. HubSpot documents that any integration or API creates contacts as non-marketing by default.

That closes the obvious escape route. Running the migration through a connector or a custom script does not sidestep the behaviour, it reproduces it. Every bulk path into the portal lands in the same state.

The contrast that explains why this surprises everyone: HubSpot forms set contacts as marketing by default. Day-to-day, contacts arrive through forms, they are marketing contacts, and nobody thinks about the property at all. The first time anyone meets it is the first bulk load, which is usually a migration, which is usually the highest-stakes moment available.

Why the default exists

Worth understanding rather than resenting, because it changes how you handle the fix.

Marketing contact status is what your contact tier is measured against. A contact marked as a marketing contact counts toward the tier for the billing period. A non-marketing contact does not.

If imports defaulted to marketing, any bulk load could change what the portal costs without anyone deciding to. Defaulting to non-marketing means the expensive direction requires an explicit action, which is the right way round.

The consequence for you is that turning the migrated set into marketing contacts is a commercial decision, not a cleanup task. It belongs in the migration plan, agreed with whoever owns the client's HubSpot bill, and not in a Friday afternoon bulk edit by whoever noticed the campaign had failed.

The conversation to have before the import

Ask one question during scoping: of the records we are moving, which ones will actually be marketed to?

The answer is never all of them. Migrated databases carry closed-lost contacts from four years ago, former employees at client companies, duplicate personal addresses, and entire segments the client stopped emailing long before they decided to change platforms.

Non-marketing contacts still exist, still hold their history, still associate to deals, and still support sales activity. They just do not receive marketing email and do not count toward the tier. For a large share of a migrated database, that is the correct end state and not a compromise.

Running that filter deliberately is one of the few points in a migration where careful scoping visibly reduces what the client pays, which makes it an easy conversation to have.

Fixing a set that is already loaded

If the import has already run, the remedy is straightforward:

1. Build a list of the records that should be marketing contacts, using the filter you agreed rather than selecting everything.
2. Set them as marketing, either in bulk from the contacts index page or through a workflow.
3. Confirm the count before you commit, because it is the number the tier is measured against.
4. Re-check the send. Do not assume the fix worked because the property changed; look at the recipient count on the next scheduled email.

Step one is where the discipline is. The reflex after a failed send is to select everything and switch it on, which works, and which quietly moves the whole migrated database onto the billable side of the line.

What a non-marketing contact can still do

Worth knowing, because the reflex on discovering the status is to treat it as damage and reverse it wholesale.

A non-marketing contact is a full CRM record. It holds its properties and its history, it associates to companies and deals, it appears in reports, it can be enrolled in workflows, and the sales team can work it and email it one to one. The only thing it cannot receive is marketing email.

So for a large part of a migrated database, non-marketing is the right permanent state rather than a problem to fix. Closed-lost contacts from four years ago, former employees at client companies, records the client stopped emailing long before the platform change: all of them are worth keeping, none of them are worth paying to market to.

Framing it that way changes the conversation with the client from "the import went wrong" to "here is a decision you get to make," which is both more accurate and considerably easier.

Timing the switch

One scheduling detail that catches people out. Marketing status is what the contact tier is measured against for the billing period, so the moment you flip a large set is the moment the tier is affected.

Two habits:

• Flip once, deliberately, with the number agreed. Not in stages across a fortnight as different people notice different campaigns failing, which produces a tier change nobody can explain afterwards.
• Do it close to the first genuine send, not on the day the data lands. There is no benefit to carrying a marketing-eligible database through the reconciliation period, and reconciliation is exactly when somebody is most likely to send a test to the wrong list.

The neighbouring trap: opt-out lists

While you are working on who can be emailed, there is a second import behaviour worth knowing, because it is the one that produces an expensive surprise in the opposite direction.

Importing an opt-out list marks email addresses as ineligible to receive marketing email and sets the Unsubscribed from all email property to true. Usefully, contacts added this way are not created as contacts and are not added to your billable contact total. Feeding a suppression list from the old platform into HubSpot does not inflate the database.

The caveat is specific and easy to miss: if those addresses already exist as HubSpot contacts, they become unsubscribed but remain billable. HubSpot's documented route around that is to delete the contacts first, then re-import the addresses as opted out.

Sequence matters here. Import the suppression list before the main contact load and the addresses stay out of the database entirely. Import it afterwards and you have paid to hold records you are not allowed to email.

The check that prevents all of this

Before the first send after any bulk load, three things, in five minutes:

• Marketing contact count against the number you expected. If it is zero, the import default is why.
• Unsubscribed from all email across the loaded set, compared against the suppression list from the source platform. Both a much larger and a much smaller number than expected are worth investigating.
• A test send to a small internal segment drawn from the migrated records specifically, not from a contact created by a form during testing. Test contacts created through forms are marketing contacts by default and will happily receive the email that the real migrated records cannot.

That last one is the check that catches this before the client does. A test that passes on a contact created the normal way tells you nothing about a database that arrived the other way.

Why this survives handovers

Marketing contact status leaves no error behind. The import succeeds. The records are correct. The email sends without failing. There is simply nobody in the audience.

On a portal you have inherited, the tell is a marketing contact count that sits well below the total contact count with no apparent reason, usually alongside a team that has quietly concluded HubSpot's email tool is unreliable. It is a standard finding in our portal audit work, and it is almost always traceable to one bulk load nobody documented.

The bottom line

HubSpot imports create non-marketing contacts by default, multi-object and multi-file imports always do, and integrations and the API do the same. Non-marketing contacts cannot receive marketing email, so the first campaign after a migration reaches nobody.

Decide during scoping which migrated records will genuinely be marketed to, set only those as marketing, load the suppression list before the contacts rather than after, and check the marketing count before the first send is scheduled.

If your agency is inheriting portals where the email tool looks broken and the real cause is a bulk load from years ago, that diagnosis is standard work for our white-label HubSpot support team, delivered under your brand.