App Considerations

If you are looking into migrating all the apps, please look at Backup, Restore and Disaster Recovery.

In order to migrate a single 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 Systems

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.

...

However, it is important to note that although there's ability to export form data in Export App feature, the intent of this feature is to export/import setup data, not production data. If the resultant export package size file size is too big, importing it later on will result in error / request time out issues.

Shared 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.

...

1. How are we making use of the shared tables? As a lookup or we write into them too?
2. Can we continue to provide access from the original server?
3. At which layer should the access be created? Joget app server or DB server level?
4. If DB level, we can consider making use of JDBC related plugins(i.e. JDBC Options Binder / JDBC Form Binder / JDBC Datalist Binder).
5. If Joget app level, we can consider making use of JSON API or provision new ones using API Builder where we can exert more controls in API management.

App Process Data

This section is applicable to you if your app is making use of processes (Process Builder), otherwise, you can move on to the next section.

...

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.

Referring to Figure 1 above, plugins that are used by the app can be exported alongside with the app itself. You should check if the new / target server has the same plugins but of different versions and check for its compatibilty.

Integration with External Systems

This section is applicable to you if your app is making external calls / relying on external systems, 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.

...

Otherwise, you may need to duplicate the existing user directory date (tables with prefix of dir_ in the database) to the new server.

Migration of Process Instances

Before We Begin

Before attempting anything, always perform a backup in any (app or database) servers that you will be working on. This is so that there's always something to fallback on, just in case!

...

1. The target server has the same app, same process(es), and have been tested to be working end to end (with all integrations, and plugins fitted in). This is so that discrepency in app/process design can be ruled out in case of any problem arised later on.
2. The target server has the same user management, so that the same user assigned, in current server, can be found in target server. This is so that problem that may arise when assigning an user can be ruled out.

Performing the Migration

Copy Form Data

Migrate non-process data over first by copying them over. Remember to copy and not to move, so that the original server remains fully functional and intact.

1. Make a list of process instances that are still running.
2. Copy these data over to the target server.
   1. Form Data from the database
   2. File Upload from wflow/app_formuploads
3. Now that form data and its uploaded files are available in the target server, we can migrate process instances over to the target server.

Migrate Process Instances

Then, perform the follow steps, starting with just 1 process instance.

...