Migrated app architecture reference

This page describes what the Neptune DXP - Open Edition app produced by the Neptune DXP App Migration Wizard looks like structurally: how Neptune DXP - SAP Edition data maps to Neptune DXP - Open Edition conventions, what Neptune DXP - Open Edition-specific fields are set automatically, and how to locate migrated code in the App Designer.

You do not need to understand these internals to run a migration. This reference is useful when reviewing, troubleshooting, or extending a migrated app.

App identity

The application name is carried over from Neptune DXP - SAP Edition and lowercased to conform to Neptune DXP - Open Edition naming conventions. For example, ZTEST_MIGRATION_APP in Neptune DXP - SAP Edition becomes ztest_migration_app in Neptune DXP - Open Edition. This is the canonical app ID used in URLs and API calls.

Neptune DXP - Open Edition metadata defaults

Neptune DXP - Open Edition-specific fields that do not exist in Neptune DXP - SAP Edition are assigned defaults on first save. These defaults reflect current Neptune DXP - Open Edition best practices for new apps and are appropriate for the vast majority of migrated apps. They can be adjusted in the app settings in Neptune DXP - Open Edition if your deployment has specific requirements.

Neptune DXP - Open Edition field Migration default Purpose

compilerTarget

3

ES compilation target (modern)

useV2AppHandler

true

Modern Neptune DXP - Open Edition app handler

enableFileStorage

false

Enables server-side file storage for the app; disabled by default as Neptune DXP - SAP Edition apps do not use this feature

enableManifest

true (if manifest content present)

Enables the app-level manifest; set automatically if the source app includes manifest content

enableStylesheet

true (if CSS content present)

Enables the app-level stylesheet; set automatically if the source app includes CSS content

publicAccess

false

Controls whether the app is accessible without authentication; disabled by default to preserve authenticated access

roles

[]

Authorization roles — assign as needed post-migration

id, ver, status

Assigned by Neptune DXP - Open Edition on save

Managed by Neptune DXP - Open Edition runtime

Object tree structure

Root-level organization

Neptune DXP - SAP Edition uses two explicit top-level folder objects in its internal tree: HTML5 Document (containing the UI control tree) and Resources (containing scripts, HTML fragments, TypeScript files, and other resources). Neptune DXP - Open Edition does not use these folder nodes. The migration re-parents their contents to Neptune DXP - Open Edition’s standard root positions, which correspond to what you see as the top-level tree nodes in the Neptune DXP - Open Edition App Designer:

Neptune DXP - SAP Edition folder Maps to in Neptune DXP - Open Edition Contains

HTML5 Document

Main view root

All UI controls

Resources

Resources root

Scripts, TypeScript, HTML, events, models

The Neptune DXP - SAP Edition folder nodes themselves are not present in the migrated app.

Object identifiers

Neptune DXP - SAP Edition uses string-based object IDs in the format UI_N (for example, UI_1, UI_42). Neptune DXP - Open Edition uses numeric IDs internally. The migration converts all UI_N references to their numeric equivalent. This conversion is handled entirely by the engine. You will not encounter raw numeric IDs in normal use of the App Designer.

Control type resolution

In virtually all apps, control types resolve automatically. The Analyze step flags any controls where type resolution cannot be completed. This occurs only in very old Neptune DXP - SAP Edition apps where the UI5 class name was not stored in the database, and would result in an unrecognized control type in Neptune DXP - Open Edition. The Analyze report gives you a precise list for your specific app before migration is committed.

Scripts and event handlers

Neptune DXP - SAP Edition stores scripts in separate flat arrays keyed by object ID. Neptune DXP - Open Edition inlines all script content directly into each object’s script property. After migration, scripts are part of their parent object’s definition in the Neptune DXP - Open Edition tree, which is standard Neptune DXP - Open Edition convention.

Event scripts (Anonymous Function): Event handlers using Anonymous Function are fully migrated and behave identically in Neptune DXP - Open Edition. In the Neptune DXP - Open Edition App Designer, these appear as attributes with value "Anonymous Function" and the script body inlined, which is standard Neptune DXP - Open Edition convention. No further action is required.

Ajax ID migration output

The migration rewrites Ajax ID logic as TypeScript and places the generated files alongside a human- and machine-readable README in a dedicated location within the Resources tree:

Resources/
└── __GENERATED_MIGRATION_CODE__/
    ├── README                        ← migration summary: what was transformed, what requires review
    └── __AJAX_ID_MIGRATION__/
        └── (generated .ts files, one per Ajax ID group)

The README provides a structured summary of the full migration pipeline output for this app: which elements were transformed automatically, which were excluded or replaced with placeholders, and which require manual rework. Consult it before making changes to the migrated app.

The Ajax TypeScript files wrap the original Ajax ID calls as TypeScript functions routed through the Neptune DXP - Open Edition proxy to your SAP back end, with service paths and SAP system parameters preserved from the source app. In most cases, no changes are needed if the remote system is correctly configured. Changes are required if back-end paths, authentication parameters, or service structures differ between the Neptune DXP - SAP Edition and Neptune DXP - Open Edition environments.

Translations

Classic app i18n

Neptune DXP - SAP Edition uses SAP single-character language codes (for example, D for German, E for English). Neptune DXP - Open Edition uses uppercased BCP-47 locale strings (for example, DE, EN). All classic translation entries are converted and inlined into each attribute’s translation array in the migrated app.

SAP data dictionary field label translations

For apps that use DDIC-bound technical field bindings, for example, ~MATNR, which maps to "Material Number" in the SAP data dictionary, the migration can fetch human-readable label translations directly from the SAP system at migration time and carry them into the migrated app. This is architecturally distinct from classic i18n conversion: rather than converting existing app content, the wizard fetches additional content from the SAP dictionary during the migration run.

The languages fetched are selected in the Analyze step’s Advanced Options. Fetched translations are written into the migrated app as RefDataElements_* keys. For detail on configuring this, see Step 3 — Analyze in the wizard guide.

App-level stylesheet and manifest

If the Neptune DXP - SAP Edition app includes a stylesheet, its content is placed in the Neptune DXP - Open Edition app’s top-level css field. The manifest is placed in manifest. Both are standard Neptune DXP - Open Edition app properties, editable in the App Designer's app settings.

Post-migration work

Items that affect app functionality

Address these before considering the migration complete:

  • README and Analyze report: Consult the GENERATED_MIGRATION_CODE / README and the Analyze report as your primary reference. Together they give a complete, migration-specific picture of what requires action.

  • SAPUI5 control placeholders: Each placeholder is listed in the Analyze report with its original control type. Replace with Neptune DXP - Open Edition-compatible equivalents to restore the intended UI.

  • Cross-app dependencies: If the source app calls other Neptune DXP - SAP Edition apps via AppCache.Load or AppCache.Open, ensure those apps are also available in Neptune DXP - Open Edition. Runtime navigation to missing apps will fail.

  • Ajax ID migration code: Review the generated TypeScript under GENERATED_MIGRATION_CODE / AJAX_ID_MIGRATION. If backend paths or authentication parameters differ between your Neptune DXP - SAP Edition and Neptune DXP - Open Edition environments, update them here.

  • Data bindings and models: If the app uses Neptune DXP - Open Edition data bindings or OData models, re-configure these in Neptune DXP - Open Edition. The migrated app runs without them but any data-bound behavior will be incomplete until they are in place.

  • Header script: If the Neptune DXP - SAP Edition app used a header script, re-enter it in the app settings in Neptune DXP - Open Edition.

Recommended review

These items do not block the app from running but are good practice to complete:

  • Authorization roles: The migrated app’s roles field is empty by default. Assign the appropriate Neptune DXP - Open Edition roles for your deployment.

  • OData and REST connectivity: Even when bindings are recreated automatically, validate that the migrated app communicates correctly with your SAP back end end-to-end.

  • Translations: If you carried over multiple languages, spot-check that labels render correctly in the migrated app, including any DDIC-sourced field label translations.

  • App settings: Review the OE metadata defaults and adjust if your deployment has specific requirements.

Related topics