Short answer: yes, the schemas. No, the records.

When you create a HubSpot Sandbox, your Custom Object definitions come with you. The records do not. You get the structure of your portal in the sandbox, not the live data sitting inside it.

That one-line answer covers most of what people are searching for. The more interesting question is what you do about it - especially right now, because HubSpot is in the middle of a big shift on how sandboxes work.

Does a HubSpot Sandbox include Custom Objects?

Custom Object schemas sync. Custom Object records do not.

HubSpot’s own documentation puts it directly: “All object definitions will sync, but not object records.”

That means when you spin up a new Standard Sandbox from an Enterprise production portal:

• Your Custom Object definitions come across - the object name, every property, the association configuration.
• Your pipelines come across (without records inside them).
• Workflows come across, minus call-based workflows.
• Forms, automated marketing emails, themes, templates, and segments (names only) come across.

And this does not happen:

• Custom Object records do not come across.
• Standard object records do not come across (with one optional exception, covered below).
• Non-automated marketing emails, website content, subscription types, scoring rulesets, and integration connections do not come across.

The practical effect: your sandbox looks like your portal but is empty of the data that lives inside it. You can test a workflow against your real property schema; you cannot test it against the records that would enrol into it. You have to create test records yourself.

Legacy Standard Sandboxes are being sunset on April 30, 2026

This is the bit a lot of older blog posts miss, because it has not happened yet at the time of writing.

HubSpot announced in December 2025 that legacy Standard Sandboxes sunset on April 30, 2026. The new Standard Sandbox is already the default for new accounts, and if you are on a legacy sandbox you need to move before the deadline.

The differences that matter for Custom Objects:

Legacy model. One-time copy on creation, plus the option to resync production data back into the sandbox. That resync overwrote most of the sandbox state (except contacts and anything created only in the sandbox). Custom Objects created in the sandbox were protected from being overwritten.

New model. One-time copy on creation. No resync. Changes in the sandbox do not affect production unless you explicitly deploy them. If you want the sandbox to reflect the current state of production, you create a new sandbox.

The tradeoff: you lose easy refresh, but you gain Deploy to Production - a real pipeline for promoting sandbox-built changes into live.

How do I move Custom Objects from sandbox to production?

In the new Standard Sandbox, this is what Deploy to Production is for.

Deploy to Production pushes assets created in the sandbox back into production. Up to 300 changes per batch. It covers schema changes, workflows, lists, forms, automated emails, property changes - the things you would normally build in a sandbox, test, and want to ship.

The important constraint: it only works for assets first created in the sandbox. If you edit a workflow that was synced down on sandbox creation, that edit will not deploy up. The flow assumes you build new in the sandbox, verify, then push.

For Custom Objects specifically that means: you can design a brand new Custom Object in the sandbox, test it against a small dataset, then deploy the schema and the workflows built around it to production as a single batch. You cannot edit a synced-down schema in the sandbox and expect the edit to reach production automatically.

How do I replicate Custom Objects between two production portals?

This is the trickier case, and it comes up constantly for agencies and teams running multiple HubSpot instances.

Sandbox sync only copies from production to sandbox. Deploy to Production only goes sandbox to production. There is no built-in path between two production portals.

Your three options:

1. The Custom Objects API

HubSpot’s Custom Objects API lets you define a schema in code and post it to any portal you have API access to.

POST https://api.hubapi.com/crm/v3/schemas

Scope required: crm.schemas.custom.write.

If you build the schema JSON once and store it, you can hit multiple portals with it. This is the cleanest technical path if you are comfortable writing API calls and managing versioning yourself. You still have to rebuild workflows, properties, and associations around that schema separately in each portal.

2. Manual recreation

Settings > Data Management > Objects > Custom Objects, and build it the same way in every portal. Works. Scales to three portals; breaks down at thirty.

This is the path most RevOps teams take because it does not require a developer. The trade is the one you would expect: it is slow, and the drift between portals over time is the enemy.

3. Plan Mode (Daeda AI)

If you are running multi-portal operations and rebuilding Custom Object schemas is a regular job, the manual path gets expensive fast. That is the gap Daeda AI’s Plan Mode was built for.

You describe the schema you need in conversation. Daeda AI reads the target portal, checks what already exists (so it does not duplicate or collide with live workflows), and drafts a complete execution plan you can read top to bottom. You approve in one step. The plan itself becomes your documentation - replay it on another portal when the next one lands.

That pattern - design once, replay across portals - is covered in more depth in Plan Mode: 200 clicks to 2 and multi-portal ops with Daeda AI.

What gotchas should I expect when replicating Custom Objects?

A few that HubSpot calls out directly in their own docs, and a few from living with it:

Record IDs are different between sandbox and production. HubSpot states that “contact, company, deal, and ticket IDs will have different IDs between sandbox and production accounts.” The same applies to Custom Object records. Any workflow or script that hard-codes an ID will break on deploy.

Dependent assets can fail silently. If a workflow in your sandbox references a property or pipeline that did not sync across (or was deleted), the workflow still shows in the UI but flags an alert next to the broken action. Worth scrolling through every workflow after a sandbox creation to check for those alerts.

Property sync does not work between Custom Objects. HubSpot’s sync properties feature does not support two Custom Objects syncing to each other. If you need a value to flow between two Custom Objects, you need a workflow.

The 5,000-contact optional import is contacts only. The new Standard Sandbox offers an optional “copy 5,000 contacts and associated records” toggle. The associated records are capped at 100 deals, companies, and tickets per contact. Custom Object records are not included in this toggle.

Sandbox workflow enrollments are capped. Across the whole sandbox, 100,000 enrolments per day. Enough for most testing; worth knowing if you are running a scenario that replays volume.

When Plan Mode beats manual replication

Sandbox is a testing environment, not a replication tool. That is worth keeping separate in your head, because it is the part that causes the most confusion.

If your goal is to test a workflow safely: sandbox is built for this.

If your goal is to move a Custom Object schema between production portals: sandbox will not help you. You are back to API, manual rebuild, or a tool that does the job.

This is the piece of HubSpot that has stayed manual the longest. Custom Objects are Enterprise-only. They are complex. They connect to pipelines, workflows, lists, reports, and every one of those connections has to be rebuilt by hand on the second portal.

Daeda AI’s Automation Suite closes that gap through Plan Mode. One conversation designs the schema, the workflows, and the lists that depend on it. The plan is reviewable before anything touches the portal, and it is replayable on the next portal when you need the same structure there.

If you are running one HubSpot portal, the API path is fine. If you are running five, or you inherit them from clients, Plan Mode is the difference between a weekly rebuild and a weekly conversation.

FAQ

You can also read through the Daeda AI hub for more on how AI-assisted operations work across HubSpot portals.