A Friday afternoon fix to the intake form. The developer tests it in a sandbox, it works, and it goes live. On Monday morning the first person to find out it broke something else is a client.
Nobody was careless. On HubSpot there’s simply no copy of the live portal to test the change against, so the real test happened in front of the people the portal exists to serve.
Where do you test a change to a HubSpot portal?
Somewhere that isn’t your portal. HubSpot offers three places to try things, and each is built for a different job. None of them is a full copy of the live portal, with its content, records, contacts and permissions.
HubSpot’s advice for code is a developer test account, which gives you “a testing environment to build out your CMS assets without impacting a standard HubSpot account,” or a CMS developer sandbox. 1 Source 1 HubSpot Developers, “HubSpot CMS overview,” read October 30, 2026: a developer test account gives “a testing environment to build out your CMS assets without impacting a standard HubSpot account”; alternatively “you can create a CMS developer sandbox account.” Both are separate accounts. That’s what makes them safe, and it’s also what makes them thin: they start empty.
For pages there’s content staging, part of Content Hub Professional and Enterprise. It stages pages on a your-domain.sandbox.hs-sites.com address. HubSpot’s own guide carries a warning worth reading twice: “Changes made to any page template, global content, or HubDB table in content staging” show up on the live pages that use them, so HubSpot recommends cloning those first. For changes to themes, templates and modules, HubSpot’s developer docs point you back to a developer sandbox. 2 Source 2 HubSpot Knowledge Base, “Redesign and relaunch a site with content staging,” last updated June 20, 2026: Content Hub Professional or Enterprise; staged content “is hosted on your-domain.sandbox.hs-sites.com”; “Changes made to any page template, global content, or HubDB table in content staging” are reflected on live pages that use those assets; “HubSpot recommends cloning your templates, global content, and HubDB tables before editing them in content staging.” HubSpot Developers, “Content staging”: “For building and testing changes to assets like themes, templates, modules, we recommend using a developer sandbox account.”
Enterprise accounts can also create a sandbox from the live account. It copies the account’s supported settings, and on request your 5,000 most recently updated contacts with up to 100 associated deals, companies and tickets each. You can import up to 200,000 more records per object by hand. 3 Source 3 HubSpot Knowledge Base, “Create a sandbox and deploy changes to production,” last updated October 28, 2026: Enterprise subscriptions; sandboxes copy the production account’s supported assets at creation; an option to “Copy 5,000 contacts and associated records” copies the 5,000 most recently updated contacts with up to 100 associated deals, companies and tickets each; up to 200,000 records per object can be imported manually.
HubSpot’s list of what a new sandbox copies is specific. Object definitions, templates and modules come across. Website, landing and blog pages don’t, and neither does anything the list doesn’t name. HubDB, access groups and serverless functions aren’t on it, so a sandbox has none of the portal’s HubDB tables or rows to test against, and none of its sign-in rules. 4 Source 4 HubSpot Knowledge Base, “Production assets eligible to copy to a sandbox,” last updated October 22, 2026: “Standard and custom object schemas” are fully supported, though custom object and association IDs don’t match production; “Templates and modules” are copied; “Website, landing pages, and blog pages” aren’t copied; all Service Hub assets aren’t copied; “If an asset or configuration isn’t listed above, it isn’t copied to your sandbox at creation.” HubDB, access groups, memberships and serverless functions don’t appear on the page.
| Where | What it’s for | What it holds | What it can’t tell you |
|---|---|---|---|
| Developer test account or CMS sandbox | Building and testing code | Whatever you put in it | How the change behaves with your real content, contacts and access groups |
| Content staging | Redesigning and relaunching pages | Staged copies of pages in your account | Anything about templates, global content or HubDB, which are shared with live pages |
| Enterprise sandbox | Testing account changes before deploying them | Object definitions, templates and modules, and a sample of recent records | How the portal behaves with its real pages, HubDB rows and access groups, none of which are copied |
Each is useful. The trouble is the gap between them, which is exactly where a portal lives: custom code running against real records, for real people, with real permissions.
What happens when changes are tested on live clients?
The obvious cost is the occasional broken release. The bigger cost is what the risk does to the team.
When every change might break something clients see, people make fewer changes. Fixes wait for a quiet week. Small improvements never get started, because nobody wants to own the Monday morning that follows. The portal’s backlog grows, and its owners start describing it as stable. It isn’t stable. It’s stuck.
Where does the knowledge of the portal live?
In more places than anyone has written down. A custom HubSpot portal is code plus configuration: templates and modules, serverless functions, HubDB tables, CRM properties and pipelines, workflows, lists and access groups. HubSpot’s command-line tools let developers keep the code in files and in version control, and good ones do. The configuration the code depends on still lives in the account, and some builds keep the code there too, edited in the browser.
So the real map of how the portal works sits in three places: the account itself, an email thread or two, and the head of whoever made the last change. That’s key-person risk in its plainest form. It’s invisible right up until the person leaves.
When every change might break something clients see, people make fewer changes. Fixes wait for a quiet week.
What happens when the developer leaves?
The pattern is common enough that we can describe it without naming anyone. A firm moves an important channel onto a custom HubSpot portal. The developer who built the custom pieces moves on. The firm’s own HubSpot admins are capable people: they can add a property, fix a pipeline, rebuild a list. They can’t safely change the custom code, and nothing written down explains how it fits together.
The next request to the builder starts with explaining the requirements again, to someone new. That person has no copy of production to learn on, so their first changes are slow and cautious, tested in front of clients. We wrote about our own part in this pattern, as the partner who built these portals for years, in We Taught Companies to Build Portals on HubSpot for Ten Years.
What a safe release process looks like
It isn’t exotic, and none of it is specific to one product. Every change is tried on a full copy of the portal, with realistic data, before it goes anywhere near clients. A second person reviews it. Every release is recorded (what changed, who changed it, when and why), and any release can be rolled back in minutes. A scheduled test submission runs through the intake form after each release and around the clock, so a break is caught by a check rather than by a client.
The documentation lives next to the code and belongs to the firm. It describes how the pieces connect in plain English, and it changes whenever the portal does, so no single person is the only one who knows.
On HubSpot you can get partway there with discipline and a good partner. You can’t get the first step, the full copy of production, because the platform doesn’t offer one.
What you gain: a portal that keeps getting better
Speed is the real return. Teams that can test safely change their portal more often, in smaller pieces, and each change is less risky because it’s small and reversible. The backlog shrinks instead of growing. New people can be productive in weeks, because the portal is written down and there’s a copy to learn on.
And the firm stops depending on any one person. The knowledge lives in the repository and the documentation, which the firm owns, rather than in whoever happens to be on the account this year.
Testing is one of five places a portal on HubSpot runs into the platform. Platform changes you don’t schedule are covered in HubSpot Serverless Function Limits for Client Portals (2026), and the full set in Can You Build a Customer Portal on HubSpot? Where the portal should live instead is in Custom Client Portal or HubSpot? 5 Options Compared. And every department that comes to rely on a portal only HubSpot can run deepens what the Five Locks calls the Dependency Lock.
The research is free. So is the diagnosis. 60 seconds →