Nobody at a company knows what its HubSpot portal does. Not the person who runs it, not the person who pays for it, and not the agency that built most of it years ago. The portal we opened for a HubSpot portal audit this autumn had been described to us, in good faith and on a screen-share, as five or six active workflows, under 2,000 contacts, four integrations and a team that avoided tickets. It had 70 workflows switched on, 4,873 contacts, 23 connected apps, 314 tickets, and a custom object holding 98 contracts that nobody had mentioned because nobody thought of it as HubSpot.
That gap is the subject of this piece. Not because the company did anything wrong. Because the gap is normal, it is invisible from inside the portal, and an exit scoped against the conversation instead of the portal is the most common way a HubSpot migration goes over budget or loses something.
The screen-share
The sales call was ordinary. Someone on the client side shared the workflows page, read the number at the top, and counted down the list: “78 workflows… these ones are on, one, two, three, four, five, six.” Six active workflows. It went into the notes, and for the next eleven days it was the number the migration was scoped against.
The workflows page opens in a filtered view. The six were whatever that view happened to show. When we read the inventory from HubSpot’s own flow objects rather than from the screen, the portal held 134 workflows including the deleted ones, 90 of them live, 70 of those switched on. Nothing had been hidden. The default view is just not an inventory, and the person sharing the screen had no more reason to know that than anyone else who has ever opened that page.
Seventy is more than ten times six. The migration had been scoped against a number wrong by an order of magnitude, and the number came from the only source anyone ever uses: the customer’s own description of their system.
Seventy is more than ten times six. The migration had been scoped against a number wrong by an order of magnitude, and it came from the only source anyone ever uses.
Why does nobody know what their portal does?
The usual answer is turnover, and it is half right. This portal had been built by a larger team than the one that remained. Two people had authored almost every workflow that had a recorded author, and 68 of the 134 carried no author at all. Whoever built those had already gone, and the logic stayed behind without the memory.
The other half is structural. HubSpot presents itself through views, and every view is a subset. The workflows page shows a filter. The contacts page shows a list. The integrations page shows the apps someone installed, not the twenty inbox connections individual users made from their own mail. There is no screen in the product that shows the whole estate at once, so the whole estate is something no customer has ever seen. They have seen the parts they use, and they describe those, accurately, as the system.
Which is why every number from discovery was wrong in the same direction:
“Under 2,000 contacts.” The portal held 4,873, and 8,634 companies.
“We use contacts, companies and deals, and avoid orders and tickets.” Said twice. The portal held 314 tickets, a ticket survey workflow with 71 enrollments, switched off but still there, and a custom object called an order form, 98 records deep, with two live workflows attached, one of them erroring. 1 Definition 1 Custom object: a record type a HubSpot customer defines beyond contacts, companies, deals and tickets. It has its own properties, associations and workflows, and it is not in the contact, company or deal export; someone has to know to ask for it.
“Our integrations are these four.” The portal had 23 connected apps and seven more user-level integrations, among them two separate automation platforms running alongside the 70 workflows, so automation was spread across three systems and two of them were outside anything an audit of HubSpot could see. One outreach tool had a workflow keyed to it and no installed app, which meant it was writing into the CRM either through one of those platforms or straight through the API, and nobody could say which.
Nobody lied. These are the answers you get when you ask a person instead of reading the portal.
The custom object nobody mentioned
Of everything on the list, the order-form object matters most, and it is the item that would have been lost.
A custom object is a record type the customer invented. This one held 98 contract records, created from closed-won deals by a workflow that copied ten fields across, named each record after the deal and its contract end date, and raised two follow-up tasks, one of them to send the invoice. Fifty of the records carried an original agreement date that one person had typed by hand, and those dates were a source of the company’s renewal dates. Another workflow on the object was presumably meant to copy a company date down onto the form. It did the reverse, reading the empty form field and writing the blank onto the company, and had never once succeeded.
None of this was in discovery, because the people on the call did not think of it as HubSpot. It was an operations record, not a marketing one. It was also revenue-adjacent, undocumented, erroring, and in no export anyone would have thought to run. Custom objects are what break silently in a migration, for a simple reason: nobody scopes what was never mentioned.
More seats than people
A small company had 24 HubSpot users, more than twice as many accounts as employees. More of them were internal addresses than the company had staff, which usually means former employees still hold seats, and on HubSpot those seats are billable. Nine were outside the company: two agencies, a deliverability vendor with two logins, a page-speed vendor, a contractor, our own audit account, and two personal email addresses that belonged to no employee and no vendor.
Five of the 24 were super admins, one of them our own audit account. No user had a permission role assigned at all; access was a pile of per-user toggles. One owner held 62% of the contacts, and that owner was “none.”
This is not a security lecture. It is a scoping point. Seats are a line on the renewal bill and part of Lock 5, the Dependency Lock, and an access review is one of the few parts of an exit that produces a saving before anything is built. It is also the one part that has to be raised with the person who owns the company, not the person who runs the portal. 2 See also 2 See The Five Locks, Lock 5, the Dependency Lock: the integrations, seats and side systems that accrete around a platform until nobody can list them.Read The Five Locks: How SaaS Vendors Keep You Trapped
What the rest of the estate looked like
The portal held 442 marketing emails, 305 of them published. 163 lists, 131 untouched in over a year. 196 reports, 150 of them custom, on 19 dashboards. More than a thousand properties, 175 of them custom. Sixty-five “forms,” which on inspection were 22 real forms, 28 meeting booking links, seven lead-ad forms from a social network, four surveys and a handful of document gates. About 168,000 engagement records: 130,935 logged emails, 21,233 tasks, 8,061 calls, 6,770 meetings.
A small company was paying $14,000 a year to carry the marketing and operations estate of the company it had been several years earlier. That is not a criticism. It is what a portal looks like after years of use, and it is the single most important thing to know before pricing an exit, because most of it does not have to move.
Nobody lied. These are the answers you get when you ask a person instead of reading the portal.
The seventy are less frightening than they sound
Here is the part that makes the audit worth paying for rather than merely alarming.
Of the 90 live workflows, 23 existed only because HubSpot cannot read a value across a relationship. They copied a field from company to contact, or deal to company, so that a list or a report could filter on it. In a CRM with real relations they are not rebuilt; they stop being necessary. Fifteen more were dead: disabled, never enabled, or superseded. Fourteen were the email program, which moves to an email platform. Seven were form handling, which belongs in the website. Four were a social-ads audience and activity sync. Nine needed a decision from the company. Only 18 of the 90 were real CRM logic: qualification, lifecycle, deal stage, renewals, the actual revenue process. Forty-two percent of the estate disappeared on migration, and the rest fit on one screen.
The two largest workflows by volume illustrate it. One had enrolled records 729,866 times in a portal with 4,873 contacts. Another had run 751,403 times against roughly seven open deals. Both were re-enrollment loops, one copying a value onto itself and the other stamping a date over and over, and the first was among the workflows erroring that week, because it was thrashing. They were not automation doing work. They were the portal’s own plumbing, and the plumbing is most of what “70 workflows” means.
So the honest answer to the marketer’s worry, which was losing the ability to see a list of all her workflows, was that she would have a shorter list. Seventy switched-on workflows become six in the new CRM, plus five pieces of code anyone can read.
What the audit got wrong, and how we found out
An audit that reads the portal is better than a conversation. It is not infallible, and the way it fails is instructive.
Our first pass said the company’s email program had stopped in 2023. The evidence looked clean: broadcast sends fell from 175 that year to three, then six, then two in 2026. We wrote the headline. It did not survive the internal read before the deliverable went out, because the sequence the marketer had built that summer was running at that moment and the audit had called the program dormant.
The challenge was right. The count had included only broadcast emails and silently excluded every automated one, and all of 2026’s activity was automated: 38 emails across seven months, at least 15,081 delivered, and a three-email welcome sequence handing off to a thirteen-email nurture, six weeks old, running at the moment we declared the program dead. The conclusion about which platform to move to did not change. The reason, the risk and the priority all did: a live program to migrate intact on a deadline is not an archive to leave behind.
The lesson is not that audits are unreliable. It is that counts need two passes, and the second one should be adversarial. On the workflow classification we ran exactly that: an independent review challenged every proposed deletion against the raw export and overturned 12 of 27, including all seven workflows that a first reading had dismissed as “only HubSpot billing.” They were encoding real suppression and geographic rules, and the billing flag was simply the only action HubSpot gave anyone to express them with.
How to read a portal instead of a person
Three things make the difference between an audit and a screen-share.
Read the inventory from the system, not the interface. The workflow count came from HubSpot’s internal flow objects, the only place the complete list exists. HubSpot’s service keys carry no automation scope and the public automation API returns a partial set, so a key-only audit cannot see the workflows at all. 3 Editor's note 3 HubSpot’s service keys expose no automation scope at all, and the marketing-email scope is not grantable on this tier. The same is true of forms, marketing email and reports. If your audit does not say how it read those, it did not.
Count what is on, what ran, and what errored, not what exists. Seventy workflows was the headline; the useful numbers underneath were 17 carrying issues HubSpot itself had flagged, seven that had errored in the last 30 days, six that were switched on and had never run, and 131 lists nobody had touched in a year. Those are the numbers that tell you what the company actually relies on.
Ask the people afterward, not before. Discovery is where you learn what the team believes. The portal is where you learn what is true. Done in that order, the gaps between the two are the agenda for the next conversation, and on this engagement that agenda included a contract register, two automation platforms, an outreach tool with no app, and two personal accounts with CRM access.
What you get for knowing
The exit for this company was quoted as a fixed fee against a fixed scope, and the scope was the portal, not the call. The custom object is in the migration with all 98 records and its 50 renewal dates. The seat list is a line on the access review instead of a surprise on the next bill. The 23 plumbing workflows are not being built, and the company ends up with a list of its own automation short enough to read in a minute.
None of that is possible from a screen-share, and all of it is routine from an inventory. If you are weighing whether to leave at all, the six-factor framework will help, and the first factor to score honestly is whether you know what your portal does. If you have decided, the list of what dies with the portal is the next thing to read, because the items on it are the ones that were never in the conversation either.
The research is free. So is the diagnosis. 60 seconds →