We recently introduced an improved Standard Sandbox, including the new Deploy to Production feature for the most requested supported asset types. These enhancements empower RevOps and Marketing Ops teams to safely test business logic, data flows, and nurture workflows in a dedicated environment without risking disruption in their production accounts.
To support this upgrade, Legacy Standard Sandboxes will be sunset on March 16, 2026.
If you currently use a legacy sandbox, this guide outlines what’s changing, how to prepare, and what actions your team should take to ensure a smooth transition.
What This Means for You
To support this change, your sandbox limit will be temporarily increased so you can create and configure a new standard sandbox while still accessing your legacy sandbox.
- Most customers will experience minimal impact.
- Teams with connected apps that orchestrates data flow across systems may need to review and reconnect certain elements in the new sandbox.
The new standard sandbox includes:
- A more accurate representation of the most requested supported asset types
- A new Deploy to Production feature for supported asset types
FAQ — What You Need to Do Before March 16, 2026
Who can make these changes
Any Super Admin can create a new standard sandbox and delete the legacy one. We recommend coordinating with the Super Admins who actively use sandboxes and maintain integrations to assess the requirements.
If you have questions not answered in this FAQ please reach out to your Customer Success Manager or visit the HubSpot Help Center.
How to assess your migration needs
- Create your new Standard Sandbox
Your temporary sandbox limit allows you to create it without deleting your legacy sandbox. - Review whats in your Legacy Sandbox
Identify any integrations, apps, or automations your tech stack depends on, for example:
- Connected private or public apps
- Workflows that send data externally through webhooks
- Custom-coded workflow actions
- Recreate or reconnect what you need
If you use integrations or apps, you may need to:
- Reconnect private and public apps
- Update authentication or secrets in integrations settings and workflows with webhooks
- Validate your setup in the new sandbox
Ensure integrations, authentication, and any data-flow-related logic are functioning correctly by comparing them against your legacy sandbox or requirement documentation. - Delete your Legacy Sandbox
Once your new sandbox is fully operational, delete the legacy sandbox. Your temporary sandbox limit increase will be removed.
What happens to legacy sandboxes on March 16, 2026
If you don’t migrate before March 16, you will lose access to your legacy sandboxes. After that date, only the new Standard Sandbox will be supported.
Who Is Impacted
Most Customers (Simple Testing Use Cases)
Most teams will experience minimal impact and can simply:
- Create a new standard sandbox
- Confirm no migration needs exist
- Delete their legacy sandbox
Customers Using Private/Public Apps
If your sandbox connects to external systems, expect a deeper review. You may need to:
- Assess and reconnect private or public apps
- Refresh authentication tokens, secrets, scopes
- Update references to your new sandbox’s account ID
- Review workflows that contain webhooks or custom-coded actions
- Once validated, you can delete your legacy sandbox
Why We’re Making This Change
Legacy sandboxes were foundational, but they had key limitations, especially around tracking changes critical for supporting safe, predictable deployments to production.
The new Standard Sandbox addresses these challenges with:
A production-like environment for supported assets
A more accurate representation of supported assets, allowing you to test confidently without disrupting live systems or your end users in production.
A native Deploy to Production experience for supported assets
You no longer need to rebuild supported assets manually once testing is complete. The new deployment technology provides:
- Predictable, safer deployments
- Visibility into eligible assets and required connected assets
- Conflict warnings
- Deployment logs for transparency and troubleshooting
Why the legacy resync feature is removed
Although the resync feature felt useful, it introduced major instability in sandbox development. It could overwrite in-progress work, break change tracking, disrupt reliable development practices, and increase the risk of errors when deploying changes to production. Removing resync eliminates these risks and ensures sandboxes remain clean, consistent environments you can trust.
How to get a fresh copy of production
To maintain a reliable development environment, your sandbox should be recreated, not resynced, whenever you need a fresh copy of production. Recreating your sandbox eliminates drift, restores a clean baseline, and ensures that what you test behaves the same way in production.
This change makes deployments more predictable and aligns our process with industry standards for managing development environments and deploying tested changes to production safely.
How to Manage Your Sandboxes Going Forward
To get you started adopting this new way of working with the delete and create model consider implementing lightweight governance practices such as:
- Defining when a sandbox should be recreated
- Assigning clear ownership and access
- Keeping sandboxes purpose-driven and uncluttered
- Deploying changes intentionally, not reactively
Together, these practices support safer deployments, reduce operational risk, and clarify how sandboxes should be managed across your organization. Here’s a framework to help you get started.
Checklist for Customers with Connected Apps
If your legacy sandbox has connected apps, review the following when assessing configuration requirements in your new standard sandbox:
Account IDs
- Each sandbox has a unique ID. Update any systems that reference your legacy sandbox’s ID.
API calls, authentication, and secrets
- Generate new credentials in your new sandbox and update external systems if needed.
Private & Public Apps
- Private apps: reconnect and generate new tokens (Developer docs here)
- Public apps: reauthorize following developer documentation here
Workflows with Webhooks or Custom-Coded Actions
- Review and update webhook and custom-coded actions
- Update authentication types (KB article here)
- Re-enter endpoint details
CRM Data Imports
If you test data flow across systems, you may need to reimport CRM records.
Because record IDs differ between production and sandbox, consider using a consistent identifier:
- In Production: Create a custom property (e.g., “external ID”)
- In Production: Use a workflow to copy record IDs into this property
- In Sandbox: Use this external ID to upsert records
Next Steps
If you haven’t already, the best next step is to create your new Standard Sandbox and review what may need to migrate. Most of the work will be straightforward, and if you have integrations, a bit of early review ensures a smooth transition.
Final Thoughts
We know this change represents a shift in how you’ve used sandboxes in the past. We’re sharing it early to give you clarity and confidence throughout this transition.
The improved Standard Sandbox, with its production-like environment and Deploy to Production, helps you build, test, and deploy changes the way modern teams should: safer, more predictable, and more efficient.
Questions or concerns? Join us in the Developer Community Forum for a peer-to-peer discussion.