Skip to main content





Traditional to Reactive App migration reference

  • Edit
    Collaborate with us
    Edit this page on GitHub
  • We've been working on these documents. Please let us know how useful this new version is by voting.

    This reference document is a collection of notes about the differences between Traditional and Reactive App. The purpose is to help developers in migrating an existing Traditional app to a Reactive runtime.

    Initial planning and preparation

    These are the considerations relevant in the preparatory steps of the Traditional Web App migration.

    • URLs should be working for new Screens, Resources, Images. If you use hardcoded URLs, you need to update them on your new Screens.
    • Migrate Entities while preserving the data
    • Handling Site Properties
    • Migrating Roles
    • Impact of Timers and Processes

    Once you start migrating your app to the Reactive Web App, consider following this order for each Module:

    1. Theme
    2. UI Flows
    3. External sites
    4. Web Screens
    5. Web Blocks, starting by the Web Blocks with no dependencies.

    Customize or redirect the application URL

    To manage the site and page rules in your Reactive Web Apps see Technical Preview - SEO in Reactive Web Apps.


    There are several accelerators that can help you migrate your app faster.

    Elements you can copy and paste

    You can copy the following elements from your Traditional App to Reactive App directly:

    • Aggregates without dependencies from other Aggregates and logic. Paste Aggregates to a Screen to create a Screen Aggregate.
    • Database content
    • Entities
    • Processes
    • Timers
    • Roles
    • Server Actions
    • Site Properties
    • Structures

    Additionally, you can paste a Server Action to a Screen Client Action, but never paste server Actions containing sensitive information that you could expose. For more information about security in Reactive Web Apps, see the Reactive Web security best practices.