When a HubSpot contract ends, a HubSpot data export gives you the contacts, companies and deals in an afternoon. Seven things do not, and they are purged or sealed with the portal: the suppression history on people you deleted, the rules written inside workflow enrollment criteria, the names of your pipeline stages, every file attachment, every hosted video, the source of a marketplace theme, and the objects a read-only key is not allowed to see. Each one has to be pulled while the account is still paid for, and most of them cannot be recovered at any price afterward.
We learned the list on one engagement. A small B2B software company, a lean marketing team, a HubSpot subscription at $14,000 a year, and a contract about to end when we opened the portal. The company thought it had five or six workflows switched on. It had 70. It thought it had under 2,000 contacts. It had 4,873. None of that was the problem. The problem was the material that no export, no API key and no spreadsheet could reach.
What a HubSpot data export leaves behind
Everyone plans an exit around what is hard to rebuild. That is the wrong axis. The axis that matters is what dies with the portal and what does not.
Most of a HubSpot estate does not die. On the contract date the portal drops to the free tier. The CRM records stay. The API stays reachable. You can still log in and export a contact list in March. The capability that ends on the date is Marketing Hub email sending, and that is a build problem with a known shape: authenticate a new sending domain, move the sequences, start the warm-up early enough.
What dies is a shorter list and a nastier one. It is the data HubSpot never exposed as data in the first place: states it tracks about people who are no longer contacts, logic it stores as interface configuration, assets it serves from infrastructure you never had an account on. On the portal we audited, every item below was missing from the standard export, and most were unreadable through the service key, readable only from a logged-in browser session on HubSpot’s own internal endpoints, or not readable at all. The extraction was the part of the project that could not have been skipped.
So the sequence of an exit inverts. Week one is not design. Week one is pulling everything on this list out of the building, reading it back, and only then deciding what to build.
1. Your do-not-contact history is mostly about people you deleted
The contact export told us 602 contacts carried a reason not to email them: 254 hard bounces, 246 unsubscribed from everything, 97 opted out of marketing mail, 5 quarantined. A reasonable person loads those 602 into the new platform as suppressed and moves on.
The portal was refusing to mail 6,714 addresses.
6,194 of them were not the address of any current contact; nearly all of them were on contacts that had been deleted. HubSpot keeps an address’s unsubscribe after the contact record is deleted, which is the right behavior and also the trap, because the only place that state lives is the email subscription timeline, and the timeline is not an export. It is 15,571 events across 9,702 distinct addresses, readable from a logged-in session and nowhere else. Among them: 3,399 bounced addresses with no contact, 2,754 full unsubscribes with no contact, and the portal’s only two spam complaints, filed years ago, on addresses that are no longer contacts.
Where did 6,000 deleted contacts come from? Years of list cleanup, a live rule that deletes spam submissions, and four workflows that were themselves already deleted. Those four had processed 55,422 records between them: an “unqualified lead” demotion that ran 49,231 times, a do-not-contact rule, a bad-address rule, a spam list. Their definitions returned nothing on every read, live or archived. Their effect survived only as the suppression state of addresses that no longer had a record. 1 Editor's note 1 HubSpot’s documentation describes a window of about 90 days in which a deleted workflow can be restored from the interface. We did not test it. Treat deleted workflows as gone unless you restore them while the portal is still paid.
This is the single most dangerous item on the list, and it has nothing to do with data loss in the abstract. A new sending domain has no reputation. If it re-learns 6,000 bad addresses by bouncing them, it learns them as a brand-new sender under Google’s bulk-sender rules, which ask for reported spam under 0.1% and never above 0.3%. 2 Source 2 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%. Two of those addresses had already reported the old sender as spam. Those are the numbers a mailbox provider uses to decide whether a new domain is a spammer, and a domain does not get to argue.
Pull the contact-level state through the API. Pull the portal-level timeline through the browser. Load both into the new platform as suppression before a single subscriber, and load them over the API, because on the platform we chose the CSV importer could not re-subscribe anyone it had suppressed and the API could. Then load the subscribers.
One more number from the same pull, because it changes a figure everyone quotes. HubSpot counted 1,401 “marketing contacts” on this portal. 3 Definition 3 Marketing contact: HubSpot’s billable unit for Marketing Hub. A contact flagged marketable can receive marketing email and counts toward the subscription tier. The flag is a billing status, not a record of consent. It was billing for all of them. 174 had unsubscribed from all email and 61 more from marketing email. Marketable is not subscribed. The sendable audience was 1,157, and a migration plan that loads the 1,401 as subscribers re-subscribes the 174 who had unsubscribed from everything, and mails the 61 who had opted out of marketing.
The contact export showed 602 suppressed contacts. The portal was refusing to mail 6,714 addresses. The difference lived on people who had been deleted.
2. The rules live inside the workflows
Every marketing operation accumulates rules nobody wrote down. Which email domains are spam. Which countries are outside the territory. Which job titles should never enter the funnel. In a HubSpot portal those rules end up in the one place that can act on them: the enrollment criteria of a workflow, or the filter tree of a dynamic list that feeds one. That is Lock 3, the Logic Lock. 4 See also 4 See The Five Locks, Lock 3, the Logic Lock: business rules encoded in a platform’s configuration rather than in a form you can carry out of it.Read The Five Locks: How SaaS Vendors Keep You Trapped
The portal we audited had two such workflows. The spam rule deleted a contact an hour after a form submission if the address matched one of 28 substrings or ended in one of three top-level domains. It had deleted 158 contacts since October 2024. The territory rule made a contact non-marketable if its company’s free-text country field named one of the 27 EU member states, or if the email ended in one of 30 country-code suffixes and the contact had no owner and no activity. Neither rule existed anywhere else. Not in a property and not in a document.
Reading them was the only way to find out what they actually did, which was not quite what their names said. Three branches of the “spam” list were not spam at all: a submitter whose title contained “Professor,” whose email contained “universit,” or whose address came back from a third-party verifier as invalid or catch-all was deleted along with the spam. Two of the three were deleting academics. One pattern had a leading space and had never matched anything. The territory rule had an unowned-and-inactive guard on the email branch and none on the company branch, so a contact at any company whose country field said France was demoted, owned or not. Those are policy decisions, and they had been made by whoever last edited a filter.
None of this is readable through a service key. HubSpot’s service-key catalog carries no automation scope at all, so a key can list the workflows and count their enrollments but cannot read a single definition. We read all 90 live workflow definitions through a logged-in session, one request each, and committed them as the record. The two rule files now carry the logic verbatim, a plain-language restatement, and a note on which branches are spam defense and which are qualification policy wearing a spam costume.
3. The names of your pipeline stages exist only on a screen
The CRM API will tell you how many deals sit in each stage. It will give you the stage’s internal identifier. It will not, through the objects endpoint, give you the label a salesperson sees, the display order, or the win probability attached to it. Those come from the pipelines endpoint, which nobody had looked at closely, because nobody thinks of stage labels as data until the day the new CRM asks what to call its columns.
When we pulled them, the three pipelines (eight stages, seven, and four) held facts the architecture had been designed without. The new-business pipeline had two closed-won stages, not one; the second held a single deal, and the first draft of the new CRM’s closed-deal rule had missed it. The two deal pipelines did not share their closed stages; each had its own, with different identifiers, so “closed lost” was two things. One label carried a typo that was presumably on every sales report. And 490 lost deals recorded, in a “stage before lost” field, a stage name that no longer existed in the ladder; 449 of them said “Demo,” a stage someone had renamed or removed without touching the history that pointed at it.
Labels and order are the cheapest extraction on this list. One request per object type. They are also the item most likely to be skipped, because the deal export looks complete without them.
4. Attachments are in no export
HubSpot’s CSV export of contacts, companies and deals contains no files. The attachments on an email, a note or a meeting are in the Files API, keyed by a file identifier that only the engagement record knows. To get them you need every engagement, every association, and a file pull with scopes the standard read set does not include.
The portal held 2,752 attached files, 2.48 gigabytes: 1,410 PDFs, 450 Word documents, 104 spreadsheets, the rest images and a long tail. They were attached through 3,430 email references, 210 notes and three meetings, and they pointed at 2,242 companies, 1,467 contacts and 1,230 deals. Almost all of them, 2,751, were flagged private in HubSpot, so nobody had ever meant them to be public. Fifty-nine of them were reachable only through a custom object the company used as its contract register. Without the custom-object associations, those 59 files would have had no owner in the archive and nobody would have known to look.
The archive we built holds every one of them, each tied to the engagement it came from and the records that engagement touched, and each re-hashed on disk against the checksum recorded at download. It is sized to cost the company about a dollar a year to keep in its own cloud storage account. The alternative was a signed contract that existed only as an attachment on an email in a portal that no longer existed.
5. Hosted video is not a file
One blog post on the site embedded a video uploaded to HubSpot’s video hosting. It was not in the File Manager. It was not reachable through the Files API. It was served from HubSpot’s video domain, and it would stop being served on the contract date, with the post still pointing at it.
Small item. It was downloaded and self-hosted. It would have been a dead player on a live page for as long as it took someone to notice, and the fact that nobody could name the mechanism until we went looking is the point. Anything a HubSpot interface lets you upload has a storage location, and not all of them are the File Manager.
A scan of the rebuilt site before launch found 530 files and ten fonts still loading from the old HubSpot paths, and 417 HubSpot content-delivery addresses stored inside the migrated content. Each one was a dependency on an account the company was leaving. The marketing emails were worse: of 197 images they referenced on HubSpot hosting, 76 had already been deleted from the portal some time before, so 365 of the company’s 442 emails were already rendering with broken images on the day we read them, 15 of them in sends that were still running.
6. The theme you paid for was never yours
The company’s website ran on a child theme of a theme bought from HubSpot’s marketplace. When we asked HubSpot for the parent theme’s source, the Design Manager showed it read-only and the download endpoint returned a refusal: marketplace assets cannot be downloaded. No permission unlocks it. The vendor, asked directly, declined to share it.
So 13 page templates and two modules were rebuilt from the rendered HTML, which is to say from what the browser received, with the structure inferred and the styling reconstructed. That worked. It also cost work that an exportable theme would not have, and it was the first time the company learned that the design it had paid for was licensed to display, not to keep.
The second finding was quieter. The live site was loading 153 files from HubSpot accounts that were not the company’s: 131 font files, 21 demonstration images and an icon, served from theme makers’ own portals. They worked because those accounts were there. They would have stopped working the day they were not, on a site that no longer had anything to do with HubSpot.
The design it had paid for was licensed to display, not to keep. And the fonts were loading from somebody else’s account.
7. Some of your own records are behind a door the key cannot open
A read-only service key is the right instrument for an audit. It is also, on the standard tier, blind to a specific set of things, and the blindness does not announce itself. A missing scope returns a permission error, which a tired script can log as zero.
On this portal the key could not read: the Leads object (at least 75 records, referenced by engagements); the 1,734 form submissions; the 442 marketing emails as rendered pages; the 196 reports and 19 dashboards, for which no public API exists; and, as above, every workflow definition. The emails, the reports and the workflows came out through a logged-in session, reading the same endpoints the HubSpot interface uses, with the result hashed in the page before download and checked on disk after it. The Leads and the form submissions did not come out at all. They sit behind scopes the key was never granted, and they are on the losses schedule, in neither the new CRM nor the archive.
We say this not because the method is interesting but because the alternative is an audit that reports “0 marketing emails” for a portal holding 442, which is exactly what an early version of our own tool did. A permission failure rendered as a fact is the worst thing an audit can produce. If an agency hands you a HubSpot audit built from an API key alone, ask it which of these seven it did not see.
What you have afterward that you do not have today
The point of all this is not a backup. It is a change in who owns the record.
The suppression history becomes a consent record with a source and a timestamp on every row, in a platform that treats “who may be emailed” as its own concern and never as a billing flag. The new sender starts warm: every bounce and complaint from six years of sending is already known to it, so the first campaign goes out to people who can receive it. That is deliverability as a day-one property instead of a recovery project.
The rules become two files in a repository. Anyone can read what the spam filter does, a change is a reviewed diff, and the branches that were deleting academics are now a policy question with a name on it instead of a filter nobody remembered editing.
The attachments become an archive in the company’s own cloud account, every file tied to the deal and the company it belonged to, with the tooling to query it. The company can answer “what did we send this customer in 2023” without a HubSpot seat and without a HubSpot.
And the exit itself gets scoped against what the portal holds rather than what the screen-share showed. The company that thought it had five or six workflows switched on and four integrations had 70 and 23. Knowing that on day one is the difference between a six-week project and a six-week surprise.
The first week: what to pull, and in what order
Treat the contract end as a wall and work backward from it. Nothing on this list can be done after the date, and one item, the deleted workflows, has an earlier date of HubSpot’s choosing.
Day one, the suppression state, both layers: every contact’s opt-out, bounce and quarantine properties through the API, and the portal-level subscription timeline through a logged-in session. Read the counts back against the portal before anything else happens. The contact-level pull on this portal took ten minutes, and it is what surfaced the 174 billed-but-unsubscribed contacts that the plan had been about to re-subscribe.
The same week, the rules: every workflow definition and every list filter the rules depend on, verbatim, with a plain-language restatement beside each one and a decision about which branches are policy. Then the pipeline stage labels, order and probabilities, one request per object type. Then the full engagement archive with its file attachments, which on this portal was the largest thing we moved; the 2,752 file downloads alone took about 70 minutes.
Before the site moves: the hosted video, the theme source if you can get it, and a scan of every page for files served from HubSpot hosting or from accounts that are not yours. Before the email platform goes live: the images every sent email points at, so the archive of those emails is not a gallery of broken thumbnails.
Then a restore that someone opens. Not “we took a backup.” A named person at the company opens the export, finds a record, and reads a value back out of it against the live portal. Our own read-back on this portal compared 3,140 property values across a random sample against the live records and found every one identical. The client’s read-back is the one that counts, because the moment it is done the archive stops being our claim and becomes the company’s asset.
Two rules on timing. Cut over before the last day, because the old portal is the only fallback and it is already paid for; we scheduled this one nine days before the date. And never cancel early to save a month: the one capability that ends with the contract is the one you most need running until the replacement is carrying it. 5 Editor's note 5 The deliverability ramp. Email platforms and deliverability vendors generally advise four to eight weeks to reach production volume on a cold domain. We treat that as planning guidance, not a measurement, and start the ramp inside the old contract so a reputation problem surfaces while the old sender is still available.
If you are deciding whether to leave at all, the six-factor framework is the place to start. If you have decided and want to know what happens to the content, the forms and the CRM data, that is the migration guide. This piece is the part in between: the week nobody budgets for, and the list that makes it short.
The research is free. So is the diagnosis. 60 seconds →