---
sourceDocument: Australia Build or modify applications
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/application-development
Release :
- australia
ft:locale :
- en-US
ft:publication_title :
- Australia Build or modify applications
ft:clusterId :
- cadev
bundleId :
- cadev
workflow :
- Development, Data, and Analytics
---
# Clone and upgrade impact
# Cloning and upgrading considerations for Developer Sandboxes {#ariaid-title1}
Release version: Australia
Updated May 11, 2026
 2 minutes to read
Summarize
 Summarized using AI
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.
## Summary of Cloning and upgrading considerations for Developer Sandboxes
This content explains important considerations for ServiceNow customers using Developer Sandboxes when cloning or upgrading their instances.
It emphasizes the need to back up sandbox work prior to these operations, since sandboxes are retired automatically during upgrades or clones.
It provides guidance on how to preserve and restore sandbox work to avoid data loss and maintain sandbox functionality.
Show full answer Show less
## Key Considerations for Upgrading Instances with Developer Sandboxes
* Family, patch, and security upgrades automatically retire all existing sandboxes and recreate them.
* Changes made in pre-existing sandboxes must be manually restored from automatic backups created before the upgrade.
* Developer Sandboxes automatically back up update sets containing at least one change to the base instance.
* Backups are stored as remote update sets named with the sandbox and backup date, making it easy to identify and restore.
* Customers can immediately create new sandboxes after upgrades without contacting Support.
* Automatic backups are only available on instances running Australia Patch 3 or higher.
* Custom table configuration changes or fixes after upgrade require contacting Now Support.
* Source control users should restore sandbox work from their source control repositories.
## Key Considerations for Cloning Instances with Developer Sandboxes
* Sandboxes are **not** automatically recreated after a clone operation.
* It is essential to manually save and export sandbox work before cloning to enable restoration afterward.
* Install the **Dev Sandboxes CC plugin (com.glide.dsb.cc)** on the production instance to enable clone preservers, which maintain Developer Sandboxes feature enablement on the target instance after cloning.
* Custom clone profiles should link specific records (clone cleanup script, clone data exclude, clone data preserver) to preserve sandbox functionality when cloning over a sandbox instance.
## Practical Actions for ServiceNow Customers
* Always back up your sandbox work by exporting update sets or committing changes to source control before cloning or upgrading.
* After an upgrade, locate and review remote update sets backed up from sandboxes, then preview and commit changes as needed.
* If cloning, prepare by saving sandbox work and ensure necessary plugins and clone preservers are configured to maintain sandbox features on the target instance.
* Contact Now Support for assistance with reapplying custom table configurations or fixes after upgrades.
You should understand how plugins and sandboxes work before you clone or upgrade an instance with Developer Sandboxes. Always 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 {#dev-sbx-clone-upgrade-info__section_y2t_v5y_1hc}
Family, patch, and security upgrades automatically retire all existing sandboxes. Sandboxes are recreated, but any changes from pre-existing sandboxes must be manually restored from the automatic backup
created. After an upgrade, you can immediately begin creating new sandboxes without contacting Support.
Developer Sandboxes automatically backs up any update sets from the sandboxes and exports them to the base instance. 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.
{#dev-sbx-clone-upgrade-info__ul_pcr_cq5_khc}
Note:
When using sandboxes, make sure to save or backup work consistently. Automatic backups are available only for instances on Australia Patch 3 and higher.
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](https://servicenow-prod.fluidtopics.net/0kuMPeoACZH_aizb3hJfnw#t_PreviewARemoteUpdateSet "Previewing checks a retrieved update set against the local instance to find issues. Resolve all problems before committing the update set.") and [Commit an update set](https://servicenow-prod.fluidtopics.net/pWyuhY_Pxe5zjH9S9e9XWw "After resolving any issues from previewing, commit the update set to apply all changes and generate a local copy with records of each update.").
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](https://servicenow-prod.fluidtopics.net/y~WASxZ1VxWQrZAIauSFKQ "Use source control with Developer Sandboxes to enable parallel development and prevent merge conflicts.").
## Cloning instances with Developer Sandboxes {#dev-sbx-clone-upgrade-info__section_alj_bsz_1hc}
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 production 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](https://www.servicenow.com/docs/access?context=create-new-clone-preserver&version=australia&pubname=australia-platform-administration&ft:locale=en-US). For details on the plugin, see [Plugin information for all Australia features and products](https://www.servicenow.com/docs/access?context=rn-summary-plugin-info&version=australia&pubname=australia-release-notes&ft:locale=en-US).
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
{#dev-sbx-clone-upgrade-info__ul_vgq_pm2_vjc}