If your team uses a HubSpot sandbox to test major CRM changes before deploying to production, an important shift is underway. As of March 16th, 2026, HubSpot is retiring legacy sandboxes and replacing them with their new standard sandboxes that introduce a fundamentally different way to test and deploy changes.
On the surface, this feels like a clear upgrade. HubSpot standard sandboxes allow teams to sync supported assets from production and deploy eligible changes back, reducing the amount of manual rebuild work required. In practice, this new sandbox introduces intentional guardrails and specific data-sync behaviors that teams need to understand when planning how they test and deploy changes.
This article explains what’s changing, how HubSpot legacy sandboxes differ from HubSpot standard sandboxes, and how to migrate safely without disrupting production systems. Understanding these nuances upfront helps teams plan testing and deployment with fewer surprises.
A HubSpot sandbox is a separate environment connected to your production portal that lets teams test changes without affecting live data or active records. Sandboxes are commonly used to:
For mid-market and enterprise organizations, sandboxes play an important role in how changes are introduced and validated. They provide a controlled environment to test automation, data models, and integrations without putting live records or active processes at risk.
Historically, HubSpot sandboxes were strong testing environments but offered no direct path to production. Changes that worked still had to be rebuilt manually. Standard sandboxes are HubSpot’s response to that gap, introducing a more structured approach to testing and deployment.
Understanding the HubSpot Legacy Sandbox
HubSpot legacy sandboxes were designed as a snapshot of your current portal. When created, it copied supported assets from production at the time of creation. While certain assets could be re-synced later, the sandbox did not maintain an ongoing, live connection to production.
Key characteristics of a HubSpot legacy sandbox included:
Legacy sandboxes worked well for experimentation and learning. Teams could safely test ideas and validate logic in isolation. The tradeoff was that successful changes still had to be recreated manually in production, which greatly increased build time.
With the rollout of HubSpot standard sandboxes, the tool has moved closer to a true staging environment. Instead of a snapshot of your existing portal, controlled syncing and deployment are now available.
With a HubSpot standard sandbox, teams can:
This is a meaningful improvement, but it comes with an important caveat. HubSpot standard sandboxes are intentionally designed to protect production. They do not allow you to overwrite or directly modify existing production assets.
That design choice shapes how standard sandboxes must be used.
HubSpot standard sandboxes allow teams to sync existing workflows, properties, and records from production so they can be reviewed and tested in a controlled environment. However, edits made to existing assets in the sandbox cannot be deployed directly back into production.
This behavior is intentional. HubSpot’s deployment model is designed to protect live systems by preventing in-place updates to production assets. When a change to an existing asset needs to be implemented, the recommended approach is to clone the existing asset in the sandbox, make updates to the clone, and deploy the new version instead.
If you want to modify an existing workflow, the typical process looks like this:
This approach adds an extra step, but it ensures production logic is not unintentionally overwritten and keeps changes more predictable as portals grow in complexity.
Understanding what types of assets can be deployed is critical to planning how you can use HubSpot sandboxes moving forward.
HubSpot’s deployment tool lets you move certain sandbox-created assets back into your production portal using the Deploy to production feature. These assets are typically net new creations in the sandbox, not edits to assets that already existed in production.
Examples of supported deployable assets include:
These assets are additive and can be selected in the Deploy wizard when you set up a production deployment.
For assets that already existed in production but were synced into the sandbox, sandbox edits generally will not be offered for deployment. In those cases, the sandbox is valuable for validation and testing, but the intended production update pattern is to create a new version and deploy that instead.
It’s just as important to understand what won’t be picked up by the sandbox deployment tool. HubSpot only lists assets that were created in the sandbox and do not yet exist in production as eligible for deployment. Edits to supported assets that were copied from production into the sandbox are not shown in the deployment wizard.
Limitations include:
In these cases, the sandbox is best used to validate changes and test behavior, not to push the edits to production.
While HubSpot documents many sandbox limitations, there are several operational impacts that are not covered in HubSpot’s documentation. Below are a few key considerations that our team found when testing our standard sandboxes in HubSpot.
As previously mentioned, workflows that exist in both production and the sandbox cannot be deployed if edited directly. This becomes more complex when workflows trigger other workflows, reference shared properties, or include custom code actions. Cloning is required, and dependencies must be carefully reviewed.
You can create new properties in a sandbox and deploy them. You cannot deploy changes to existing properties, including dropdown options, conditional logic, or field settings. The sandbox can validate downstream impact, but final changes must be made manually in production.
List definitions can be deployed, but list membership does not carry over. Deployed lists start empty and then repopulate based on filters. This can unintentionally trigger workflows if enrollment logic is not reviewed carefully.
Sandbox environments do not share record IDs with production. Any integration or custom code relying on hardcoded IDs will fail. Integrations should always connect sandbox environments to test or sandbox versions of external systems, never production systems.
Sandbox emails are real emails. If real contacts are enrolled in workflows, they will receive messages. A global suppression list using internal or test email domains should always be applied before testing automation.
Website pages and blog posts cannot be deployed from a HubSpot standard sandbox to production. While themes, templates, and modules can be deployed, page-level content must be recreated manually in production, typically by copying and pasting from the sandbox. Teams should plan CMS testing accordingly and avoid building landing pages in the sandbox with the expectation that they can be pushed live.
Connected apps are not copied into a HubSpot standard sandbox. Integrations such as Salesforce, Slack, Zoom, and other third-party apps must be reconnected manually. Production systems should never be connected to a sandbox environment, as this can result in production data being written from sandbox activity. When integrations are required for testing, teams should always use sandbox-to-sandbox or test credentials to avoid polluting live systems.
Standard sandboxes also introduce stricter data syncing behavior that impacts longer-term testing. It’s important to understand these limitations before you start testing.
This means new leads or updated contact data in production will not appear in an existing sandbox unless handled manually.
While certain assets, such as workflows, lists, and forms, can be re-synced, doing so overwrites sandbox changes. Contacts and leads are not included in these re-sync actions.
To work with updated data, teams must manually export records from production and import them into the sandbox using CSV files. Relationships can be preserved using multi-object imports with shared keys and automatic contact-company association.
There are a few technical limits worth planning for:
These limits should be considered when planning what types of testing are realistic in a standard sandbox.
Migrating from a HubSpot legacy sandbox to a standard sandbox is an opportunity to reset how testing and deployment are handled.
Before deleting a legacy sandbox, confirm that no critical assets exist only in that environment, including:
Anything worth keeping should be documented or recreated.
When creating the new sandbox, syncing all supported assets is recommended. Partial syncs often lead to missing dependencies and unreliable tests. Keep the legacy sandbox active until validation is complete.
Standard sandboxes do not automatically copy users or integrations. Teams must:
Any required data imports should be completed before testing begins.
Deploy a small, net-new asset as a validation test. Confirm deployment behavior, workflow status, and dependencies. Once validated, the legacy sandbox can be safely deleted.
Standard sandboxes work best when teams are clear about what they are trying to accomplish.
If you are building a brand-new feature, workflow, or process, the sandbox is the right place to do that work. You can test thoroughly and deploy with confidence.
If you are modifying an existing complex process, the sandbox is still valuable, but cloning is required. Testing should focus on validating logic, not replacing production assets directly.
If you are updating existing properties or pipelines, the sandbox is best used to understand the downstream impact. The actual changes should be made manually in production.
Clear decision-making upfront prevents wasted effort and frustration.
As teams adjust to standard sandboxes, here are a few best practices that can help you use them more effectively:
Following these practices helps ensure sandbox work stays aligned with how changes are actually deployed.
The move from HubSpot legacy sandboxes to standard sandboxes represents a clear improvement in how teams can test major changes to their CRM. Standard sandboxes provide more structure around syncing and deployment, reducing the amount of manual rebuilding that was required in the past.
At the same time, standard sandboxes behave differently from legacy environments. Understanding how asset deployment, data syncing, and testing constraints work is key to using them effectively. When teams account for these nuances upfront, the sandbox becomes a reliable part of the change process rather than a source of confusion.
With the legacy sandbox being retired, standard sandboxes will be the default way teams test and deploy changes in HubSpot. Used with the right expectations, they offer a more consistent and production-safe path from testing to live implementation.
Need help implementing this in your portal? Contact the Pros.
