System Upgrade Principles

When working with Appway/FNZ Studio Platform, upgrading to newer versions is part of the ongoing development workflow. This articles describes:

  • The scope of the different release types and their frequency
  • General information on the different kinds of upgrades you can perform
  • Best practices related to upgrading

Release Types

FNZ Studio 2023 and higher

There are two different types of FNZ Studio releases:

  • LTS (Long-Term Support) Release

    • Examples: FNZ Studio 2023 LTS (full name: 2023.5.1 - this is due to align numbering to internal (FNZ only) releases occurring over the year).

    • Scope: Mainly new features, may include changes and bugfixes.

    • The LTS release occurs once a year, and is accompanied by an Upgrade Guide that documents the upgrade procedure. You should always upgrade to the latest patch of the LTS release (e.g., from FNZ Studio 2022.2.x to FNZ Studio 2023 LTS).

      An overview of the exact lifecycle phase dates for all Platform versions is available in Product Lifecycle and End of Support.

  • Patch Release

    • Examples: Numbering convention still to be determined

    • Scope: Mainly bugfixes and security fixes

    • Patch releases are provided for all supported Platform versions. The release frequency depends on demand, when needed.

      You can see all released versions of the Platform in the Products page.

Appway 2022.1 and FNZ Studio 2022.2

Starting from 2022, Appway Platform versions are being renamed. Moreover, starting from version 2022.2, the Appway Platform has been renamed FNZ Studio (also referred to, generically, as Platform in this article).

There are two different types of Appway releases:

  • Feature Release

    • Examples: Appway 2022.1 (full name: 2022.1.1), FNZ Studio 2022.2 (full name: 2022.2.1)

    • Scope: Mainly new features, may include changes and bugfixes

    • Feature releases occur at least twice a year, and are accompanied by an Upgrade Guide that documents the upgrade procedure.

      An overview of the exact lifecycle phase dates for all Platform versions is available in Product Lifecycle and End of Support.

  • Patch Release

    • Examples: Appway 2022.1.1 (first patch release of feature release 2022.1), Appway 2022.1.2, FNZ Studio 2022.1.3, Appway 2022.2.1 (first patch release of feature release 2022.2), FNZ Studio 2022.2.2

    • Scope: Mainly bugfixes and security fixes

    • Patch releases are provided for all supported Platform versions. The release frequency depends on demand, when needed.

Appway 11 and lower

There are three different types of Appway releases:

  • Major Release

    • Examples: Appway 11 (full name: Appway 11.0.0), Appway 10 (full name: Appway 10.0.0), Appway 9 (full name: Appway 9.0.0)

    • Scope: Mainly new major features (also disruptive and significant features), may include changes and bugfixes.

    • Major releases occur once a year, and are accompanied by a Beta program and an Upgrade Guide that documents the upgrade procedure.

      An overview of the exact lifecycle phase dates for all Appway versions is available in Appway Releases – Product Lifecycle and End of Support.

  • Minor Release

    • Examples: Appway 11.1 (full name: 11.1.0)
    • Scope: Consolidation of major features, minor features and improvements, may contain bugfixes.
    • Minor releases are provided only for the latest major release of Appway. In general, an annual Appway Major release will be followed by one or two Minor releases.

  • Patch Release

    • Examples: Appway 11.0.0 (first patch release of Major Appway 11), Appway 11.0.1, Appway 11.1.0 (first patch release of Minor Appway 11.1)

    • Scope: Mainly bugfixes and security fixes

    • Patch releases are provided for all supported Appway versions. The release frequency depends on demand, when needed.

Upgrading Appway/FNZ Studio

Upgrading Appway is fully backward compatible, meaning that Solutions developed with older Appway/FNZ Studio versions will continue to run after upgrading.

FNZ Studio 2023 and higher

Upgrading to a New Patch Release

Details to be determined.

Upgrading to an LTS (Long-Term Support) Release

Upgrading to an LTS (Long-Term Support) release provides access to new functionality to enhance your Solutions.

After upgrading, new functionality enhancing operations, stability, and quality (like new Health Sensors) is available for use immediately and your existing Solutions continue to run. Adoption of new development features happens gradually, as you enhance existing Solutions or build new Solutions.

Examples: Upgrade from FNZ Studio 2022.2 to FNZ Studio 2023 LTS

Note: If your scenario implies upgrading across several feature versions, e.g. from Appway 2022.1 to FNZ Studio 2023 LTS, you need to perform the upgrade in steps to ensure the success of the upgrade. To stay with this example, that means upgrading from Appway 2022.1 to FNZ Studio 2022.2, and then from FNZ Studio 2022.2 to 2023 LTS.

When upgrading to a new Feature release, follow the steps outlined in the relevant System Upgrade guidevto ensure the correct transformation of the model. The Upgrade Guide typically covers three upgrade phases:

  1. Pre-upgrade – Steps to perform on your current system before upgrading, like checking for and replacing functionality that was removed in the version you are upgrading to (see the following section).
  2. Upgrade – Tasks like upgrading the WAR file for FNZ Studio Core and the JAR files for extensions. On first startup, the model is automatically transformed to comply with the version of FNZ Studio you are upgrading to.
  3. Post-upgrade – Steps to perform on the upgraded system, such as clean up tasks and addressing changes in default functionality.

Feature Deprecation and Removal

Deprecation, and the subsequent removal of features, helps ensure that Solutions built with our Platform are using up-to-date technology and principles, according to contemporary development strategies.

When upgrading to a new Platform release, see the related 'Removal and Deprecation' article for information on features that are deprecated or removed in the release. This article is updated continuously and it is your point of reference for all deprecation, migration, and removal information:

  • Removed features – Issues related to the removal of features must be addressed before upgrading if there is any impact on your Solution. The removal of features is also announced in the Release Notes.
  • Deprecated features – Issues related to the deprecation of features do not require immediate action before upgrading but we recommend that you start considering the recommended actions illustrated in our documentation. Deprecation is a continuous process, and each deprecated feature is also announced in the Release Notes. Deprecated features will continue to work as normal and only be removed a minimum of 2 years since the date of the release that deprecates the item (therefore, in 2026 for features deprecated in Appway 2023 LTS - released on November 2023). This time frame gives you time to address the necessary changes.

Appway 2022.1 and FNZ Studio 2022.2

Starting from 2022, Appway Platform versions are being renamed. Moreover, starting from version 2022.2, the Appway Platform has been renamed FNZ Studio (also referred to, generically, as Platform in this article).

Upgrading to a New Patch Release

Upgrading to a newer Patch release ensures you have all the latest bugfixes and changes available. Upgrades of this type are seamless, generally requiring no manual migration steps while upgrading.

Example: Patch upgrade from FNZ Studio 2022.2.1 to 2022.2.5

Upgrading to a new Patch release consists of the following steps:

  1. Upgrade the WAR file for FNZ Studio Core and the JAR files for extensions.

  2. On first startup, the model is automatically transformed to comply with the version of FNZ Studio you are upgrading to.

    Note: Specific upgrade steps (if applicable) are documented in the respective Release Notes and in the respective System Upgrade document.

Upgrading to a Feature Release

Upgrading to a newer Feature release provides access to new functionality to enhance your Solutions.

After upgrading, new functionality enhancing operations, stability, and quality (like new Health Sensors) is available for use immediately and your existing Solutions continue to run. Adoption of new development features happens gradually, as you enhance existing Solutions or build new Solutions.

Examples: Upgrade from FNZ Studio 2022.1 to 2022.2

Note: If your scenario implies upgrading across several feature versions, e.g. from Appway 11 to FNZ Studio 2022.2, you need to perform the upgrade in steps to ensure the success of the upgrade. To stay with this example, that means upgrading from Appway 11 to FNZ Studio 2022.1, and then from FNZ Studio 2022.1 to 2022.2.

When upgrading to a new Feature release, follow the steps outlined in the relevant System Upgrade guide to ensure the correct transformation of the model. The Upgrade Guide typically covers three upgrade phases:

  1. Pre-upgrade – Steps to perform on your current system before upgrading, like checking for and replacing functionality that was removed in the version you are upgrading to (see the following section).
  2. Upgrade – Tasks like upgrading the WAR file for FNZ Studio Core and the JAR files for extensions. On first startup, the model is automatically transformed to comply with the version of FNZ Studio you are upgrading to.
  3. Post-upgrade – Steps to perform on the upgraded system, such as clean up tasks and addressing changes in default functionality.

Feature Deprecation and Removal

Deprecation, and the subsequent removal of features, helps ensure that Solutions built with our Platform are using up-to-date technology and principles, according to contemporary development strategies.

When upgrading to a new Platform release, see the related 'Removal and Deprecation' article for information on features that are deprecated or removed in the release. This article is updated continuously and it is your point of reference for all deprecation, migration, and removal information:

  • Removed features – Issues related to the removal of features must be addressed before upgrading if there is any impact on your Solution. The removal of features is also announced in the Release Notes.
  • Deprecated features – Issues related to the deprecation of features do not require immediate action before upgrading but we recommend that you start considering the recommended actions illustrated in our documentation. Deprecation is a continuous process, and each deprecated feature is also announced in the Release Notes. Deprecated features will continue to work as normal and only be removed a minimum of 2 years since the date of the release that deprecates the item (therefore, after October 2024 for features deprecated in Appway 2022.2 - released on September 2022). This time frame gives you time to address the necessary changes.

Appway 11 and lower

There are two different scenarios when upgrading Appway, illustrated in detail below.

Upgrading to a New Patch or Minor Release

Upgrading to a newer Patch or Minor release ensures you have all the latest bugfixes and changes available. In addition, Minor releases may include new functionality. Upgrades of this type are seamless, generally requiring no manual migration steps while upgrading.

Example: Patch upgrade from 11.1.0 to 11.1.1, Minor upgrade from 11.0 to 11.1

Upgrading to a new Patch or Minor release consists of the following steps:

  1. Upgrade the WAR file for Appway Core and the JAR files for extensions.

  2. On first startup, the model is automatically transformed to comply with the version of Appway you are upgrading to.

    Note: Specific upgrade steps (if applicable) are documented in the respective Release Notes and in the respective System Upgrade document.

Upgrading to a New Major Release

Upgrading to a newer Major release provides access to new functionality to enhance your Solutions.

After upgrading, new functionality enhancing operations, stability, and quality (like new Health Sensors) is available for use immediately and your existing Solutions continue to run. Adoption of new development features happens gradually, as you enhance existing Solutions or build new Solutions.

Examples: Upgrade from 10.1 to 11.1, or from 9.1 to 10.1

Note: If your scenario implies upgrading across several major versions, e.g. from Appway 9.1 to 11.1, you need to perform the upgrade in steps to ensure the success of the upgrade. To stay with this example, that means upgrading from Appway 9.1 to 10.1, and then from 10.1 to 11.1.

When upgrading to a new Major release, follow the steps outlined in the relevant System Upgrade guide to ensure the correct transformation of the model. The Upgrade Guide typically covers three upgrade phases:

  1. Pre-upgrade – Steps to perform on your current system before upgrading, like checking for and replacing functionality that was removed in the version you are upgrading to (see the following section).
  2. Upgrade – Tasks like upgrading the WAR file for Appway Core and the JAR files for extensions. On first startup, the model is automatically transformed to comply with the version of Appway you are upgrading to.
  3. Post-upgrade – Steps to perform on the upgraded system, such as clean up tasks and addressing changes in default functionality.

Feature Deprecation and Removal

Deprecation, and the subsequent removal of features, helps ensure that Solutions built with Appway are using up-to-date technology and principles, according to contemporary development strategies.

When upgrading to a new Appway release, see the related 'Removal and Deprecation' article for information on features that are deprecated or removed in the release. This article is updated continuously and it is your point of reference for all deprecation, migration, and removal information:

  • Removed features – Issues related to the removal of features must be addressed before upgrading if there is any impact on your Solution. The removal of features is also announced in the Release Notes.
  • Deprecated features – Issues related to the deprecation of features do not require immediate action before upgrading but we recommend that you start considering the recommended actions illustrated in our documentation. Deprecation in Appway is a continuous process, and each deprecated feature is also announced in the Release Notes. Deprecated features will continue to work as normal and only be removed a minimum of 3 major releases later: this time frame gives you time to address the necessary changes.

Ensuring a Smooth Upgrade: Best Practices

The below sections summarize some best practices which will help you be prepared for upgrading Appway to new versions.

Model Transformation – Prerequisites

To ensure model transformation works seamlessly, do not step outside of the Appway model when building a Solution. The parts of Solutions built outside of the model are at risk of breaking during upgrade, as they are not part of the automatic transformation of the model. It is not possible to statically analyze the impact of these parts of the Solution at design time. Design practices to avoid are:

  • Using other technologies such as Java, CSS, or JavaScript within Appway.
  • Dynamically injecting script calls, as Appway cannot automatically transform functions that are renamed in such cases. Example: If NEW is renamed to NewObject, Appway transforms NEW(Party) to NewObject(Party). But, if you are using EVAL('NEW(Party)'), transformation by Appway fails.

Rolling Back an Upgrade

To be prepared for a scenario where you need to roll back an upgrade, follow these steps:

  1. Before the upgrade takes place, take a full backup of your solution – this means the model, the platform, and the data.

  2. Once you have upgraded to a newer version, test the new release thoroughly on your testing environment before rolling out to a production environment.

  3. If you experience issues while testing, you can roll back by restoring the full backup created in step 1 on a platform running the previously used version of Appway.

    Note: If you encounter issues only at a later point when you are already on a production environment, open a ticket with FNZ Studio support before rolling back.
    Important notes
    • Appway downgrade not supported. Reversing the upgrade process described in chapter 2 to "downgrade" to a lower version of Appway is not supported. While it is possible to roll back to the previous version of WAR/JAR files, rolling back the automatic transformation of the model is not supported. This means it is not possible to "downgrade" patch or major/feature releases (e.g. from 11.1.3 to 11.1.1, or from 11.0 to 10.1). A platform running a different version of Appway to that of the model is not able to interpret the transformed model. For example, Appway 6.3 is not able to deserialize the Business Objects, or interpret the Business Rules transformed for use on Appway 7.
    • Package backward compatibility not supported. Appway does not support Package backward compatibility. Therefore, exporting Packages e.g. from Appway 11 and importing them to a lower minor or major/feature Appway version (e.g. Appway 10) is not supported.