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

1. Create your new Standard Sandbox
   Your temporary sandbox limit allows you to create it without deleting your legacy sandbox.
   
   
2. 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
     
     
3. 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
     
     
4. 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.
   
   
5. 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:

1. Create a new standard sandbox
2. Confirm no migration needs exist
3. 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:

1. In Production: Create a custom property (e.g., “external ID”)
2. In Production: Use a workflow to copy record IDs into this property
3. 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.