1. Documentation
2. 2025.0 (Latest) 2024.1 2024.0 10.3 10.2 10.1 10.0 9.10 9.9 9.8 9.7 9.6 9.5 9.4 9.3 9.2 9.1 9.0 8.2 8.1 8.0 7.6
3. Deployment
4. Manage
5. Upgrade

Upgrade

Upgrades can be daunting, especially in production deployments, and we are committed to providing a smooth experience even in these scenarios.

That being said, there are multiple distinct upgrade and migration scenarios depending on multiple factors.

On this page, we will explain the upgrade and migration paths that we support, and we will provide step-by-step instructions to carry out a successful upgrade or migration.

Supported upgrade and migration paths

First, let's establish the different flavors of deployments that exist:

• Standalone RapidMiner Server: installed manually, not containerized (any version up to 9.7)
• RapidMiner Platform: containerized (any version between 9.4 and 9.6)
• RapidMiner Platform with centralized identity: containerized (version 9.7)

We support upgrading to the latest version of Standalone RapidMiner Server, and migrating to the latest version of the RapidMiner Platform with centralized identity (both from an older version of Standalone RapidMiner Server and from an older version of RapidMiner Platform).

To upgrade from one version of Standalone RapidMiner Server to the latest version, follow the Server upgrade guide.

To migrate to the latest version of RapidMiner Platform with centralized identity, follow our migration guide below.

Migrating to the latest version of RapidMiner Platform with centralized identity

Depending on the source version and deployment flavor you are migrating from, you will need to follow slightly different steps. Choose the right chapter for your deployment below.

Migrating from Standalone RapidMiner Server

1. Download a deployment template for the latest version
2. The RapidMiner Server home folder: you will use your existing home folder in the RapidMiner Platform deployment. To do this, you'll need to change the docker volume definition in your docker-compose.yml to a bind mount pointing to your home folder on the host machine's disk.
3. Make sure that the RapidMiner Server home folder is accessible on the host machine by the user with the UID 1000. To do this, run chown -R 1000:1000 ./your-rmserver-home-folder. This command will work even if no such user exists on your system. This is needed so the user inside our docker containers can access the folder contents properly.
4. The RapidMiner Server database: you can choose one of three options:
   1. Dump the contents of the old SQL database and load it into the new one which will run as a docker container. This will only work if you are using a PostgreSQL database.
   2. Create a bind mount pointing to your database's storage on disk. This will only work if you are using a PostgreSQL database.
   3. If you plan to keep your existing database backend (either because you want to administer it separately from the Platform, or it's not a PostgreSQL database), edit your .env file to contain the address and credentials of this database. You need to modify these variables: SERVER_DBHOST, SERVER_DBSCHEMA, SERVER_DBUSER, SERVER_DBPASS.
5. On the host machine, initialize the deployment stack by running docker-compose up -d rm-init-svc
6. You can check when the initialization procedure finishes by running docker-compose logs rm-init-svc. When you see a message stating that initialization completed successfully, hit Ctrl-C to get back to your terminal.
7. Start the stack by running docker-compose up -d
8. After everything has booted up, you will be able to log in on the address specified in step 5. At first only the default admin user can be authenticated, user migration needs to be done separately.

To complete the migration, two more manual steps are needed.

1. If needed, perform a database schema migration in RapidMiner Server. You will get prompted to do this when logging in to the Platform and navigating to RapidMiner Server for the first time.
2. Recreate users which existed in the old installation. We are working on a migration script to automate this, but for now it has to be done manually. If available, we also encourage configuring identity federation.

Migrating from an older version of RapidMiner Platform

1. Back up your Python environments from the Platform Admin tool.
2. Back up your old docker-compose.yml and .env files (.env was only introduced in version 9.6).
3. Download a deployment template for the latest version
4. Modify the template with your favorite text editor based on your old definition files. These are the things you should migrate:
   1. environment variable values (note: before version 9.6, the variable values were stored in the docker-compose.yml file, and have since been moved to the .env file)
   2. any extra container definitions and their configuration (such as additional Job Agent containers)

      Make sure you migrate all the previously generated and stored secrets and passwords (all variables with SECRET, USER or PASSWORD in their names) from your old .env file, otherwise you won’t be able to log in after upgrade.

5. Add the public DNS name (or IP address if you don't have a DNS entry configured) for the deployment to the PUBLIC_URL and SSO_PUBLIC_URL variables in your .env file.
6. If you haven't done so already, overwrite docker-compose.yml and .env on the host machine where the old deployment is running.
7. On the host machine, initialize the deployment stack by running docker-compose up -d rm-init-svc
8. You can check when the initialization procedure finishes by running docker-compose logs rm-init-svc. When you see a message stating that initialization completed successfully, hit Ctrl-C to get back to your terminal.
9. Start the stack by running docker-compose up -d
10. After everything has booted up, you will be able to log in on the address specified in step 5. At first only the default admin user can be authenticated, user migration needs to be done separately.

To complete the migration, two more manual steps are needed.

1. Recreate the backed up Python environments using Platform Admin.
2. If needed, perform a database schema migration in RapidMiner Server. You will get prompted to do this when logging in to the Platform and navigating to RapidMiner Server for the first time.
3. Recreate users which existed in the old installation. We are working on a migration script to automate this, but for now it has to be done manually. If available, we also encourage configuring identity federation.

Enabling legacy HTTP basic authentication on Server REST endpoints

By introducing the KeyCloak component to implement Identity and Security in the RapidMiner Platform, we increased our security level available on our REST endpoints.

When migrating from an existing version of the RapidMiner Platform, or a Standalone RapidMiner Server, existing web services might already be embedded in client applications where a change is not possible, or not desired.

In these cases it's possible to re-enable the HTTP Basic authentication that was previously available on these REST endpoints.

To enable it, you have to set the environment variable LEGACY_REST_BASIC_AUTH_ENABLED to true in your platform deployment. This variable is stored in the .env file. You can do this either using Docker Deployment Manager, or by manually editing the file and then issuing docker-compose up -d to apply the changes.