Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...


App

...

Considerations

In order to migrate a Joget app from one server to another, we will need to assess the current footprint of the app to determine the best way to migrate.

  1. App Form Data
  2. Shared App Form Data
  3. App Process Data
  4. Plugins
  5. Integration with External SystemsUser Management

App Form Data

This section is applicable to you if you intend to migrate the form data stored in the server, otherwise, you can move on to the next section.

...

Due to the complexity and structure of the data of the workflow engine (shk* tables), as of now, we do not recommend migrating process data out in parts.

This is because data of process instances are stored in set of tables shared by all other apps in the same Joget server. Process data contains not just instances from the latest version of the app that we are migrating out, it may also contain all the process instance data of the same app but from earlier versions. Migrating the data out in parts may affect the normal functionality of the workflow engine.

We would recommend to leave the process instances' data behind. For process instances that are still in transit, here's the approach that we recommend.

...

This way, end users should be able to seamlessly continue with their process flow.

Having explained about the complexity of migrating workflow engine data out, there is an alternative.

In the case of you find in important to preserve the audit trail of the part / completed process data, you can enable Process Data Collector at the app level. Process related data of the app would be written into set of tables (app_report_* tables) that can be easily digested for analytical use. However, this plugin would only work on new process data as they are being executed after it is enabled, and not retrospectively on past data.

Plugins

This section is applicable to you if your app is making use plugins, otherwise, you can move on to the next section.

...

For each of them, do check for permission in the external systems to see if you need to whitelist / permit your new server in order to continue to function normally. If the new server is located in environment that is significantly different with current server (i.e geographically far away), it would be good to test its network / throughput to ensure that the app in the new server would be able to function within expected response times and not get bogged down by slow external integrations.

Platform Considerations

Joget Server Version

When we are migrating the app out from one to another, it is good to maintain the exact same version from the original server and the one you are migrating to. This is so that we do not introduce too much of moving variables, in case the app we migrated to, fails to function as expected.

Bear in mind that if you intend to upgrade your Joget platform, do it first at the environment where the staging server is, or upgrade the staging server where the said apps have been confirmed working before by following the Upgrade Guide. This way, the only change made is to upgrade the Joget platform version. It would be easier to find out cause of any problems as there are not many variables changed.

User Management

Typically, we will continue to server the same set of users in the new server as we scale out.

...