Use cases

Upgrade Community Hub Team Plan to KNIME Business Hub: Enables the migration of your assets into a dedicated, larger-scale KNIME Business Hub instance. It helps you migrate content from a Community Hub team to a Business Hub instance.

Experimental to Permanent Installation: Transfers the content developed during a proof of concept phase into a new KNIME Business Hub instance.

Consolidate multiple Business Hubs into one: Transfers content from one Business Hub to another.

In this guide the Hub you are migrating from is referred as the source Hub and the instance where the content is migrated as the destination Hub.

The solution to the previously described use cases is implemented as a KNIME Workflow/Data App designed specifically for Hub-to-Hub migrations.

The migration workflow:

  • Recreates teams and spaces: Reproducing organizational structures and collaborative environments.

  • Migrates content: Copying over all assets, including files, workflows, components, and data files without any modification.

  • Preserves versions history: Conserving item histories, ensuring continuity.

  • Migrates deployments and execution contexts: Setting back deployments and execution on the new Hub instance.

Prerequisites

Networking

It is crucial that the source and destination Hub instances can communicate over the network. Specifically, the executor running the migration workflow must have direct network access to the destination Hub instance to successfully complete the migration. For more information on this topic, please refer to the Limitations section below.

Permissions

Source Hub Instance:

  • You do not need global admin privileges to execute the workflow. However, you will only be able to migrate content to which you have explicit access.

Destination Hub Instance:

  • Certain operations (e.g., creating teams) require global admin permissions. Therefore, it is mandatory to connect using an account with global admin credentials.

Setup

Execute the workflow preferably as a data app on the source Hub or locally on the Analytic Platform. Running the workflow directly on the Hub simplifies the connection process, as authentication credentials (Application Passwords) for the source Hub instance are handled automatically. The Application Password and Hub URL for the destination instance must always be provided manually. Once you have selected the teams for migration and established a successful connection to the destination instance, everything is ready to proceed with the migration.

Upon execution, the workflow prompts the user to select a specific team from the source Hub (see Fig 1).

team selection connection
Figure 1. Team selection and connection to destination Hub

Since the deployments need to be assigned to an execution context to be recreated, you will be given three possibilites:

  • Skip Deployment Creation: Deployments will not be recreated during migration.

  • Deploy to a Single Execution Context: Assigns all deployments to an existing (global) execution context on the destination Hub, provided that one is already available.

  • Recreate Execution Contexts: Recreates each execution context referencing the original Docker image. Note that this method may have limitations if the Docker images are not available on the Hub where content is migrated.

At the end of the migration process, users can download a comprehensive log file (Excel format) detailing all migrated items and highlighting any errors encountered during the migration.

Limitations

The Hub-to-Hub migration workflow simplifies the process of moving content to a new KNIME Business Hub instance. However, certain scenarios and tasks are not currently covered by this workflow:

  • User Migration: User accounts cannot be migrated. This workflow neither recreates user accounts nor reassigns them to their previous teams. User migration requires a separate process.

  • Workflows will be transferred unmodified: When workflow includes linked resources, such as files stored relative to its location, those must also be accessible for the users on the new Hub.

    • Reader or writer nodes (e.g., Excel Reader, CSV Writer)

    • Nodes that call other workflows (e.g., Call Workflow Service)

  • API Errors: Some workflows or data files may exceed size limits, potentially causing timeout errors during upload or download via the API. To address such issues, open the configuration dialog of the relevant REST node within the workflow and increase the timeout value.

  • Linked Components: When linked components are migrated, the link may break. This is unfortanately not avoidable. Please reach out to your (technical) account manager on a guide on how to migrate such workflows via support@knime.com.

  • Credentials and Secrets: Due to their sensitive nature, credentials and secrets cannot be migrated. They must be manually reconfigured on the destination Hub and within the workflows.

  • Execution Context recreation: If an execution context references a Docker image that has not been built and pushed to the registry, the execution context will be available, but the executor will not start. Only official KNIME Docker images are readily available in the registry. All custom images must be rebuilt and pushed to the registry associated with the new Hub instance.

  • Hub Reachability and Network Constraints: Network connectivity between the two Hub instances might be disrupted due to:

    • Proxy settings

    • Instances residing on different networks or behind VPNs

    • Firewall restrictions

    • DNS resolution issues

    • SSL/TLS configuration problems

If you encounter connectivity issues, we recommend running the Executor Diagnostics Workflow on the same executor. Use the Proxy Perspective to verify whether the destination Hub URL is reachable.