23.2 Exporting and Importing Applications

Export and import APEX apps as portable snapshots.

Exporting an app extracts its definitions from the database into files. You can do this in two ways: through the APEX web interface or with the Oracle SQL Command Line (SQLcl) utility. In App Builder, open the application you want to export and choose Export/Import > Export from the application actions menu. APEX then generates a SQL script for you. You can export it as a single file or as a ZIP archive containing separate component files (by enabling Split Export). The UI prompts you to download the result. This quick, interactive method is ideal for one-off backups or GUI-based migrations.

SQLcl is Oracle’s modern command-line tool for working with the database, with built-in commands for APEX. It’s ideal for automating or scripting exports. Make sure SQLcl and Java are installed, then connect to the database using your workspace's parsing schema. Run a command such as:

sql> apex export -applicationid 12345

This exports the application with ID 12345 into the current directory, creating one file named f12345.sql by default.

In practice, include a few options for best results. The most useful is -split, which creates an organized folder of component files. Other handy options include -skipExportDate, which omits timestamps to avoid false diffs in source control, and -expOriginalIds, which preserves internal IDs across environments for easier comparison and refresh. If your app uses Supporting Objects, add -expSupportingObjects to export those as well.

SQLcl also allows specifying the format of export using -expType. The default is APPLICATION_SOURCE (the normal SQL scripts), but you can also request APEXLANG for a more readable and editable representation, or EMBEDDED_CODE to extract all SQL, PL/SQL, and JavaScript code separately. You can combine formats. For example, to export both the standard SQL and APEXlang version in one go, use a command line this all on a single line with a space between options:

sql> apex export -applicationid 12345 
                 -split 
                 -skipExportDate
                 -expOriginalIds 
                 -expSupportingObjects Y
                 -expType APPLICATION_SOURCE,APEXLANG

This command exports app 12345, splits it into component files, skips timestamps, preserves IDs, includes supporting object scripts, and produces both SQL and APEXlang formats. After it runs, you’ll have a directory appalias/ containing the APEXlang .apx files as well as a f12345/ directory with the SQL Format artifacts. Together, these files represent your application in text form.

Importing an application is the reverse: it loads a previously exported file or set of files into an APEX instance, creating or replacing the app in a workspace. You can import it in two ways: through the APEX web interface or with the Oracle SQL Command Line (SQLcl) utility.

In App Builder, open the target workspace and use the Import function. Upload the export file (.sql or .zip), and APEX guides you through the steps. You may be asked to assign a new application ID or confirm the workspace. For example, if you exported app 100 from development and want to import it into test without overwriting another app, assign a new ID during import. APEX then recreates all pages, components, and shared logic defined in the file. If the app already exists, APEX installs a new copy or updates the existing one, depending on your choices.

You can also import a SQL format application export from the command line by running the SQL export script. Before doing so, set the context with APEX APIs if you need to target a different workspace or change the application ID. Use the APEX_APPLICATION_INSTALL package for this. For example, first run the PL/SQL block below:

begin
   apex_application_install.set_workspace('MyWorkspace');
   apex_application_install.set_application_id(56789);
end;

Then run f12345.sql or f12345/install.sql to import the app with new id 56789 in that workspace. To have APEX install any Supporting Objects automatically, add a call to set_auto_install_sup_obj(true) to the setup block above.

Tip:

See Using SQLcl with APEXlang for details on importing an app in APEXlang format.

If you import into the same APEX instance but a different workspace you must use a different application ID, since IDs are unique within an instance. For example, you might do this when moving an app from dev to test on the same server. The APEX_APPLICATION_INSTALL API can generate a new ID and adjust the application alias and parsing schema for you. When moving to a separate APEX instance you can usually keep the same ID and alias if there’s no conflict. This could happen when moving from on-premises development to a cloud environment. In either case, the import process faithfully rebuilds the application from the export. Afterward, run the app in its new environment to verify it works and complete any post-install steps, such as setting environment-specific settings or running data scripts.

Tip:

Exporting and importing covers only the APEX application definition. Any supporting database objects must be migrated separately, typically with SQL scripts or schema migration tools. Examples include tables, views, and PL/SQL packages. This section focuses on the application artifact itself. Managing database schema changes is a separate but essential part of the lifecycle. The SQLcl Projects feature can simplify this work by coordinating application exports with related database objects. For more information, see Database Application CI/CD in Oracle SQLcl User’s Guide.