---
sourceDocument: Australia Build or modify applications
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/pt-BR/application-development

 Release :

    - australia

ft:locale :

    - pt-BR

ft:publication_title :

    - Australia Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Legacy - Production deployment tips

# Legacy - Production deployment tips {#ariaid-title1}

* Versão de lançamento: Australia
* 
* Atualizado 12 de mar. de 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 min. de leitura

When you develop customizations to applications on the ServiceNow®
platform, you deploy them via the application repository to a production instance. This topic
examines and provides cautions for the tradeoffs between installing an application from the
application repository versus Git repository with source control.  
Importante:  
Starting with the Xanadu release, the legacy version of ServiceNow Studio is being prepared for future deprecation. It will be hidden and no longer activated on new instances but will continue to be supported. For details on the deprecation process, see the [Deprecation Process \[KB0867184\]](https://support.servicenow.com/kb_view.do?sysparm_article=KB0867184) article in the Now Support Knowledge Base.

Try building and editing apps in the current version of ServiceNow Studio instead. For more information, see [ServiceNow Studio](https://servicenow-prod.fluidtopics.net/HJE5fDsb~bjmVZ9BqGtS8w "ServiceNow Studio provides a unified experience for all ServiceNow development activities, enabling admins and developers to extend base system solutions and create custom apps with ease. Use ServiceNow Studio to build apps and app files with integrated tools, access and edit app metadata in scoped and global apps, and package app changes for deployment, all in one powerful development tool.").

## Overview or deploying to production {#tips-production-deployment__section_nkb_4mv_mqb}

Technically, you can still "deploy" an application from a Git repository to a production
instance using source control. This can have unintended consequences.

## Glossary of terms {#tips-production-deployment__section_zbg_2mv_mqb}

{#tips-production-deployment__table_ik3_gmv_mqb__entry__2}

| Term | Definition |
|-|-|
| [Metadata or application files](https://servicenow-prod.fluidtopics.net/F~gg2JmnPm9DCmQQSVtj1g "Application files are configuration records that allow developers to extend application functionality.") | The sys_metadata records that define configuration in ServiceNow and are packaged in an application. These records alter the behavior of the instance but do not contain data such as incident or CMDB records. (See Note below) |
| [Scoped applications](https://servicenow-prod.fluidtopics.net/dpABJ5Jynnn9dK2h3GuwXg "Application scoping protects applications by identifying and restricting access to application files and data.") | ServiceNow applications that restrict allowing only updates and operations within the boundary of the scope. This mechanism is used for most new development. |
| [Global applications](https://servicenow-prod.fluidtopics.net/dpABJ5Jynnn9dK2h3GuwXg "Application scoping protects applications by identifying and restricting access to application files and data.") | Global applications are developed in the legacy global scope. Work is often done in this scope to customize existing ServiceNow applications such as IT Service Management (ITSM). |
| [Application repository](https://servicenow-prod.fluidtopics.net/apKZle1m7VYjJA7qSzDrAQ "After you develop and test a custom application, you can make the application available to company instances by publishing it to the ServiceNow application repository.") | Applications are typically published here for deployment in production instances. Although the application repository has separate entitlement rules, it operates similarly to the ServiceNow Store. |
| [ServiceNow Store](https://www.servicenow.com/docs/access?context=t_InstallApplications&version=australia&pubname=australia-platform-administration&ft:locale=en-US) | Repository for third-party (vendor) applications as well as ServiceNow published applications. Most customers do not publish to the Store, but often install applications from it. |
| [Update sets](https://servicenow-prod.fluidtopics.net/2n0mjX_i1izL9pTdrKeFbQ "An update set is a group of configuration changes that can be moved from one instance to another. This feature allows administrators to group a series of changes into a named set and then move them as a unit to other systems for testing or deployment.") | Standard method of packaging customizations for deployment in each successive instance. They contain the incremental collection of insertions, updates, and deletions. |
| [Legacy - Delta loading](https://servicenow-prod.fluidtopics.net/Hnw1DHfpA~Plmb0MTM_Z9Q "\"Delta loading\" is an optimized way to load an application from a Git repository.") | The most efficient method of loading because it changes only from source control rather than earlier uninstall/reinstall methods. |
| Schema | Definition of tables and columns in the tables. |
| [Rollback](https://www.servicenow.com/docs/access?context=rollback-scoped-applications&version=australia&pubname=australia-platform-administration&ft:locale=en-US) | Administrators can roll back the last installation of a selected application. A rollback removes all code, table, and file updates from the initial installation. |
[ ]

{#tips-production-deployment__table_ik3_gmv_mqb}  
Nota:  
The sys_metadata table is the parent table of all application files in the ServiceNow platform using the table inheritance model. You can view summary information for metadata by visiting the parent table or tables that extend directly or indirectly as indicated by the Extends table(super_class) field on the Table(sys_db_object record). You can also see the whole schema by visiting the Table(sys_db_object) form for the sys_metadata table and selecting the Show Schema Map related link at the bottom of the form. The schema is large and so takes some time to render.

## Installation location {#tips-production-deployment__section_vtz_tmv_mqb}

When you install source control, it facilitates the ongoing development of a custom application. Therefore, the application is managed as an "In development" application in the Custom Application \[sys_app\] table rather than as an "Installed" application in the Store Application \[sys_store_app\] table. Both tables are extensions of sys_scope so they both provide the same protections and restrictions as the scope. So when you search for the installation of a source control deployed application, refer to the System Application \[sys_app\] table and the in development section of the Application Manager page.

You cannot have a sys_app
record on the instance while deploying that same application from the ServiceNow Store or
application repository. The two deployment models are mutually exclusive. If at any point the
deployment model changes, the sys_app record must be converted to a sys_store_app record first.
You can contact ServiceNow Support for help with performing that operation.

## Delta loading {#tips-production-deployment__section_d1r_1nv_mqb}

Prior to the ServiceNow Paris release, application installation from
source control always removed and reinstalled the entire application when triggered, including
the Apply Remote Changes function. With [Legacy - Delta loading](https://servicenow-prod.fluidtopics.net/Hnw1DHfpA~Plmb0MTM_Z9Q "\"Delta loading\" is an optimized way to load an application from a Git repository."), now only the changes
update, simplifying the process considerably.  
The Delta loading process loads the changes from source control incrementally. When you apply remote changes, you don't drop existing tables or columns unless they were removed from the repository. This preserves the data for tables and fields that continued to be present.  
Nota:  
The glide.source_control.allow_delta_loading_in_scopedapp property allows you to disable Delta loading in Paris; however, this will revert to the more destructive behavior of removing and reinstalling the application. Global applications in Paris always use Delta loading.  
Below is a table of the different expected outcomes in an instance using Delta loading. {#tips-production-deployment__table_dkm_tc1_pqb__entry__6}

| Application type | Install source | Schema present in package | Schema contains data | Claim by another app (Global) | Expected outcome for data and schema |
|-|-|-|-|-|-|
| Scoped | Application repository or Store | Yes | Yes/No | N/A | Preserved |
| Scoped | Application repository or Store | No | Yes/No | N/A | Preserved |
| Scoped | Source control | Yes | Yes/No | N/A | Preserved |
| Scoped | Source control | No | Yes/No | N/A | Removed |
| Global | Source control, Application repository, or Store | Yes | Yes/No | Yes/No | Preserved |
| Global | Source control, Application repository, or Store | No | Yes | No | Preserved (1) |
| Global | Source control, Application repository, or Store | No | No | Yes | Preserved (2) |
| Global | Source control | No | No | No | Removed (3) |
| Global | Application repository | No | No | No | Preserved |
[ ]

{#tips-production-deployment__table_dkm_tc1_pqb}  
Nota:  
* While the database schema and the data are preserved, they will be moved into the default global application.
* While the database schema and the data are preserved, they will be moved into the global application which previously held claim to these files if installed. Otherwise, they will move into default global application.
* Applicable only on custom columns with u_ prefix. ServiceNow platform-authored columns are not dropped.
{#tips-production-deployment__ul_y22_1nr_hcc}

When switching branches in source control for a scoped application, use extreme caution in a
production environment. If the target branch is missing schema elements found in the current
branch, the related schema is dropped, destroying any data it contains. (Global applications do
not drop schema when data is present.)

Just as with update sets, only a subset of the incremental changes needs to be applied with
Delta loading. Unlike update sets, the application package represents the complete application.
Files that are absent from the new package are deleted. This can alter functionality and delete
data. Update sets and applications upgraded from the application repository or ServiceNow Store must have an explicit DELETE payload
to remove a file or drop a schema.  
If application files are being generated dynamically in any fashion, the next install/apply remote changes the operation of an application deletes those records. They are considered absent from the incoming application package. If you stash local changes, the application files may be recoverable by a stash commit, but if data is lost as a result of the changes, the data is not recovered.  
Nota:  
Removing or suppressing sys_update_xml records prevents them from being removed by Delta loading; however, this action can have other severe or undesirable results.

Direct edits to the repository, especially to remove files, can have significant
ramifications, including loss of data and cascading deletes. Perform this action with care.
* **[Legacy - Author elective and customer updates](https://servicenow-prod.fluidtopics.net/EJql559hP8FCXFqMpu3CFw)**   
  When you install an application from the application repository or ServiceNow® store, you can set a series of properties to define the behavior of delete and choice processing. These kinds of choices are called an "author-elective" feature.
* **[Legacy - Roll back, back out, and uninstall](https://servicenow-prod.fluidtopics.net/h1IBZegfwtLdM9hzQ7ANIw)**   
  The application installation from the application repository is recorded for rollback, which means as an administrator, you can roll back the last installation of a selected application. When you roll back an application, you remove all code, table, and file updates from the initial installation.
* **[Legacy - Upgrade history](https://servicenow-prod.fluidtopics.net/c7Hu_QYfXgI99gwLgFOvcw)**   
  Upgrade history records and history line dispositions are generated as part of the source control installation providing a record of the install.
* **[Legacy - Development considerations](https://servicenow-prod.fluidtopics.net/bdYpSTUT5NljOQ0jCDqaaA)**   
  When you are developing code, consider some of these suggestions for the most efficient performance.

