---
sourceDocument: Australia Mobile Configuration and Navigation
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/mobile

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Mobile Configuration and Navigation

ft:clusterId :

    - mobile

bundleId :

    - mobile

workflow :

    - Development, Data and Analytics


---

# Migrate to New York \& later

# Mobile migration from Madrid to New York and later
releases {#ariaid-title1}

* Release version: Australia
* 
* Updated March 12, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 Mobile Migration from Madrid to New York and Later Releases

Migrating your mobile applications from the Madrid release to the New York release or later allows you to utilize enhanced features and continue editing in Studio.
The upgrade process involves activating the Mobile Agent Native Client plugin, which introduces a new mobile hierarchy and various tables to manage native clients, navigation bars, notifications, and settings.
Show full answer Show less  

## Key Features

* **New Mobile Hierarchy:** Transition to a structure that supports enhanced features like applet launchers and customizable navigation bars.
* **Migration Script:** This script converts modified and custom applications to the new mobile schema, ensuring compatibility with the updated system.
* **Debug Upgrade Feature:** Helps diagnose and resolve upgrade issues efficiently.
* **Regression Testing:** Essential for verifying that applications function as intended post-upgrade.

## Key Outcomes

After completing the migration and running the migration script, your applications will benefit from improved navigation and organization. Existing applications will continue to operate, but modified applications will require running the migration script for full functionality in Studio. The migration process also ensures that customizations are preserved and facilitates the transition to the new applet launcher format.  
Migrate your mobile applications in New York or later releases to take
advantage of the improved features and continue editing within Studio.

## Changes made during your upgrade {#sg-mobile-migration-ny__section_sn5_mmg_b3b}

During the upgrade from Madrid to New York or later releases, the instance updates to the new mobile hierarchy by activating the Mobile Agent Native Client \[com.glide.sg.agent_native_client\] plugin. This installation creates the following changes:

Native clients
:   Adds the Native Clients \[sys_sg_native_client\] table. Records on this table represent the
    available native clients; Mobile Agent, Now Mobile,
    and Mobile Onboarding.

Navigation bar
:   Adds the navigations \[sys_sg_navigation\] table. Records on this table represent a
    navigation bar for each of the native clients. Records on this table during the migration
    have their Legacy application \[legacy_application\] field enabled.

Notifications tab
:   Adds the notifications tabs \[sys_sg_notifications_tab\] table. Records on this table
    represent a tab for notifications on each navigation bar.

Settings tab
:   Adds the settings tabs \[sys_sg_settings_tab\] table. Records on this table represent a tab
    for settings on each navigation bar.

This upgrade includes new features such as application launchers and a configurable navigation
bar. Any unmodified base system mobile applications installed on your instance are automatically
updated to work with the new design, and can be used with Studio right away. For more detail on the
mobile hierarchy used in New York and
later, see [Mobile hierarchy](https://servicenow-prod.fluidtopics.net/quRHhTePhYULmOhDTWOqqg "Learn the components of ServiceNow mobile and how they work together to assist you in configuring, modifying, and creating applications.").

Modified base system applications, and applications that you have created in Madrid will continue to work after the
upgrade. These applications will not be configurable in Studio until after you have run the mobile
migration script.

## Post-upgrade considerations {#sg-mobile-migration-ny__section_kw4_gx3_z3b}

After an upgrade, consider the following information to confirm that your mobile
implementation is working as expected, and ensure that mobile migration script runs.

Modified base system applications
:   Document any changes you have made to mobile applications provided by ServiceNow, as well as any applications
    you have created. Test each of these applications to ensure that they continue to function as
    you expect.

Use the Debug Upgrade feature

:   The debug upgrade feature can help you to quickly diagnose upgrade issues. For information on this feature, see Debug upgrade.

    A video training course on this tool is available. To view this course, see [Using Debug Upgrade](https://nowlearning.service-now.com/lxp?id=overview&sys_id=f6f64ed9db123700760a7104399619c8&type=course)

Review skipped records

:   To prevent overriding your customizations, the upgrade process does not update records that you have modified. Instead, the upgrade process notes this skipped record in the upgrade logs.

    A video training course on resolving skipped records is available. To view this course, see
    [Upgrade Skipped Records](https://nowlearning.service-now.com/lxp?id=overview&sys_id=cbb197a6136b77002ff55eff3244b0b6&type=course).

Review functionality after upgrade
:   Once you have upgraded your instance and run the migration script, regression testing can
    help ensure that your users can continue to work as expected after an upgrade. A regression
    test is a review of your applets, screen ui policies, and functions to make sure that they are
    working as intended.

## Running Mobile migration script {#sg-mobile-migration-ny__section_at3_jng_b3b}

This script converts your custom applications and any modified base system application to the
new mobile schema available in the New York release. The script only changes the current scope when it runs. If you have more than one
scoped mobile application, you must run the script for each scope.

After an upgrade, the option to run the migration script appears when you first access a
custom application, or a base system application that you have modified. For example, when
opening a modified or custom applet record. You can also see the migration prompt when accessing
the applet picker in Studio by browsing to Mobile StudioApplets and clicking the pop-out icon (![Pop out icon]()). The migration prompt displays if any of the applets shown the picker require
migration.  

After the script completes, you may be prompted to resolve collisions detected by the
migration process. Collisions are records created by ServiceNow that you
have modified, and are not automatically upgraded. Collisions can only occur when you have
modified a base system application before your upgrade to New York or later
releases.  
Click the View Collisions to resolve these collisions. For detail on this process, see [Resolve common issues in mobile migration script results](https://servicenow-prod.fluidtopics.net/K2eVoTMCxB8EO5p8sBF9lQ "Find solutions to common issues after running the mobile migration script.").

## Changes made by the mobile migration script {#sg-mobile-migration-ny__section_ij3_1fj_z3b}

Click Migrate to start the migration script for the current scope. The
migration script migrates all records within the scope, not just the applet you have opened.  

Applications and folders transition to applet launchers

:   The legacy Madrid schema used mobile applications and folders to organize
    your applets. The Now Mobile schema, uses applet launcher screens,
    which are divided into UI sections. Applet launcher is accessed by tapping on tabs in the
    navigation bar which appears at the bottom of your app screens.

    Figure 1. Changes to applications in the New York schema

    The migration script creates an applet launcher for each mobile application record. The
    script converts each folder in the original mobile application to a new horizontal icon
    section within that applet launcher. The script then creates an icon in the icon section for
    each applet with the folder. Hidden screens do not appear in the icon section. The script
    then adds a tab to the navigation bar for each of the new applet launchers.

    The example image shows how the incidents application appears after the migration process.
    The original folders (My Incidents and Group Incidents) display as UI sections in the Incidents
    applet launcher. These UI sections can scroll horizontally to show as many applets as
    needed. The Incidents application is accessible by tapping the
    Incidents tab in the navigation bar.

    After migration, the script removes the legacy Folder \[sys_sg_folder\] and Mobile
    Application \[sys_sg_application\] records.

    For more detail on the navigation bar, applet launchers and their UI sections, see [Navigation bar](https://servicenow-prod.fluidtopics.net/qv5r2DDV9~FLyGe8Gq8j7A "User the navigation bar in your mobile apps to access launcher screens, screens, settings, and notifications."), and [Launcher screens](https://servicenow-prod.fluidtopics.net/j~FcnCpkp7WvBW6tncIm4A "Launcher screens serve as landing pages or home pages. Using a launcher screen, you can access screens in various formats, as well as search, do quick actions, and find user information.").

Form migration
:   The Form applet replaces the root detail screens used to view record forms in the Madrid release. The migration creates a form screen \[sys_sg_form_screen\] record.
    The script creates segments for each embedded screen in the original main detail screen. Any
    button \[sys_sg_button\] records associated to the original main detail screen change to
    associate with the new form applet.

Map migration
:   Map applets did not use an item view to display fields in map cards in the Madrid release. The migration script
    creates an item view\[sys_sg_item_view\] record for each map applet using the
    Title, Tag, Sub-title,
    and Info fields from the original map applet.

Calendar migration
:   The migration script creates time span item stream \[sys_sg_time_span_item_stream\] records
    for each calendar, and associates the calendars original data item to the new item stream.
    The migration script also creates a form applet \[sys_sg_form_screen\] record, and migrates the
    buttons from the calendars original embedded screen to the new form.

Item streams and Item configurations

:

    The migration script creates an item stream \[sys_sg_item_stream\] record for each screen in
    the scoped application. The original data item record associated with the legacy application
    changes to associate with the new item stream record. The script creates time span item
    stream \[sys_sg_time_span_item_stream\] records for each calendar screen, and location item
    stream \[sys_sg_location_item_stream\] records for map screens. These two tables extend from
    the item stream table, but are used specifically for these screen types.

Screen Cleanup
:   The following fields are no longer used in Screen records. The script removes these fields from call records on the Screen \[sys_sg_screen\] table.

    * User Roles \[application_roles\]
    * Order \[order\]
    * Parent \[parent\]
    * Parent table \[parent_table\]
    * Data Item \[sys_sg_data_item\]
    * Hidden \[hidden\]
    {#sg-mobile-migration-ny__ul_nk3_wjr_23b}

    In addition, the script also removes values from the following fields on Map screen \[sys_sg_map_screen\] records:

    * Data item table \[data_item_table\]
    * Title \[title\]
    * Sub-title \[subtitle\]
    * Info \[info\]
    * Location \[location\]
    * Tag \[tag\]
    * Tag font color \[tag_font_color\]
    * Tag background color\[tag_background_color\]
    * Tag Style \[tag_style\]
    * Phone \[phone\]
    * Pin color type \[pin_color_type\]
    * Pin color \[pin_color\]
    {#sg-mobile-migration-ny__ul_dpr_tkr_23b}

    The script removes values from the following fields on Item configuration \[sys_sg_master_item\] records:

    * Table \[table\]
    * Screen \[screen\]
    * Condition \[condition\]
    * Condition Order \[condition_order\]
    {#sg-mobile-migration-ny__ul_old_tlr_23b}

    The script removes the value in the Item View \[item_view\] field of Details screen
    \[sys_sg_details_screen\] records.

    The script removes the value in the Item View \[item_view\] field of List screen
    \[sys_sg_list_screen\] records.

    The script removes the value in the Data Item \[data_item\] field of Item View \[item_view\]
    records.

## More Resources {#sg-mobile-migration-ny__section_m2k_2dl_1jb}

For more information on the migration process, see the Mobile Migration Guide for New York on
the ServiceNow community site. [https://community.servicenow.com/community?id=community_article\&sys_id=f5121a33dba7f788fff8a345ca961957](https://community.servicenow.com/community?id=community_article&sys_id=f5121a33dba7f788fff8a345ca961957)
* **[Run the mobile migration script](https://servicenow-prod.fluidtopics.net/lVh~AzM8P25dCqrVDlhIfg)**   
  Run the mobile migration script to convert Madrid mobile applications you have created or modified to use the new mobile hierarchy.
* **[Resolve common issues in mobile migration script results](https://servicenow-prod.fluidtopics.net/K2eVoTMCxB8EO5p8sBF9lQ)**   
  Find solutions to common issues after running the mobile migration script.

*[\>]: and then