---
sourceDocument: Australia Build or modify applications
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/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 October 20, 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
When working with Developer Sandboxes in ServiceNow, it is crucial to understand how cloning and upgrading affect sandbox instances.
Always back up your work before performing these operations, as sandboxes are automatically retired during upgrades or clones, which can result in loss of unsaved changes.
Proper backup and restoration processes ensure continuity and integrity of your customizations and development work.
Show full answer Show less
## Key Considerations for Upgrading Instances with Developer Sandboxes
* Family, patch, and security upgrades automatically retire all existing sandboxes.
* Sandboxes are recreated post-upgrade, but any changes made in pre-existing sandboxes must be manually restored.
* Developer Sandboxes automatically back up update sets from sandboxes to the base instance, provided the update set has at least one change since sandbox creation.
* Backups are accessible in the retrieved update sets table, named with the sandbox name and backup date.
* After upgrading, you can create new sandboxes immediately without contacting Support.
* Custom table configurations or fixes must be reapplied manually after an upgrade; contact Now Support if needed.
* For source control users, restore sandbox work from your source control system instead of update sets.
* Automatic backup functionality is available only on instances running Australia Patch 3 or later.
## Key Considerations for Cloning Instances with Developer Sandboxes
* Sandboxes are **not** automatically recreated after cloning; save your sandbox work before cloning to enable restoration.
* Install the Dev Sandboxes CC plugin (com.glide.dsb.cc) on the source instance to enable clone preservers, which maintain Developer Sandboxes features on the target instance.
* If using custom clone profiles, ensure related clone cleanup scripts, data exclude lists, and data preserver lists linked to Developer Sandboxes are included to maintain sandbox functionality post-clone.
* Manual restoration of saved work is required after cloning.
## Practical Advice for ServiceNow Customers
* Always export update sets or commit changes to source control before upgrading or cloning to prevent data loss.
* Regularly review and commit remote update sets created automatically by Developer Sandboxes to keep work synchronized.
* Understand your instance's patch level to know if automatic update set backups are available.
* Coordinate with ServiceNow Support if you encounter issues with upgrades or need to reapply custom configurations.
* Leverage clone preservers and plugins to streamline sandbox functionality preservation during cloning.
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://www.servicenow.com/docs/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://www.servicenow.com/docs/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://www.servicenow.com/docs/y~WASxZ1VxWQrZAIauSFKQ "Use source control with Developer Sandboxes to enable parallel development and help avoid 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 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](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}