Deadline Extended for Legacy Standard Sandboxes Sunset: What’s Changing & How to Prepare (FAQ)

[Denise_Thijzen]

On December 15, 2025, we’re introducing 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 April 30, 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.

Key Dates

• December 15, 2025: New Standard Sandboxes launch
• April 30, 2026: Legacy Standard Sandboxes sunset

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 April 30, 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 what’s in your legacy sandbox

Identify any integrations, apps, or automation 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 integration 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 April 30, 2026

If you don’t migrate before April 30, 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.

[DanMYD]

Huge miss on this update because now you can’t sync updated/new assets from production to an existing sandbox. So yes, now you get a deploy to production, but if you want an actually useful sandbox environment that can be used for any realistic testing, you have to…

• erase the entire sandbox
• recreate it
• turn back on all the relevant workflows

Otherwise you don’t have updated schemas, relevant workflows, etc. etc.
To be a real enterprise solution, there should be the ability to have Sandbox, UAT, and Prod. You should be able to sync prod assets to sandbox to replicate the environment OR the sandbox should be an exact replica with all assets and all workflows activated to match production.
This was one step forward and two steps back.

[SealaB]

Hi @DanMYD,

Thank you for sharing this candid feedback.
I completely understand your frustration here - while the new Deploy to Production feature solves for moving things up safely, the removal of the “Resync” feature makes keeping the Sandbox environment current with Production (moving things down) is clearly having an impact.

The intention behind removing “Resync” was indeed to prevent the accidental overwriting of in-progress development work (which happened often with the old button), but I hear you loud and clear that a full “wipe and replace” is not ideal.

I have flagged your comment specifically to @Denise_Thijzen and the product team so they can review this perspective and use case.

In the meantime, if you have a specific list of assets that are the most painful to re-configure after a recreation (e.g., specific workflow types or schema settings), please feel free to list them here. The more specific detail we have on where the friction is highest, the better information the team has for future Sandbox capabilities.

[Denise_Thijzen]

Hi @DanMYD

Thanks for sharing your perspective. We recognize this represents a meaningful change in how some teams have used HubSpot sandboxes in the past, and it’s worth clarifying why this change was necessary.

The removal of the legacy re-sync capability was not arbitrary. In practice, full or incremental environment re-syncs introduce substantial risk to reliable change tracking, cause divergence, and make deploying changes from sandbox to production high-risk and error-prone. Because of this, re-sync is not considered a recommended or safe pattern for governed deployment workflows.

After extensive research and engineering review, our decision to sunset re-sync was informed by well-established industry standards for reliable, auditable deployment practices.

It’s also important to emphasize that Sandboxes are moving forward. The new Sandbox experience was designed to provide significantly more control and predictability and includes:

• Broader and more accurate representation of supported assets
• A brand-new Deploy to Production capability that the legacy sandbox could not support
• Change tracking, conflict detection, and dependency awareness to improve deployment confidence
• A deployment flow that clearly shows what will be promoted to production before it happens

These capabilities did not exist previously and are intended to reduce reliance on destructive resets while providing a clean, governed, and auditable path for moving changes forward.

We understand this is a shift from how HubSpot sandboxes may have been used historically. In practice, this does require stronger governance around how sandboxes are maintained, which may include planning for periodic recreation or using additional sandboxes depending on testing needs.

Finally, this is only the first slate of supported assets. We’re actively working on expanding coverage as part of the roadmap, and feedback like this continues to inform where we invest next.

[hkampen]

The inability to synchronise elements from production to the sandbox makes work considerably more difficult. Various departments and external service providers only work in Production, and that is not going to change anytime soon. In general, I agree that synchronising from the sandbox to Production is the only correct way to go, but that is not how it works in practice. For companies that have extensive data in the sandbox and whose sandbox is connected to various systems, recreating the sandbox is not an option. Ultimately, this leads to copies of workflows, for example, being created in the sandbox, which makes it impossible to transfer data from the sandbox to production.

I would welcome the ability to at least synchronise individual elements, such as data fields, from production to the sandbox. Currently, I have to build the synchronisation myself, which probably leads to more inconsistencies than a two-way synchronisation within HubSpot.

[StefanWendt]

Thank you for the info @Denise_Thijzen, looking forward to the new Sandboxes!

But what about the short timeline? Is there any migration feature from HubSpot to move data, processes, automations to the new sandbox-environment?

Best,

Stefan

[thorstenheissel]

Hi @Denise_Thijzen, we do not have enough time to migrate all Sanboxes of existing customers to the new Saynbox. We have many CMS customers and we spent significant amount of time to set up the sandboxes. This incudes creating pages, integrations, membership portals and more. The effort for each portal is mutilpe days.
Is there a way to get exceptions for certain customers (many strategic accounts included)

[Denise_Thijzen]

Hi @hkampen, thank you for sharing your perspective. You’re describing a set of workflows we’ve often seen across sandbox users, especially where sandboxes are either long-lived because they’re heavily connected to various integrations, or where different teams are doing various things in one single sandbox.

You’re right that sandbox → production is the correct direction of travel. As you noted, given that many teams have come to rely on recurrent production → sandbox resyncs to keep things moving, these two realities came into direct conflict and introduced a myriad of risks for maturing the HubSpot Sandbox.

Why production → sandbox sync had to change

The core reason we removed resync / selective sync in the new sandbox architecture is reliability and safety:

• Selective resyncs cause sandboxes to diverge unpredictably from production over time, especially when different users were constantly making micro decisions to resync all or selectively sync assets on any given moment of the day.
• That constant divergence made it impossible to reliably detect what actually changed in a sandbox.
• Without a trustworthy reference state, any two-way or incremental resync introduces a real risk of overwriting production unintentionally or impacting active development in sandboxes.

In other words: production → sandbox resync might have seemed to facilitate short-term iterations, but it fundamentally blocked us from ever delivering a safe deploy to production feature to support enterprise-grade testing and deployment workflows. The decision to no longer support resync isn’t unique to HubSpot, platforms that support deploy to production at scale do not allow ad-hoc resyncs for these reasons.

On syncing individual elements (like properties)

We understand the idea of at least allowing to syncronize individual fields from production → sandbox. The issue is that even individual elements don’t exist in isolation, for example they’re referenced by workflows, integrations, validation rules, lists, emails and so forth. Partial syncs are exactly what created the inconsistencies and blocked us from delivering a reliable and low risk deploy to production feature. So, on the mid/long term, rather than re-introducing this risk, we’re focused on:

• Reducing the need for users to manually recreate or copy assets in either direction by continuing to deliver support for newer asset types.
• Continue to expand the sandbox → production deployment experience to offer a broader and more reliable one.

On the topic of navigating governance such as multiple sandboxes or various teams, I’d recommend reading Smarter Sandboxes for Safer Deployments blog post which delves into the topic providing a brief framework to get teams started.

We’re also open to talking with users about the next slate of supported assets needed to get closer to a full mirror of production. So if you’re open to it, please let us know and we can get a call scheduled.

[Denise_Thijzen]

Hi @StefanWendt

Can you share an overview of what exactly you’re looking to migrate? For example:

• which asset types
• which configurations
• do these assets only exist in the legacy sandbox or have they also been manually recreated in production

I’m happy to set up a call to discuss the nuances and see if there are any recommendations. Let us know if that’s something you’d like to do. Thanks!

[Denise_Thijzen]

Hi @thorstenheissel, I’ve reached out over DMs to gather more context!

[CDean]

+1 on this being a net negative.

• The deployment from sandbox to production is not very useful. It does not push up any edits– only new things. A huge portion of updates are edits rather than new.
• The loss of sync from prod to sandbox is huge. Overwriting sandbox junk is a good thing. The entire point of sandbox is trial and error.
• Proper version control would solve all of this. A sync screen similar to the de-duplication would prevent accidental loss by choosing which version to keep/overwrite. This would work for both syncing down and deploying up.
• The new sandbox creation should have had the option to copy the existing legacy sandbox. This would at least alleviate the problems people have with the extremely short turnaround time on this sunset. If nothing else, please give much more time for updates that cause fires.

[DWinnyk]

I’m excited about this new feature, definitely a big step foward! Thanks for the work!
However, I echo the concerns of other users here.
Key features we need to see in the future:
1. Syncing updates to properties that exist in production.

2. Pull changes from production down to the sandbox

3. Version control (This is probably a HUGE ask, but would be so nice)
Some reasoning:
1. Building good products is an iterative process. Not being able to push changes to existing properties or workflows means we are stuck at single iterations.

2. Easily maintaining alignment between sandbox and production environments is a huge advantage for dev teams and user assurance testing.
3. Being able to push, pull, and roll back changes gives organizations a safety net when pushing big changes. A bad push in the current HubSpot could take hours to undo.
Again, big step forward here with this feature. Super thrilled to roll this out to our organization and thanks for all the hard work on updating the product!

[DKR91]

Thanks for moving forward on this. However I was wondering if it would port over themes/React CMS as well and you could test new deployments like this. Else it’s not fully useable since you can’t fully test end to end.

[hkampen]

Hi,

I understand the possible issues, but I think there are some which can be synched from production to sandbox without concerns.

First of all I miss the views after sandbox creation. Views can be synched without impact if none existing or archived fields in the sandbox are ignored.

To synch fields will be a bit more difficult. If the fields are archived or the options are changed, it can causes conflicts, but I think that can be solved. I do that now with a script.

A subset of elements synched from production to sandbox would really help.

[Monjogard]

I agree with comments above around not being able to sync from prod to sandbox. So many tiny things are edited and updated in the production environment every other week that the sandbox will never be up to date without an ability to sync assets to the sandbox. If you’re concerned about overwriting “stuff ready to be deployed” in th sandbox, then add a feature to the sync where you can select what to keep from the sandbox and what to overwrite with from production.
Like most commenters mentioned above, this means we have to delete and recreate the sandbox every time we prep for a major change. This also then includes updating integrations, connected apps etc. While I’ve been longing for the the sync to prod feature, removing the sync to sandbox feature will make this change net negative.

[DaleGearhart]

Here is another issue I have but this was true with the legacy SB as well. Custom object records. They still have to be exported/imported, and it breaks all associations. An export will have the associated record IDs but they won’t match any IDs in the SB. It seems the recommended course of action is to create new properties in all objects, replicate the record id’s to these new “production account record id”, so on the backend in the SB - you can take your imported data and create a workflow to re-associate.

(1) why are custom object records not included? This is 2026 - cars can parrallel park themselves. But we can’t have custom object records included in our sandbox sync?

(2) if they just can’t be, then why can’t the task of adding the prod portal record id be part of the sandbox creation? It doesn’t seem like it would be that hard to create (another) hubspot provided property that is the prod portal record id that is simply the record id value carried over. Its a lot more involved for me to add the property to all the objects and create workflows to update the values.

[hattiefawcett]

I’ve just had to delete and recreate our standard sandbox rather than refresh it, which works, but is pretty painful for ongoing dev and integration work. I’m also guessing the new sandbox will generate new portal and asset IDs (objects, properties, records), meaning code and APIs need updating.

Whilst I love the “push to prod” feature, losing a simple refresh option makes it harder to keep a sandbox aligned with prod over time, and the reduced contact limits make realistic integration load stress testing impossible so we can’t even be sure if stuff will break until it’s been pushed to prod…

Would also like to see options like ID parity between prod and sandbox (Salesforce does this) or more flexibility around refreshes - both would make standard sandboxes much easier to work with in real-world setups. I get the risks around overwriting from prod to sandbox but with proper process documentation it’s not been an issue for us so this new update is actually a lot more extra work.

[LauraRoberts]

Our sandbox honestly ends up being a test for integrations and imports/migrations more than anything else, with the tool running, and then we check to make sure it did all the correct things. After each run I’m quite happy to get fresh data and try again with some tweaks. I suppose this means in some ways that it should be relatively low-impact for me to recreate the sandbox each time, but I might be doing 5 tests in a single day so it would be pretty tiresome to need to set up a sandbox each time, including potentially needing to invite test users. I do understand the potential issues with production to sandbox sync when everything is open to changes in both, though I do agree with others that a versioning tool similar to git, particularly the merge conflicts remediation, would suffice here and most of us will be familiar with it. For simple things like mine though, would it be possible to have a different kind of sandbox that would effectively be a copy of production, except the app can be there and not effect the actual production records? In other words, even without version control, if the only things allowed to change the sandbox are the app(s) being tested and syncs from production, have the syncs be manual only and understood to be overwriting everything but the app connection(s). Perhaps this is kind of niche to ask for, but honestly don’t devs pretty frequently need to be testing this way? How many of us are just using the app for the API key and all of our code is otherwise external?

I’m also hoping that with the myriad of edit types that don’t deploy, that there’s some tracker that gives a checklist of things to do in Production, as explicitly and clearly as possible. This would be helpful for instance when a partner is figuring out the setup for a potential new brand, rebranding, or more complex migration/merger of portals. It would also be helpful just for all the people above doing more complex testing/changes while versioning isn’t a full feature (and the tracking of these in connection with property history and the like would be a step toward a full versioning solution)

[Logan_Armstrong]

Echoing the sentiments of other commenters. Love that we’re getting a deploy to production toolset, and I understand that sandbox to production only is the technical best practice, but in reality, this puts an Enterprise-only requirement, in immutable version control, ahead of the majority of users’ day-to-day operations.

Yes, this one-way data pipeline, is not unique to HubSpot, however HubSpot is not an engineering-focused platform, it’s a CRM. It’s not realistic, nor efficient, to set up new private apps, tokens, and otherwise external connections every time you want to refresh a sandbox. If we need to recreate a sandbox every time we want to refresh to production, what good is the version control?

At the least, could we not have a toggle of the ability to push production assets to sandbox, and forfeit version control capability? Or, just continue to at least be able to use a legacy sandbox? Transfer private app tokens and scopes to new sandboxes?
I appreciate that sandboxes are getting some much-needed love, but no production to sandbox refresh is a big miss.

[MR10C]

The new sandbox seems to be restricted to syncing CRM objects but none of the CMS objects like themes and modules. A big use case for our sandbox is to test out front-end changes. Will this still be possible?