The first decision in moving email off HubSpot is a number: how many people the new platform may send to. The obvious number is the one HubSpot bills you for, its “marketing contacts” as opposed to HubSpot non-marketing contacts, and it is wrong in the direction that gets a sending domain blocked. On the portal we are moving this month, HubSpot counted 1,401 marketing contacts. 174 of them had unsubscribed from all email. 61 more had opted out of marketing mail, and 4 were quarantined. HubSpot was charging for every one of them and refusing to send to 239. A migration that loads the 1,401 as subscribers mails all 239 from a brand-new domain, in its first week, with no reputation to spend.
The audience that could legitimately receive the first campaign was 1,157. Getting from 1,401 to 1,157, and from there to a load the new platform will never let anyone undo by accident, is what this guide covers. It is written for the person who will run the load, and for the person who will be asked, afterward, how many people the company can email.
Why is “marketable” not a consent record?
HubSpot’s marketing contact flag is a billing status. 1 Definition 1 Marketing contact: HubSpot’s billable unit for Marketing Hub. A contact flagged marketable can be targeted by marketing email and counts toward the subscription tier. The flag is set by forms, imports, workflows, batch jobs and HubSpot’s own eligibility processing. It is not a record of consent. It says the contact counts toward your tier and can be put in a send. It says nothing about whether the person agreed to hear from you, and HubSpot stores that answer somewhere else entirely: an opt-out-from-everything property, an opt-out per subscription type, a hard bounce reason, a quarantine flag. The two kinds of field are written by different hands. The marketing flag is set by forms, imports, workflows, batch jobs and HubSpot’s own eligibility processing. The opt-out is set by the person, when they click the link.
So the two sets overlap. They do not partition. On this portal, 174 of the 246 contacts who had unsubscribed from everything were still flagged as marketing contacts, and still being paid for. In the other direction, 3,040 non-marketable contacts carried no opt-out, no bounce and no quarantine. Nobody had refused anything. They had been demoted by batch jobs, by integrations, by a browser extension and by HubSpot’s own processing. Billing and consent were two different columns, and the obvious migration reads only the first.
Our own first load plan made exactly that mistake. Written from the September audit, it treated “non-marketable” as the suppression set and “marketable” as the subscriber set, and would have loaded 1,418 subscribers. A fortnight later a full pull of every contact’s consent properties, which took about ten minutes over the API, showed the 174, and the plan was rewritten around a different number. Ten minutes is the whole cost of not re-subscribing 174 people. The rest of this guide is what the ten minutes showed and what to do with it.
The number to load is 3,709, then 1,157
Every contact gets one reason it may or may not be mailed, assigned by the strongest reason first. A contact that both bounced and unsubscribed is recorded as a bounce, because a bounce is the least reversible state and the raw columns are kept beside the derived one in case anyone wants a different precedence later.
On 4,879 contacts the reasons fell out like this. 254 had a hard bounce. 5 were quarantined. 246 had unsubscribed from all email. 97 had opted out of marketing email only. 67 were on the company’s own merged bad-contact list without any of the above. 3,040 were non-marketable with no other reason at all. 13 had no email address and could not be loaded. That leaves 1,157 with nothing against them, and those are the subscribers. 3,709 rows go in as not subscribed, 1,157 as subscribed.
Two things in that table deserve a second look. The 67 on the bad-contact list included two contacts HubSpot still counted as marketable; we suppressed them, because an API load can re-subscribe a contact later and the reverse mistake cannot be taken back as cheaply. And 21 contacts had bounced softly with no hard reason. HubSpot itself still sends to those, so they are not suppressed, but they are flagged risky so the warm-up ramp reaches them last. Four of the 21 are in the subscriber set.
The history of how the 246 opted out is worth reading, because one line of it points at the layer the export cannot see. 227 came through the unsubscribe link. 4 were set by staff. 3 arrived through the one-click header mailbox providers now require. And 12 were carried over when a deleted contact was re-created, which is HubSpot doing the right thing: it keeps an address’s unsubscribe after the contact record is gone. The right thing, scaled up, is the trap. The portal was refusing to mail 6,714 addresses while its contact export showed 602 with a reason, and 6,194 of those addresses belonged to deleted contacts; that story is told in full in what a HubSpot export will not give you. What matters here is the load decision. All 6,194 go into the new platform as suppression-only rows, with no name and no CRM record, so that a spreadsheet someone finds in 2028 and imports cannot re-subscribe a single one of them. On a platform that bills on subscribed contacts, those rows cost nothing. 2 Source 2 The platform’s pricing page, read on 2026-10-05: the free plan has unlimited contacts and is limited to 4,000 sends per 30 days to the 1,000 newest contacts; paid plans are priced on subscribed contacts only. Whether unsubscribed rows count toward the newest 1,000 is not stated. Re-read on the day of publication.
HubSpot was charging for every one of them and refusing to send to 239. A migration that loads the 1,401 as subscribers mails all 239 from a brand-new domain.
Load the HubSpot suppression list first
The order is fixed. The 3,709 contact-level suppressions load first. Then the 6,194 portal-only addresses. Then, and only after both loads have fully succeeded and the 1,157 have been through a list-verification service, the subscribers. The check at the end is arithmetic: the platform should hold 11,060 addresses (4,866 loadable contacts plus 6,194), of which 1,157 less the verification failures are subscribed. Both figures get re-derived from a fresh pull on load day, because the old portal is still sending and still collecting unsubscribes, about one every two days.
The route matters more than the order, and it points the opposite way from the obvious choice. On the platform this company is moving to, the CSV importer is the documented path for bulk. It also will not re-subscribe anyone it has already marked unsubscribed. A later file with the subscribed column set to true does nothing, silently. So a mistake made through the importer cannot be corrected by the same route. The API honors the subscribed flag in both directions, which is why the load runs as one API call per contact, 4,866 calls at the platform’s rate limit, about eight minutes.
Notice that this cuts both ways. The API’s willingness to re-subscribe is the reason an API load from the wrong set is dangerous, and the reason suppression goes in before a single subscriber. If the subscriber file is wrong, the damage is 174 people re-subscribed. If the suppression file is loaded second, the damage is the same 174 people re-subscribed by the subscriber file and then suppressed again, having possibly received a send in between.
There is an escape hatch and it is small. The platform’s endpoint for removing a suppression is capped at 100 removals, and the quota can be queried before acting. 3 Editor's note 3 The un-suppression quota. The platform’s suppression endpoints return a removal quota with a limit of 100 and a remaining count, so the quota can be checked per contact before acting. A 30-day renewal window is not in the vendor’s documentation, and we have not verified it. Plan as if the load has one chance. We plan as if the load has one chance to be right, and the read-back at the end of this guide is how we earn that.
Two rules on the new platform are permanent, and they shape the field design before the first row goes in. Never express suppression as membership of a mailing list: a contact who unsubscribes from a list through the preference center can never be re-subscribed by the team, by any method. And properties cannot be renamed or retyped once created, so the field that records why a contact is suppressed, and the field that carries the old CRM identifier, have to be named and typed correctly the first time. They are the two fields a future audit will lean on.
Plan limits, for completeness, block none of this. The free tier carries unlimited contacts; its real limit is 4,000 sends per 30 days to the 1,000 newest contacts, and 1,157 subscribers is more than 1,000, so production sending needs a paid plan regardless. Loading subscribers last keeps them the newest whichever way that limit is read.
Fourteen lists, and only one of them changes the load
Every HubSpot portal has a set of lists with “suppression,” “DNC,” “unqualified” or “bad” in the name, and the instinct is to load their members as unsubscribed. On this portal there were 14 such lists holding 5,708 memberships across 3,244 distinct contacts. We read each list’s filter definition rather than its name. Two of them, the unsubscribed list and the hard-bounce list, restate consent and bounce state the contact properties already hold, so they add nothing to the load. Only one, the merged bad-contact list, drives unsubscribed on its own, and it is the 67 in the table above.
The other eleven are targeting decisions. Unengaged after eight or more sends with no opens. Never opened anything. Lead status unqualified. Lifecycle stage customer or opportunity, kept out of the prospect nurture. One hand-picked “re-engage or delete” list of 505 that cannot be recomputed from any property. None of these people refused anything. Load all fourteen lists as unsubscribed and you have suppressed 3,244 contacts on the strength of list names, most of them people who never opted out, and the importer cannot bring them back.
So each list becomes a column on the contact instead, and a segment on the new platform excludes it. The marketer keeps every exclusion she had, as something she can edit, and nobody’s consent state has been touched.
The same columns hand you the warm-up ramp for free. Among the 1,157 subscribers, 545 were on the unengaged list, 426 on the manual re-engage list and 166 on the nurture suppression list. A new domain has no reputation, and mailbox providers judge it on its first weeks; Google’s guidelines for bulk senders ask for a reported spam rate under 0.1%, never above 0.3%. 4 Source 4 Google Workspace Admin Help, “Email sender guidelines,” in force for bulk senders since February 2024. Senders of 5,000 or more messages a day to Gmail must authenticate with SPF, DKIM and DMARC, support one-click unsubscribe, and keep reported spam rates under 0.1%, never above 0.3%. The first sends go to the people who open things. The 545 who have not opened in a long while go last, or not at all until the domain has a record.
Who owns “may be emailed” after cutover?
In HubSpot one system held the CRM and the consent, so the question never came up, which is what Lock 4, the Audience Lock feels like from inside. 5 See also 5 See The Five Locks, Lock 4, the Audience Lock: the list you can export is not the audience you can mail, because consent, deliverability state and engagement history live in places the export does not reach.Read The Five Locks: How SaaS Vendors Keep You Trapped After the split there are two systems, and one of them has to be the owner. It is the email platform, and it wins on suppression, always. Every unsubscribe and every bounce is recorded there, with a source and a timestamp on the row, and flows back to the CRM as a read-only status over a webhook. The CRM shows it. The CRM never writes it forward.
Two conditions come with that. The webhook handler is designed to update existing people only, so the 6,194 suppression-only addresses never become CRM records; they are a refusal list, not a contact list. And the 3,040 who were merely non-marketable keep a reason on their row that distinguishes them from the 343 consent opt-outs (the 246 plus the 97). That distinction is what makes re-permissioning them a decision, taken later with the client’s agreement, rather than something that happens because two statuses looked alike in a CSV.
The point of making the email platform the owner is not tidiness. It is that “who may be emailed” becomes a question with one answer and an audit trail, which is the thing HubSpot’s billing flag never was.
Load all fourteen lists as unsubscribed and you have suppressed 3,244 contacts on the strength of list names, and the importer cannot bring them back.
Two things the load does not fix
The contact load gets the audience right. It does nothing for two problems that live in the emails and the sequence, and both have to be decided before the first send.
The first is a greeting. 753 of the 1,157 subscribers, 65% of the sendable audience, have no first name on their record, and all 16 emails in the live welcome-and-nurture chain open with the first-name token, once per body. On HubSpot that resolved to whatever the portal’s default was. On the new platform it resolves to a fallback the migration has to choose, and the choice lands on two-thirds of the audience. We set “there,” so 753 people will read “Hi there,” rather than a greeting with a hole in it. It is a small decision with a large footprint, and it is the kind that gets found in the first send if nobody looks for it in the conversion.
The second is the people already inside the sequence. The welcome chain had enrolled 25 people in three months, so few would be mid-chain at cutover. The nurture was another matter: 1,063 contacts had been bulk-enrolled into a 13-email sequence in which each send waits for a fixed weekday morning. The new platform’s workflows cannot start a contact partway through. The old portal can keep sending to them until the contract date, so the plan is to measure, shortly before cutover, how many are still enrolled and at which step, and decide on that cohort with the number in hand. Let them finish on the old sender, or restart them on the new one. Or let them go. Which is right depends on a count that does not exist until you take it.
What you have afterward
The gain is a sender that starts warm. Every bounce and unsubscribe from six years of sending, and both spam complaints, are already known to the new domain before its first campaign, so the first campaign goes to people who can receive it. That is deliverability as a property of day one rather than a recovery project in week six, and it is worth more than any saving on the subscription.
The second gain is a consent record. Each of the 11,060 rows carries a reason it may or may not be mailed, and where that reason came from, in a system whose only job is to be right about that. The CMO can say how many people the company may email, and the answer is a count with a basis, not a billing tier. On this portal the answer was 1,157, and the number our own plan had been quoting was 1,418.
The third is that the marketer’s exclusions survive as segments she can read and change. The 14 lists were policy that had hardened into filters nobody opened. They are now columns with a name, and the question “why does this person never get our emails” has an answer in the record rather than in someone’s memory of a list.
And the sequence that was running on cutover day keeps running, with the people inside it accounted for by count rather than by hope.
The read-back, and the day it has to be repeated
Before any row loads, the staged files are checked against the live portal by a script that opens them cold and queries HubSpot independently. On this portal: six headline counts against a fresh CRM search, all six matched (4,879 contacts, 1,401 marketable, 246 opted out of all, 254 hard bounced, 5 quarantined, 344 opted out of marketing). Five random rows per reason, 40 rows by 8 fields, 320 of 320 matched. No address appears in both the suppression file and the subscriber file. None of the 1,157 subscribers carries an opt-out, bounce or quarantine. None of the 1,157 is suppressed at portal level. All 14 list sizes equal what HubSpot reports.
Then a named person at the company opens the file, a step still ahead on this portal. They filter it to the subscribers and get 1,157. They pick an unsubscribed row and open the record in HubSpot, and it says unsubscribed. The archive stops being our claim at that moment and becomes the company’s record.
Then the whole pull runs again on load day. Between the audit and the extraction, a fortnight apart, seven contacts unsubscribed, six were created and 22 were demoted, every one of them from the live sends and jobs that had not stopped because a migration was planned. A suppression file is a snapshot, and the only snapshot that counts is the one taken minutes before the load.
If you are still deciding whether to leave, start with whether the audience is worth keeping at all. If you have decided, the migration guide covers the content, the forms and the CRM, and the data ownership piece explains why the export was never going to include this. The sibling to this guide is how per-contact billing shrank the same audience to 29 percent: that is how the marketable flag got this far from consent in the first place. This one is what to do about it on the day you load.
The research is free. So is the diagnosis. 60 seconds →