Cloning and upgrading considerations for Developer Sandboxes

  • 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

    When working with Developer Sandboxes in ServiceNow, it is crucial to understand the impact of cloning and upgrading on your sandbox environments. Sandboxes are automatically retired during these processes, so preserving your work beforehand is essential to avoid data loss. This guidance explains best practices for backing up, restoring, and managing sandboxes during upgrades and clones.

    Show full answer Show less

    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 from automatic backups.
    • Developer Sandboxes automatically back up update sets from sandboxes to the base instance, provided the update set contains at least one change since sandbox creation.
    • Backups are stored in the retrieved update sets table, named to indicate the sandbox and backup date.
    • After upgrade, new sandboxes can be created immediately without support intervention.
    • For restoring work, review, preview, and commit update sets as needed or restore from source control if used.
    • Custom table configuration changes or fixes must be reapplied manually after upgrading; contact Now Support for assistance.
    • Automatic backups are available only on instances running Australia Patch 3 or higher.

    Cloning Instances with Developer Sandboxes

    • Sandboxes are not automatically recreated after a clone.
    • You must save and manually restore sandbox work before and after cloning.
    • To protect Developer Sandboxes feature enablement on the target instance, install the Dev Sandboxes CC (com.glide.dsb.cc) plugin on the production instance.
    • This plugin enables clone preservers, which help maintain sandbox configurations during cloning.

    Practical Recommendations

    • Always back up your sandbox work before cloning or upgrading by exporting update sets or committing changes to source control.
    • Regularly save and back up work to avoid data loss, especially since sandboxes retire automatically during upgrades and clones.
    • Use the automatic backup feature for update sets if your instance supports it (Australia Patch 3+).
    • After upgrades, restore your update sets by previewing and committing them within your sandboxes or from source control.
    • For cloning, prepare by saving sandbox work and utilize the Dev Sandboxes CC plugin to maintain sandbox enablement on the cloned instance.

    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

    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.
    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 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 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. For details on the plugin, see Plugin information for all Australia features and products.