Cloning and upgrading considerations for Developer Sandboxes

concept brazil Updated Oct 20, 2026 3 min read dev-sbx-clone-upgrade-info.md
Raw file servicenow.com

You should understand how plugins and sandboxes work before you clone or upgrade an instance with Developer Sandboxes. Back up your work in a sandbox before any clone or upgrade, either by exporting the update sets or committing to source control.

Warning: Because sandboxes are retired automatically after an upgrade or clone, ensure any work that you want to keep is preserved before upgrading or cloning.

  • For upgrades, you can restore work from the remote update sets that Developer Sandboxes automatically created from prior sandboxes.
  • For clones, you must manually save and restore all work in sandboxes.
  • Any custom table configuration changes or fixes must be reapplied after an upgrade. Contact Now Support to open a case.

Upgrading instances with Developer Sandboxes

Family, patch, and security upgrades automatically retire all existing sandboxesbefore the Brazil Patch 3 release. Sandboxes are recreated, but any changes from pre-existing sandboxes must be manually restored from the automatic backup created.

After an upgrade, sandbox recreation occurs automaticallyin releases before Brazil Patch 3, but sandboxes may not be available immediately. A status banner at the top of the Sandbox Management Home dashboard indicates when recreation is in progress.

Beginning with the Brazil Patch 3 release, upgrades keep existing sandboxes instead of retiring them. Retained sandboxes aren't upgraded with the base instance, so they might be out of date or lose some functionality. Out-of-date, retained sandboxes are identified on the Sandbox Management Home dashboard with a badge for family upgrades only.

Note: If a retained sandbox doesn't work as expected, back up your work by exporting the update sets or committing to source control, and then create a new sandbox.

Developer Sandboxes automatically backs up any update sets from the sandboxes and exports them to the base instancewhen an upgrade retires sandboxes. The following rules apply:

  • The update set must contain at least one change since the sandbox was created for it to be backed up.
  • Incomplete update sets are backed up as long as there's at least one change.

Note: When using sandboxes, make sure to save or back up work consistently. Automatic backups are available beginning with Australia Patch 3.

Backups are found in the retrieved update sets table, identified by the name of the sandbox they were backed up from. For example, "DSB [sandboxname] (backup date): [Original update set name]". For more information, see Preview a remote update set and Commit an update set.

Review the update sets, then preview and commit them in each sandbox as needed.

Note: If you're using source control, you should restore your work to the sandbox from there. For more information, see Source control and Developer Sandboxes.

Cloning instances with Developer Sandboxes

Note: Sandboxes are not automatically recreated after a clone. You should save your work from a sandbox before the clone so you can recreate it.

Install the Dev Sandboxes CC (com.glide.dsb.cc) plugin on the source instance to enable clone preservers that protect Developer Sandboxes feature enablement on your target instance. For more information on clone preservers, see Create a clone preserver.

If you have a custom clone profile, these records should be linked so that cloning over a sandbox instance maintains sandbox functionality:

  • clone_cleanup_script: /clone_cleanup_script.do?sys_id=2b5e8051ff03221016abffffffffff58
  • clone_data_exclude: /clone_data_exclude_list.do?sysparm_query=nameSTARTSWITHsys_dsb
  • clone_data_preserver: /clone_data_preserver_list.do?sysparm_query=tableSTARTSWITHsys_dsb%5ENQname%3DDSB%20Properties

Parent Topic:Developer Sandboxes

Search documentation
Search document titles and file paths on the brazil branch