Migration from IBM InfoSphere Information Server to IBM Knowledge Catalog: Applying patches and toolkit to a new IBM Knowledge Catalog 4.8.x or 5.0.x or 5.1.x or 5.2.x installation (Part 2 of 2)

Preventive Service Planning

Abstract

This document lists the available patches for IBM Knowledge Catalog in Cloud Pak for Data 4.8.x or 5.0.x or 5.1.x or 5.2.x, and how to apply them for the migration when you are migrating data over from a InfoSphere Information Server 11.7.1.4 SP2 or later deployment.

This information is specific to fresh installations of IBM Knowledge Catalog in Cloud Pak for Data 4.8.x or 5.0.x or 5.1.x or 5.2.x

Content

For information on new features and functions for each release, see Watson Knowledge Catalog and InfoSphere Information Server migration to IBM Knowledge Catalog: What's new.

If you haven't started migration yet, make sure to download and install the latest migration toolkit.

Release date: 24 November 2025

Download the latest migration toolkit from Fix Central:

legacy-migration-patch_5.0.4183

After the toolkit is downloaded, refer back to the migration documentation and continue the steps outlined in the documentation:

Preparing for migration in IBM Cloud Pak for Data

Cloud Pak for Data 5.2.x

	Patch name	Migration toolkit
	Released on	24 November 2025
	Service assembly	wkc
	Applies to service version	IBM Knowledge Catalog 5.2.x
	Applies to platform version	Cloud Pak for Data 5.2.x
	Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.2.x
	Install instructions	Download patch legacy-migration-patch_5.0.4183. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry: skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:6bb3dd97329667dde965f35d749acb60000a3b6381174671081058575d9fc49d \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:6bb3dd97329667dde965f35d749acb60000a3b6381174671081058575d9fc49d skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:4111c2fc3dd67ec89a91011113cace25bee505c7ea58238ba7742abd620c748c \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:4111c2fc3dd67ec89a91011113cace25bee505c7ea58238ba7742abd620c748c skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:a0e54639f038c0e950fecfb84f08066543e2e739067c26900acbe6bcf4a308cb \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:a0e54639f038c0e950fecfb84f08066543e2e739067c26900acbe6bcf4a308cb skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.2.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.2.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:4111c2fc3dd67ec89a91011113cace25bee505c7ea58238ba7742abd620c748c","catalog_api_aux_image":"sha256:a0e54639f038c0e950fecfb84f08066543e2e739067c26900acbe6bcf4a308cb","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
	Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": { "catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{ "requests":{"cpu": "250m", "memory": "256Mi"}, "limits":{"cpu": "2", "memory": "3Gi"} }, "portal_job_manager_resources":{ "requests":{"cpu": "30m", "ephemeral-storage": "10Mi", "memory": "128Mi"}, "limits":{"cpu": "2", "ephemeral-storage": "8Gi", "memory": "8Gi"} } }}' Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${WKC_NAMESPACE}` Confirm that the patches are in place: Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi portal_job_manager_resources: limits: cpu: "2" ephemeral-storage: "8Gi" memory: "8Gi" requests: cpu: "30m" ephemeral-storage: "10Mi" memory: "128Mi" For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": { "catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{ "requests":{"cpu": "250m", "memory": "256Mi"}, "limits":{"cpu": "2", "memory": "3Gi"} }, "dap_base_asset_files_resources":{ "limits":{"cpu": "4", "memory": "12Gi"} }, "portal_job_manager_replicas": 1, "portal_job_manager_resources":{ "requests":{"cpu": "30m", "ephemeral-storage": "10Mi", "memory": "128Mi"}, "limits":{"cpu": "2", "ephemeral-storage": "12Gi", "memory": "8Gi"} } }}' Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${WKC_NAMESPACE}` Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral-storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral-storage": "2Gi"} } }}'` Wait for the WKC operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get wkc wkc-cr -n ${WKC_NAMESPACE}` Confirm that the patches are in place: Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi portal_job_manager_replicas: 1 portal_job_manager_resources: limits: cpu: "2" ephemeral-storage: "12Gi" memory: "8Gi" requests: cpu: "30m" ephemeral-storage: "10Mi" memory: "128Mi" Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral-storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral-storage: 50Mi memory: 512Mi`
	Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[ { "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" }, { "op": "remove", "path": "/spec/couchdb_search_resources" }, { "op": "remove", "path": "/spec/portal_job_manager_resources" } ]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[ { "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" }, { "op": "remove", "path": "/spec/couchdb_search_resources" }, { "op": "remove", "path": "/spec/dap_base_asset_files_resources" }, { "op": "remove", "path": "/spec/portal_job_manager_replicas" }, { "op": "remove", "path": "/spec/portal_job_manager_resources" } ]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running, and running with the original pod image.
	Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh_1_1.txt The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates three jobs to assets sync GS, relationships sync GS and Graph Lineage separately: `catalog-api-asset-sync-job`: for resync Global Search with Catalog assets `catalog-api-relationship-sync-job`: for resync Global Search with Catalog relationships `catalog-api-lineage-sync-job`: for resync Graph Lineage with Catalog Let the three jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pods -n $WKC_NAMESPACE \| grep catalog-api \| grep sync` or `oc logs -n $WKC_NAMESPACE catalog-api-asset-sync-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Release date: 24 November 2025

Download the latest migration toolkit from Fix Central:

legacy-migration-patch_5.0.4183

After the toolkit is downloaded, refer back to the migration documentation and continue the steps outlined in the documentation:

Preparing for migration in IBM Cloud Pak for Data

Cloud Pak for Data 5.1.x

Patch name	Migration toolkit
Released on	24 November 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 5.1.x
Applies to platform version	Cloud Pak for Data 5.1.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.1.x
Install instructions	Download patch legacy-migration-patch_5.0.4183. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry. skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:6bb3dd97329667dde965f35d749acb60000a3b6381174671081058575d9fc49d \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:6bb3dd97329667dde965f35d749acb60000a3b6381174671081058575d9fc49d skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac \ docker://<local private registry>/cp/cpd/catalog_master@sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/wkc-data-rules@sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db \ docker://<local private registry>/cp/cpd/wkc-data-rules@sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.1.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.1.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following commands: Apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a","catalog_api_image":"sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Apply the patch to the WKC custom resource (wkc-cr): `oc patch wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"wkc_data_rules_image":"sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db"}}}'` If the sum of the number of Data Quality projects on the source environment and the number of projects owned by the user running the import on the target IBM Knolwedge Catalog environment exceeds 200 projects, run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Wait for the WKC operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the wkc-data-rules pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": { "catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{ "requests":{"cpu": "250m", "memory": "256Mi"}, "limits":{"cpu": "2", "memory": "3Gi"} }, "portal_job_manager_resources":{ "requests":{"cpu": "30m", "ephemeral-storage": "10Mi", "memory": "128Mi"}, "limits":{"cpu": "2", "ephemeral-storage": "8Gi", "memory": "8Gi"} } }}' Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${WKC_NAMESPACE}` Confirm that the patches are in place: Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi portal_job_manager_resources: limits: cpu: "2" ephemeral-storage: "8Gi" memory: "8Gi" requests: cpu: "30m" ephemeral-storage: "10Mi" memory: "128Mi" For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": { "catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{ "requests":{"cpu": "250m", "memory": "256Mi"}, "limits":{"cpu": "2", "memory": "3Gi"} }, "dap_base_asset_files_resources":{ "limits":{"cpu": "4", "memory": "12Gi"} }, "portal_job_manager_replicas": 1, "portal_job_manager_resources":{ "requests":{"cpu": "30m", "ephemeral-storage": "10Mi", "memory": "128Mi"}, "limits":{"cpu": "2", "ephemeral-storage": "12Gi", "memory": "8Gi"} } }}' Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${WKC_NAMESPACE}` Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral-storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral-storage": "2Gi"} } }}'` Wait for the WKC operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get wkc wkc-cr -n ${WKC_NAMESPACE}` Confirm that the patches are in place: Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi portal_job_manager_replicas: 1 portal_job_manager_resources: limits: cpu: "2" ephemeral-storage: "12Gi" memory: "8Gi" requests: cpu: "30m" ephemeral-storage: "10Mi" memory: "128Mi" Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral-storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral-storage: 50Mi memory: 512Mi`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[ { "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" }, { "op": "remove", "path": "/spec/couchdb_search_resources" }, { "op": "remove", "path": "/spec/portal_job_manager_resources" } ]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[ { "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" }, { "op": "remove", "path": "/spec/couchdb_search_resources" }, { "op": "remove", "path": "/spec/dap_base_asset_files_resources" }, { "op": "remove", "path": "/spec/portal_job_manager_replicas" }, { "op": "remove", "path": "/spec/portal_job_manager_resources" } ]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running and running with the original pod image.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh_1.txt The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates three jobs to assets sync GS, relationships sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog assets `wkc-search-relationships-job`: for resync Global Search with Catalog relationships `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the three jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Release date: 24 November 2025

Download the latest migration toolkit from Fix Central:

legacy-migration-patch_5.0.4183

After the toolkit is downloaded, refer back to the migration documentation and continue the steps outlined in the documentation:

Preparing for migration in IBM Cloud Pak for Data

Cloud Pak for Data 5.0.x

Patch name	Migration toolkit
Released on	24 November 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 5.0.x
Applies to platform version	Cloud Pak for Data 5.0.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.0.x
Install instructions	Download patch legacy-migration-patch_5.0.4183. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry. skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:6bb3dd97329667dde965f35d749acb60000a3b6381174671081058575d9fc49d \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:6bb3dd97329667dde965f35d749acb60000a3b6381174671081058575d9fc49d skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a \ docker://<local private registry>/cp/cpd/catalog_master@sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007 \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.0.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.0.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007","catalog_api_image":"sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` If the sum of the number of Data Quality projects on the source environment and the number of projects owned by the user running the import on the target IBM Knolwedge Catalog environment exceeds 200 projects, run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: For Cloud Pak for Data 5.0.2 and later versions: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` For Cloud Pak for Data 5.0.0/5.0.1: `oc patch glossary glossary-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi For Cloud Pak for Data 5.0.2 and later versions: Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` `For Cloud Pak for Data 5.0.0 and 5.0.1:` Confirm that the glossary CR patch is applied by checking the output from the `oc get glossary glossary-cr -o yaml` results, under the spec section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: For Cloud Pak for Data 5.0.2 and later versions: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` For Cloud Pak for Data 5.0.0/5.0.1 `oc patch glossary glossary-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh_1.txt The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates three jobs to assets sync GS, relationships sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog assets `wkc-search-relationships-job`: for resync Global Search with Catalog relationships `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the three jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Release date: 24 November 2025

Download the latest migration toolkit from Fix Central:

legacy-migration-patch_5.0.4183

After the toolkit is downloaded, refer back to the migration documentation and continue the steps outlined in the documentation:

Preparing for migration in IBM Cloud Pak for Data

Cloud Pak for Data 4.8.x

Patch name	Migration toolkit
Released on	24 November 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 4.8.x
Applies to platform version	Cloud Pak for Data 4.8.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 4.8.x
Install instructions	Download patch legacy-migration-patch_5.0.4183. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry: skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:6bb3dd97329667dde965f35d749acb60000a3b6381174671081058575d9fc49d \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:6bb3dd97329667dde965f35d749acb60000a3b6381174671081058575d9fc49d skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810 \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc \ docker://<local private registry>/cp/cpd/catalog_master@sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 4.8.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 4.8.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810","catalog_api_aux_image":"sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f","catalog_api_image":"sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh_1.txt The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates three jobs to assets sync GS, relationships sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog assets `wkc-search-relationships-job`: for resync Global Search with Catalog relationships `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the three jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Known issues

Cloud Pak for Data Version 5.0.x

cpd-cli manage install-rsi failed hitting install-rsi not found
For information about this known issue, see here.

Earlier versions of the migration toolkit

Download the migration toolkit from Fix Central based on your Cloud Pak for Data version.

Cloud Pak for Data 5.2.x

Cloud Pak for Data 5.2.1
Release date: 17 September 2025
Cloud Pak for Data 5.2.0
Release date: 1 August 2025

Cloud Pak for Data 5.1.x

Cloud Pak for Data 5.1.3 version 4
Release date: 17 September 2025
Cloud Pak for Data 5.1.3 version 3
Release date: 1 August 2025
Cloud Pak for Data 5.1.3 version 2
Release date: 4 June 2025
Cloud Pak for Data 5.1.3
Release date: 23 May 2025
Cloud Pak for Data 5.1.2
Release date: 9 May 2025

Cloud Pak for Data 5.0.x

Cloud Pak for Data 5.0.4 version 6
Release date: 17 September 2025
Cloud Pak for Data 5.0.4 version 5
Release date: 1 August 2025
Cloud Pak for Data 5.0.4 version 4
Release date: 4 June 2025
Cloud Pak for Data 5.0.4 version 3
Release date: 23 May 2025
Cloud Pak for Data 5.0.4 version 2
Release date: 9 May 2025

Cloud Pak for Data 4.8.x

Cloud Pak for Data 4.8.9 version 6
Release date: 17 September 2025
Cloud Pak for Data 4.8.9 version 5
Release date: 1 August 2025
Cloud Pak for Data 4.8.9 version 4
Release date: 4 June 2025
Cloud Pak for Data 4.8.9 version 3
Release date: 9 May 2025
Cloud Pak for Data 4.8.9 version 2
Release date: 9 May 2025

Cloud Pak for Data 5.2.x

After the toolkit is downloaded, refer back to the migration documentation and continue the steps outlined in the documentation:

Cloud Pak for Data 5.2.1

	Patch name	Migration toolkit
	Released on	17 September 2025
	Service assembly	wkc
	Applies to service version	IBM Knowledge Catalog 4.8.x
	Applies to platform version	Cloud Pak for Data 4.8.x
	Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 4.8.x
	Install instructions	Download patch legacy-migration-patch_5.0.4167. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry: skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:02d84349d168967f01c100846c13fab6590fa75d5aed99aa46f4b8dd3a0861e3 \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:02d84349d168967f01c100846c13fab6590fa75d5aed99aa46f4b8dd3a0861e3 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:e5ad0fbd661840255ae617fc48ded7c76e396fa14aefffd6d9e7152323b8caed \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:e5ad0fbd661840255ae617fc48ded7c76e396fa14aefffd6d9e7152323b8caed skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:d72d76258d4cf172f6b44d714b8c736a63fa5f5b2682dd05cd394390a226905f \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:d72d76258d4cf172f6b44d714b8c736a63fa5f5b2682dd05cd394390a226905f skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/wkc-data-rules@sha256:2e68fb6c621fee91b0d9e1739b7962ceb1370b0e54af6d3e3ef92a89a65e9cd7 \ docker://<local private registry>/cp/cpd/wkc-data-rules@sha256:2e68fb6c621fee91b0d9e1739b7962ceb1370b0e54af6d3e3ef92a89a65e9cd7 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 4.8.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 4.8.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:e5ad0fbd661840255ae617fc48ded7c76e396fa14aefffd6d9e7152323b8caed","catalog_api_aux_image":"sha256:d72d76258d4cf172f6b44d714b8c736a63fa5f5b2682dd05cd394390a226905f","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Run the followng command to apply the patch to the WKC custom resource (wkc-cr): `oc patch wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"wkc_data_rules_image":"sha256:2e68fb6c621fee91b0d9e1739b7962ceb1370b0e54af6d3e3ef92a89a65e9cd7"}}}'` Run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Wait for the WKC operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the wkc-data-rules pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
	Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": { "catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{ "requests":{"cpu": "250m", "memory": "256Mi"}, "limits":{"cpu": "2", "memory": "3Gi"} }, "portal_job_manager_resources":{ "requests":{"cpu": "30m", "ephemeral-storage": "10Mi", "memory": "128Mi"}, "limits":{"cpu": "2", "ephemeral-storage": "8Gi", "memory": "8Gi"} } }}' Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${WKC_NAMESPACE}` Confirm that the patches are in place: Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi portal_job_manager_resources: limits: cpu: "2" ephemeral-storage: "8Gi" memory: "8Gi" requests: cpu: "30m" ephemeral-storage: "10Mi" memory: "128Mi" For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": { "catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{ "requests":{"cpu": "250m", "memory": "256Mi"}, "limits":{"cpu": "2", "memory": "3Gi"} }, "dap_base_asset_files_resources":{ "limits":{"cpu": "4", "memory": "12Gi"} }, "portal_job_manager_replicas": 1, "portal_job_manager_resources":{ "requests":{"cpu": "30m", "ephemeral-storage": "10Mi", "memory": "128Mi"}, "limits":{"cpu": "2", "ephemeral-storage": "12Gi", "memory": "8Gi"} } }}' Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${WKC_NAMESPACE}` Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral-storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral-storage": "2Gi"} } }}'` Wait for the WKC operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get wkc wkc-cr -n ${WKC_NAMESPACE}` Confirm that the patches are in place: Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi portal_job_manager_replicas: 1 portal_job_manager_resources: limits: cpu: "2" ephemeral-storage: "12Gi" memory: "8Gi" requests: cpu: "30m" ephemeral-storage: "10Mi" memory: "128Mi" Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral-storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral-storage: 50Mi memory: 512Mi`
	Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[ { "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" }, { "op": "remove", "path": "/spec/couchdb_search_resources" }, { "op": "remove", "path": "/spec/portal_job_manager_resources" } ]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[ { "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" }, { "op": "remove", "path": "/spec/couchdb_search_resources" }, { "op": "remove", "path": "/spec/dap_base_asset_files_resources" }, { "op": "remove", "path": "/spec/portal_job_manager_replicas" }, { "op": "remove", "path": "/spec/portal_job_manager_resources" } ]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running, and running with the original pod image.
	Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh_1.txt The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates three jobs to assets sync GS, relationships sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog assets `wkc-search-relationships-job`: for resync Global Search with Catalog relationships `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the three jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 5.2.0

	Patch name	Migration toolkit
	Released on	01 August 2025
	Service assembly	wkc
	Applies to service version	IBM Knowledge Catalog 4.8.x
	Applies to platform version	Cloud Pak for Data 4.8.x
	Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 4.8.x
	Install instructions	Download patch legacy-migration-patch_5.0.4161. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry: skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:4804b5ea8dd4d93ef6a68b3ee0e0a1fe7f155935968fd141aa4ceb4451a096c0 \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:4804b5ea8dd4d93ef6a68b3ee0e0a1fe7f155935968fd141aa4ceb4451a096c0 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810 \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc \ docker://<local private registry>/cp/cpd/catalog_master@sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 4.8.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 4.8.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810","catalog_api_aux_image":"sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f","catalog_api_image":"sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
	Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
	Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
	Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 5.1.x

After the toolkit is downloaded, refer back to the migration documentation and continue the steps outlined in the documentation:

Cloud Pak for Data 5.1.3 version 4

Patch name	Migration toolkit
Released on	17 September 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 5.1.x
Applies to platform version	Cloud Pak for Data 5.1.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.1.x
Install instructions	Download patch legacy-migration-patch_5.0.4167. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry. skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:02d84349d168967f01c100846c13fab6590fa75d5aed99aa46f4b8dd3a0861e3 \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:02d84349d168967f01c100846c13fab6590fa75d5aed99aa46f4b8dd3a0861e3 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac \ docker://<local private registry>/cp/cpd/catalog_master@sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/wkc-data-rules@sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db \ docker://<local private registry>/cp/cpd/wkc-data-rules@sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.1.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.1.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following commands: Apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a","catalog_api_image":"sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Apply the patch to the WKC custom resource (wkc-cr): `oc patch wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"wkc_data_rules_image":"sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db"}}}'` If the sum of the number of Data Quality projects on the source environment and the number of projects owned by the user running the import on the target IBM Knolwedge Catalog environment exceeds 200 projects, run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Wait for the WKC operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the wkc-data-rules pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": { "catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{ "requests":{"cpu": "250m", "memory": "256Mi"}, "limits":{"cpu": "2", "memory": "3Gi"} }, "portal_job_manager_resources":{ "requests":{"cpu": "30m", "ephemeral-storage": "10Mi", "memory": "128Mi"}, "limits":{"cpu": "2", "ephemeral-storage": "8Gi", "memory": "8Gi"} } }}' Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${WKC_NAMESPACE}` Confirm that the patches are in place: Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi portal_job_manager_resources: limits: cpu: "2" ephemeral-storage: "8Gi" memory: "8Gi" requests: cpu: "30m" ephemeral-storage: "10Mi" memory: "128Mi" For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": { "catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{ "requests":{"cpu": "250m", "memory": "256Mi"}, "limits":{"cpu": "2", "memory": "3Gi"} }, "dap_base_asset_files_resources":{ "limits":{"cpu": "4", "memory": "12Gi"} }, "portal_job_manager_replicas": 1, "portal_job_manager_resources":{ "requests":{"cpu": "30m", "ephemeral-storage": "10Mi", "memory": "128Mi"}, "limits":{"cpu": "2", "ephemeral-storage": "12Gi", "memory": "8Gi"} } }}' Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${WKC_NAMESPACE}` Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral-storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral-storage": "2Gi"} } }}'` Wait for the WKC operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get wkc wkc-cr -n ${WKC_NAMESPACE}` Confirm that the patches are in place: Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi portal_job_manager_replicas: 1 portal_job_manager_resources: limits: cpu: "2" ephemeral-storage: "12Gi" memory: "8Gi" requests: cpu: "30m" ephemeral-storage: "10Mi" memory: "128Mi" Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral-storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral-storage: 50Mi memory: 512Mi`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[ { "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" }, { "op": "remove", "path": "/spec/couchdb_search_resources" }, { "op": "remove", "path": "/spec/portal_job_manager_resources" } ]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[ { "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" }, { "op": "remove", "path": "/spec/couchdb_search_resources" }, { "op": "remove", "path": "/spec/dap_base_asset_files_resources" }, { "op": "remove", "path": "/spec/portal_job_manager_replicas" }, { "op": "remove", "path": "/spec/portal_job_manager_resources" } ]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running and running with the original pod image.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh_1.txt The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates three jobs to assets sync GS, relationships sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog assets `wkc-search-relationships-job`: for resync Global Search with Catalog relationships `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the three jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 5.1.3 version 3

Patch name	Migration toolkit
Released on	01 August 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 5.1.x
Applies to platform version	Cloud Pak for Data 5.1.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.1.x
Install instructions	Download patch legacy-migration-patch_5.0.4161. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry. skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:4804b5ea8dd4d93ef6a68b3ee0e0a1fe7f155935968fd141aa4ceb4451a096c0 \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:4804b5ea8dd4d93ef6a68b3ee0e0a1fe7f155935968fd141aa4ceb4451a096c0 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac \ docker://<local private registry>/cp/cpd/catalog_master@sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/wkc-data-rules@sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db \ docker://<local private registry>/cp/cpd/wkc-data-rules@sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.1.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.1.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following commands: Apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a","catalog_api_image":"sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Apply the patch to the WKC custom resource (wkc-cr): `oc patch wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"wkc_data_rules_image":"sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db"}}}'` If the sum of the number of Data Quality projects on the source environment and the number of projects owned by the user running the import on the target IBM Knolwedge Catalog environment exceeds 200 projects, run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Wait for the WKC operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the wkc-data-rules pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": { "catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{ "requests":{"cpu": "250m", "memory": "256Mi"}, "limits":{"cpu": "2", "memory": "3Gi"} }, "portal_job_manager_resources":{ "requests":{"cpu": "30m", "ephemeral-storage": "10Mi", "memory": "128Mi"}, "limits":{"cpu": "2", "ephemeral-storage": "8Gi", "memory": "8Gi"} } }}' Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${WKC_NAMESPACE}` Confirm that the patches are in place: Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi portal_job_manager_resources: limits: cpu: "2" ephemeral-storage: "8Gi" memory: "8Gi" requests: cpu: "30m" ephemeral-storage: "10Mi" memory: "128Mi" For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": { "catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{ "requests":{"cpu": "250m", "memory": "256Mi"}, "limits":{"cpu": "2", "memory": "3Gi"} }, "dap_base_asset_files_resources":{ "limits":{"cpu": "4", "memory": "12Gi"} }, "portal_job_manager_replicas": 1, "portal_job_manager_resources":{ "requests":{"cpu": "30m", "ephemeral-storage": "10Mi", "memory": "128Mi"}, "limits":{"cpu": "2", "ephemeral-storage": "12Gi", "memory": "8Gi"} } }}' Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${WKC_NAMESPACE}` Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral-storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral-storage": "2Gi"} } }}'` Wait for the WKC operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get wkc wkc-cr -n ${WKC_NAMESPACE}` Confirm that the patches are in place: Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true -Dfeature.enable_duplicates_in_bulk_create=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi portal_job_manager_replicas: 1 portal_job_manager_resources: limits: cpu: "2" ephemeral-storage: "12Gi" memory: "8Gi" requests: cpu: "30m" ephemeral-storage: "10Mi" memory: "128Mi" Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral-storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral-storage: 50Mi memory: 512Mi`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[ { "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" }, { "op": "remove", "path": "/spec/couchdb_search_resources" }, { "op": "remove", "path": "/spec/portal_job_manager_resources" } ]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[ { "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" }, { "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" }, { "op": "remove", "path": "/spec/couchdb_search_resources" }, { "op": "remove", "path": "/spec/dap_base_asset_files_resources" }, { "op": "remove", "path": "/spec/portal_job_manager_replicas" }, { "op": "remove", "path": "/spec/portal_job_manager_resources" } ]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running and running with the original pod image.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 5.1.3 version 2

Patch name	Migration toolkit
Released on	4 June 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 5.1.x
Applies to platform version	Cloud Pak for Data 5.1.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.1.x
Install instructions	Download patch legacy-migration-patch_5.0.4107. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry. skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:870bc812e971a0250132dde855b37bd43056654a9a7224cf33cf4dcd1c6139db \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:870bc812e971a0250132dde855b37bd43056654a9a7224cf33cf4dcd1c6139db skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac \ docker://<local private registry>/cp/cpd/catalog_master@sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/wkc-data-rules@sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db \ docker://<local private registry>/cp/cpd/wkc-data-rules@sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.1.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.1.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following commands: Apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a","catalog_api_image":"sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Apply the patch to the WKC custom resource (wkc-cr): `oc patch wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"wkc_data_rules_image":"sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db"}}}'` If the sum of the number of Data Quality projects on the source environment and the number of projects owned by the user running the import on the target IBM Knolwedge Catalog environment exceeds 200 projects, run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Wait for the WKC operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the wkc-data-rules pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Login to OpenShift cluster: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Login to OpenShift cluster: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running and running with the original pod image.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 5.1.3

Patch name	Migration toolkit
Released on	23 May 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 5.1.x
Applies to platform version	Cloud Pak for Data 5.1.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.1.x
Install instructions	Download patch legacy-migration-patch_5.0.4084. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry. skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:728b25634693be66b3b7846057a8dbe72c8b3b33f71b7f591c18d7f8fb5cade1 \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:728b25634693be66b3b7846057a8dbe72c8b3b33f71b7f591c18d7f8fb5cade1 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac \ docker://<local private registry>/cp/cpd/catalog_master@sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/wkc-data-rules@sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db \ docker://<local private registry>/cp/cpd/wkc-data-rules@sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.1.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.1.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following commands: Apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:aa0068aec14e37986620c982295c083df6fc6bbe95facba582ae3c6f769a8e3a","catalog_api_image":"sha256:369f66883e040accb73c3deae984ed479e90eed242051b7035723f0ba21b51ac","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Apply the patch to the WKC custom resource (wkc-cr): `oc patch wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"wkc_data_rules_image":"sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db"}}}'` If the sum of the number of Data Quality projects on the source environment and the number of projects owned by the user running the import on the target IBM Knolwedge Catalog environment exceeds 200 projects, run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Wait for the WKC operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the wkc-data-rules pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Login to OpenShift cluster: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Login to OpenShift cluster: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running and running with the original pod image.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 5.1.2

Patch name	Migration toolkit
Released on	9 May 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 5.1.x
Applies to platform version	Cloud Pak for Data 5.1.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.1.x
Install instructions	Download patch legacy-migration-patch_5.0.4070. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry. skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:6e91b90e109bae351a0ccb94f6d41bb9024e91b26b525e76f2faa2f6e382d0fb \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:6e91b90e109bae351a0ccb94f6d41bb9024e91b26b525e76f2faa2f6e382d0fb skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:98d6231e3b1933358835b85a1193a1ca3e938c8cb64a3d93c4d53a3518491b02 \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:98d6231e3b1933358835b85a1193a1ca3e938c8cb64a3d93c4d53a3518491b02 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:c5693dd44c95443130a0d9e54fe96b430df59f07eab1f3d9339e03fed6bc362c \ docker://<local private registry>/cp/cpd/catalog_master@sha256:c5693dd44c95443130a0d9e54fe96b430df59f07eab1f3d9339e03fed6bc362c skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/wkc-data-rules@sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db \ docker://<local private registry>/cp/cpd/wkc-data-rules@sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.1.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.1.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following commands: Apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:98d6231e3b1933358835b85a1193a1ca3e938c8cb64a3d93c4d53a3518491b02","catalog_api_image":"sha256:c5693dd44c95443130a0d9e54fe96b430df59f07eab1f3d9339e03fed6bc362c","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Apply the patch to the WKC custom resource (wkc-cr): `oc patch wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=merge -p '{"spec":{"image_digests":{"wkc_data_rules_image":"sha256:043b1d7862b86cacd2ddcf7b2a8a0843e669d81a0cbe23001402df3aff5149db"}}}'` If the sum of the number of Data Quality projects on the source environment and the number of projects owned by the user running the import on the target IBM Knolwedge Catalog environment exceeds 200 projects, run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Wait for the WKC operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get wkc wkc-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the wkc-data-rules pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Login to OpenShift cluster: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Login to OpenShift cluster: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running and running with the original pod image.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 5.0.x

After the toolkit is downloaded, refer back to the migration documentation and continue the steps outlined in the documentation:

Cloud Pak for Data 5.0.4 version 6

Patch name	Migration toolkit
Released on	17 September 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 5.0.x
Applies to platform version	Cloud Pak for Data 5.0.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.0.x
Install instructions	Download patch legacy-migration-patch_5.0.4167. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry. skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:02d84349d168967f01c100846c13fab6590fa75d5aed99aa46f4b8dd3a0861e3 \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:02d84349d168967f01c100846c13fab6590fa75d5aed99aa46f4b8dd3a0861e3 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a \ docker://<local private registry>/cp/cpd/catalog_master@sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007 \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.0.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.0.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007","catalog_api_image":"sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` If the sum of the number of Data Quality projects on the source environment and the number of projects owned by the user running the import on the target IBM Knolwedge Catalog environment exceeds 200 projects, run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: For Cloud Pak for Data 5.0.2 and later versions: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` For Cloud Pak for Data 5.0.0/5.0.1: `oc patch glossary glossary-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi For Cloud Pak for Data 5.0.2 and later versions: Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` `For Cloud Pak for Data 5.0.0 and 5.0.1:` Confirm that the glossary CR patch is applied by checking the output from the `oc get glossary glossary-cr -o yaml` results, under the spec section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: For Cloud Pak for Data 5.0.2 and later versions: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` For Cloud Pak for Data 5.0.0/5.0.1 `oc patch glossary glossary-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh_1.txt The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates three jobs to assets sync GS, relationships sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog assets `wkc-search-relationships-job`: for resync Global Search with Catalog relationships `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the three jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 5.0.4 version 5

Patch name	Migration toolkit
Released on	01 August 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 5.0.x
Applies to platform version	Cloud Pak for Data 5.0.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.0.x
Install instructions	Download patch legacy-migration-patch_5.0.4161. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry. skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:4804b5ea8dd4d93ef6a68b3ee0e0a1fe7f155935968fd141aa4ceb4451a096c0 \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:4804b5ea8dd4d93ef6a68b3ee0e0a1fe7f155935968fd141aa4ceb4451a096c0 skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/catalog_master@sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a \ docker://<local private registry>/cp/cpd/catalog_master@sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007 \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.0.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.0.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007","catalog_api_image":"sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` If the sum of the number of Data Quality projects on the source environment and the number of projects owned by the user running the import on the target IBM Knolwedge Catalog environment exceeds 200 projects, run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: For Cloud Pak for Data 5.0.2 and later versions: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` For Cloud Pak for Data 5.0.0/5.0.1: `oc patch glossary glossary-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi For Cloud Pak for Data 5.0.2 and later versions: Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` `For Cloud Pak for Data 5.0.0 and 5.0.1:` Confirm that the glossary CR patch is applied by checking the output from the `oc get glossary glossary-cr -o yaml` results, under the spec section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: For Cloud Pak for Data 5.0.2 and later versions: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` For Cloud Pak for Data 5.0.0/5.0.1 `oc patch glossary glossary-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 5.0.4 version 4

Patch name	Migration toolkit
Released on	4 June 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 5.0.x
Applies to platform version	Cloud Pak for Data 5.0.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.0.x
Install instructions	Download patch legacy-migration-patch_5.0.4107. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry. skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:870bc812e971a0250132dde855b37bd43056654a9a7224cf33cf4dcd1c6139db \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:870bc812e971a0250132dde855b37bd43056654a9a7224cf33cf4dcd1c6139db skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/catalog_master@sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a \ docker://<local private registry>/cp/cpd/catalog_master@sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007 \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.0.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.0.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007","catalog_api_image":"sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` If the sum of the number of Data Quality projects on the source environment and the number of projects owned by the user running the import on the target IBM Knolwedge Catalog environment exceeds 200 projects, run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: For Cloud Pak for Data 5.0.2 and later versions: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` For Cloud Pak for Data 5.0.0/5.0.1: `oc patch glossary glossary-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi For Cloud Pak for Data 5.0.2 and later versions: Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` `For Cloud Pak for Data 5.0.0 and 5.0.1:` Confirm that the glossary CR patch is applied by checking the output from the `oc get glossary glossary-cr -o yaml` results, under the spec section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: For Cloud Pak for Data 5.0.2 and later versions: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` For Cloud Pak for Data 5.0.0/5.0.1 `oc patch glossary glossary-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 5.0.4 version 3

Patch name	Migration toolkit
Released on	23 May 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 5.0.x
Applies to platform version	Cloud Pak for Data 5.0.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.0.x
Install instructions	Download patch legacy-migration-patch_5.0.4084. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry. skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:728b25634693be66b3b7846057a8dbe72c8b3b33f71b7f591c18d7f8fb5cade1 \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:728b25634693be66b3b7846057a8dbe72c8b3b33f71b7f591c18d7f8fb5cade1 skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/catalog_master@sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a \ docker://<local private registry>/cp/cpd/catalog_master@sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007 \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.0.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.0.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007","catalog_api_image":"sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` If the sum of the number of Data Quality projects on the source environment and the number of projects owned by the user running the import on the target IBM Knolwedge Catalog environment exceeds 200 projects, run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: For Cloud Pak for Data 5.0.2 and later versions: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` For Cloud Pak for Data 5.0.0/5.0.1: `oc patch glossary glossary-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi For Cloud Pak for Data 5.0.2 and later versions: Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` `For Cloud Pak for Data 5.0.0 and 5.0.1:` Confirm that the glossary CR patch is applied by checking the output from the `oc get glossary glossary-cr -o yaml` results, under the spec section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: For Cloud Pak for Data 5.0.2 and later versions: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` For Cloud Pak for Data 5.0.0/5.0.1 `oc patch glossary glossary-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 5.0.4 version 2

Patch name	Migration toolkit
Released on	9 May 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 5.0.x
Applies to platform version	Cloud Pak for Data 5.0.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 5.0.x
Install instructions	Download patch legacy-migration-patch_5.0.4070. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry. skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/legacy-migration@sha256:6e91b90e109bae351a0ccb94f6d41bb9024e91b26b525e76f2faa2f6e382d0fb \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:6e91b90e109bae351a0ccb94f6d41bb9024e91b26b525e76f2faa2f6e382d0fb skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/catalog_master@sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a \ docker://<local private registry>/cp/cpd/catalog_master@sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a skopeo copy --all --authfile "<folder path>/auth.json" --dest-tls-verify=false --src-tls-verify=false docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007 \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 5.0.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 5.0.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:08db1e715960979793eb238fab710dc03f775ca29c0c293243077f1458827007","catalog_api_image":"sha256:643ea6597dc026e51e45e8fcacc8da5d0e5925d11786b5cf9ca8faf89b15b09a","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` If the sum of the number of Data Quality projects on the source environment and the number of projects owned by the user running the import on the target IBM Knolwedge Catalog environment exceeds 200 projects, run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: For Cloud Pak for Data 5.0.2 and later versions: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` For Cloud Pak for Data 5.0.0/5.0.1: `oc patch glossary glossary-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi For Cloud Pak for Data 5.0.2 and later versions: Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` `For Cloud Pak for Data 5.0.0 and 5.0.1:` Confirm that the glossary CR patch is applied by checking the output from the `oc get glossary glossary-cr -o yaml` results, under the spec section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: For Cloud Pak for Data 5.0.2 and later versions: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` For Cloud Pak for Data 5.0.0/5.0.1 `oc patch glossary glossary-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 4.8.x

After the toolkit is downloaded, refer back to the migration documentation and continue the steps outlined in the documentation:

Cloud Pak for Data 4.8.9 version 6

Patch name	Migration toolkit
Released on	17 September 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 4.8.x
Applies to platform version	Cloud Pak for Data 4.8.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 4.8.x
Install instructions	Download patch legacy-migration-patch_5.0.4167. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry: skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:02d84349d168967f01c100846c13fab6590fa75d5aed99aa46f4b8dd3a0861e3 \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:02d84349d168967f01c100846c13fab6590fa75d5aed99aa46f4b8dd3a0861e3 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810 \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc \ docker://<local private registry>/cp/cpd/catalog_master@sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 4.8.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 4.8.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810","catalog_api_aux_image":"sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f","catalog_api_image":"sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh_1.txt The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates three jobs to assets sync GS, relationships sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog assets `wkc-search-relationships-job`: for resync Global Search with Catalog relationships `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the three jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 4.8.9 version 5

Patch name	Migration toolkit
Released on	01 August 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 4.8.x
Applies to platform version	Cloud Pak for Data 4.8.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 4.8.x
Install instructions	Download patch legacy-migration-patch_5.0.4161. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry: skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:4804b5ea8dd4d93ef6a68b3ee0e0a1fe7f155935968fd141aa4ceb4451a096c0 \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:4804b5ea8dd4d93ef6a68b3ee0e0a1fe7f155935968fd141aa4ceb4451a096c0 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810 \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc \ docker://<local private registry>/cp/cpd/catalog_master@sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 4.8.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 4.8.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810","catalog_api_aux_image":"sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f","catalog_api_image":"sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 4.8.9 version 4

Patch name	Migration toolkit
Released on	4 June 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 4.8.x
Applies to platform version	Cloud Pak for Data 4.8.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 4.8.x
Install instructions	Download patch legacy-migration-patch_5.0.4107. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry: skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:870bc812e971a0250132dde855b37bd43056654a9a7224cf33cf4dcd1c6139db \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:870bc812e971a0250132dde855b37bd43056654a9a7224cf33cf4dcd1c6139db skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810 \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc \ docker://<local private registry>/cp/cpd/catalog_master@sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 4.8.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 4.8.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:2774b8726972e786f6d8eab07608e3515ded00f6c108a12767934b056b06b810","catalog_api_aux_image":"sha256:b89154389861198a21d1eecba85bf0b635224e248ff81d2d8b8d39c86fe79a1f","catalog_api_image":"sha256:4d81767c76c05dd372d278c240bcf28e0c5f02497a8ed5cad59116c6f60daacc","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 4.8.9 version 3

Patch name	Migration toolkit
Released on	23 May 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 4.8.x
Applies to platform version	Cloud Pak for Data 4.8.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 4.8.x
Install instructions	Download patch legacy-migration-patch_5.0.4084. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry: skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:728b25634693be66b3b7846057a8dbe72c8b3b33f71b7f591c18d7f8fb5cade1 \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:728b25634693be66b3b7846057a8dbe72c8b3b33f71b7f591c18d7f8fb5cade1 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:3be5ff21209bca023b39747236ece9e696ec6d0e26ddf449cd5e749a2a5c9e79 \ docker://<local private registry>/cp/cpd/catalog_master@sha256:3be5ff21209bca023b39747236ece9e696ec6d0e26ddf449cd5e749a2a5c9e79 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:5851685a2e58c487060c338a73acea722cfa853b6e996f9f325b8216ff5ea81f \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:5851685a2e58c487060c338a73acea722cfa853b6e996f9f325b8216ff5ea81f skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 4.8.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 4.8.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:5851685a2e58c487060c338a73acea722cfa853b6e996f9f325b8216ff5ea81f","catalog_api_image":"sha256:3be5ff21209bca023b39747236ece9e696ec6d0e26ddf449cd5e749a2a5c9e79","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

Cloud Pak for Data 4.8.9 version 2

Patch name	Migration toolkit
Released on	9 May 2025
Service assembly	wkc
Applies to service version	IBM Knowledge Catalog 4.8.x
Applies to platform version	Cloud Pak for Data 4.8.x
Description	For migrating your data from InfoSphere Information Server 11.7.1.4 SP2 or later to IBM Knowledge Catalog 4.8.x
Install instructions	Download patch legacy-migration-patch_5.0.4070. Download the migration toolkit from the IBM entitled registry as follows. Download the migration toolkit images in an air-gapped environment The following steps are meant for applying the patches in an air-gapped environment. Log in to the OpenShift console as the cluster admin. Prepare the authentication credentials to access the IBM production repository. Use the same auth.json file used for CASE download and image mirroring. An example directory path: `${HOME}/.airgap/auth.json` You can also create an auth.json file that contains credentials to access icr.io and your local private registry. For example: `{ "auths": { "cp.icr.io":{"email":"unused","auth":"<base64 encoded id:apikey>"}, "<private registry hostname>":{"email":"unused","auth":"<base64 encoded id:password>"} } }` For more information about the auth.json file, see containers-auth.json - syntax for the registry authentication file. Install skopeo by running: `yum install skopeo` To confirm the path for the local private registry to copy the hotfix images to, run the following command: `oc describe pod <hotfix image pod> \| grep -i "image:"` Where <hotfix image pod> can be the pod name for any of the images which will be patched with this hotfix. For example: `oc describe pod catalog-api \| grep Image: Image: cp.icr.io/cp/cpd/catalog-api@sha256:03c88c69b986f24d39e4556731c0d171169d2bd91b0fb22f6367fd51c9020e64` To get the local private registry source details, run the following commands: `oc get imageContentSourcePolicy oc describe imageContentSourcePolicy [cloud-pak-for-data-mirror]` The local private registry mirror repository and path details should be in the output of the describe command: `- mirrors: - ${PRIVATE_REGISTRY_LOCATION}/cp/ source: cp.icr.io/cp/cpd` For more information about mirroring of images, see Configuring your cluster to pull Cloud Pak for Data images. Use the skopeo command to copy the patch images from the IBM production registry to the local private registry. Using the appropriate auth.json file, copy the patch images from the IBM production registry to the Openshift cluster registry: skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/legacy-migration@sha256:6e91b90e109bae351a0ccb94f6d41bb9024e91b26b525e76f2faa2f6e382d0fb \ docker://<local private registry>/cp/cpd/legacy-migration@sha256:6e91b90e109bae351a0ccb94f6d41bb9024e91b26b525e76f2faa2f6e382d0fb skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e \ docker://<local private registry>/cp/cpd/portal-job-manager@sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog_master@sha256:3be5ff21209bca023b39747236ece9e696ec6d0e26ddf449cd5e749a2a5c9e79 \ docker://<local private registry>/cp/cpd/catalog_master@sha256:3be5ff21209bca023b39747236ece9e696ec6d0e26ddf449cd5e749a2a5c9e79 skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/catalog-api-aux_master@sha256:5851685a2e58c487060c338a73acea722cfa853b6e996f9f325b8216ff5ea81f \ docker://<local private registry>/cp/cpd/catalog-api-aux_master@sha256:5851685a2e58c487060c338a73acea722cfa853b6e996f9f325b8216ff5ea81f skopeo copy --all --authfile "<folder path>/auth.json" \ --dest-tls-verify=false --src-tls-verify=false \ docker://cp.icr.io/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 \ docker://<local private registry>/cp/cpd/asset-files-api@sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609 To complete the installation, follow the steps in the next section. Install the migration toolkit The following steps are meant for applying the patches using the online IBM entitled registry or after downloading the images for an air-gapped environment. To install the migration toolkit on the 4.8.x cluster, proceed with the following steps: Log in to the OpenShift console as the cluster admin. Extract the .zip file you downloaded to the 4.8.x cluster. The content is extracted to a folder named legacy-migration-patch. Go to the legacy-migration-patch folder. To make the install script executable, run the following command: `chmod +x install-legacy-migration-config-spec.sh` To install the toolkit, run the following command: `./install-legacy-migration-config-spec.sh -u <ocp-username> -p <ocp-password> --url <ocp-url> -n ${PROJECT_CPD_INST_OPERANDS}` Apply patches required for migration If doing an air-gapped upgrade install, ensure that the legacy-migration image is downloaded to the local registry. Run the following command to apply the patch to the CCS custom resource (ccs-cr): `oc patch ccs ccs-cr -n wkc --type=merge -p '{"spec":{"image_digests":{"portal_job_manager_image":"sha256:07e08e8e3b837699b6e50551048ce30b0709386522692488a86398878b05430e","catalog_api_aux_image":"sha256:5851685a2e58c487060c338a73acea722cfa853b6e996f9f325b8216ff5ea81f","catalog_api_image":"sha256:3be5ff21209bca023b39747236ece9e696ec6d0e26ddf449cd5e749a2a5c9e79","asset_files_api_image":"sha256:98a8f58b8bfcebc742b52fea921d24ee8eafa45e81c1c5a9f12ea1b18b2f7609"}}}'` Run the following command to increase the limit (where <project_limit> is the new intended project limit): `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": <project_limit>}}'` For example, to increase the limit to 400 projects, run the following: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type merge --patch '{"spec":{"projects_created_per_user_limit": 400}}'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the catalog-api, portal-job-manager and asset-files pods in ${PROJECT_CPD_INST_OPERANDS} should be up and running. Restart the ngp-projects-api pods. Get the names of the ngp-projects-api pods: `oc get pods -n ${PROJECT_CPD_INST_OPERANDS} -o custom-columns=POD:.metadata.name \| grep ngp-projects-api` Then, for each of the ngp-projects-api pod names, run the following to restart the pod: `oc delete pod ngp-projects-api-xxxxxx`
Configuration changes	Apply configuration changes for Migration Before continuing with the migration process, you will need to tune your cluster based on the scaleconfig size. Run the following commands to save your current cluster CCS and WKC settings: `oc get ccs ccs-cr -o yaml > ccs.bak.yaml oc get wkc wkc-cr -o yaml > wkc.bak.yaml` For small-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"8Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch for scaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it does, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}}}}' Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 8Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi For medium-sized clusters Note: Ensure the cpd-cli is installed correctly and that $PATH has been set properly. Increase PJM resource limit through RSI patch from the previous section. Create a file named specpatch.json and copy the following content into the specpatch.json file. If $CPD_CLI_MANAGE_WORKSPACE is defined, save it under the $CPD_CLI_MANAGE_WORKSPACE/work/rsi directory, otherwise, save it under the cpd-cli-workspace/olm-utils-workspace/work/rsi/ directory: `[{"op":"replace","path":"/spec/containers/0/resources/limits/cpu","value":"2"},{"op":"replace","path":"/spec/containers/0/resources/limits/memory","value":"8Gi"},{"op":"replace","path":"/spec/containers/0/resources/limits/ephemeral-storage","value":"12Gi"}]` Enable the RSI patch: `cpd-cli manage login-to-ocp --server=${OCP_URL} -u kubeadmin -p ${PASSWORD} cpd-cli manage enable-rsi --cpd_instance_ns=${WKC_NAMESPACE} cpd-cli manage install-rsi --cpd_instance_ns=${WKC_NAMESPACE}` Run the patch: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} \ --patch_type=rsi_pod_spec \ --patch_name=pjm-scaling \ --description="This is spec patch forscaling PJM" \ --include_labels=app:portal-job-manager \ --state=active \ --spec_format=json \ --patch_spec=/tmp/work/rsi/specpatch.json` The above call may fail if the `olm-utils-play-v2` already exists before the call, which doesn't have the `/tmp/work/rsi/specpatch.json` file mounted. If it fails, you can stop the previous container by running: `podman stop olm-utils-play-v2` Then restart the process from step 1 again, to relogin and restart the `olm-utils-play-v2` container. Patch the CCS CR to temporarily turn off some features and increase the resource limit during migration: oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"catalog_api_jvm_args_extras": "-Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true -Dfeature.fetch_stale_data_from_couch_db=true", "catalog_api_properties_enable_activity_tracker_publishing": "false", "catalog_api_properties_enable_global_search_publishing": "false", "catalog_api_properties_enable_global_search_rabbitmq_publishing": "false", "catalog_api_properties_global_call_logs": "false", "couchdb_search_resources":{"requests":{"cpu": "250m", "memory": "256Mi"},"limits":{"cpu": "2", "memory": "3Gi"}},"dap_base_asset_files_resources":{"limits":{"cpu": "4", "memory": "12Gi"}}}}' Patch the WKC CR/Glossary CR to increase the resource limit for the glossary service: `oc patch wkc wkc-cr --type merge --patch '{"spec": { "bg_resources":{ "requests":{"cpu": "250m", "memory": "512Mi", "ephemeral_storage": "50Mi"}, "limits":{"cpu": "2", "memory": "4Gi", "ephemeral_storage": "2Gi"} } }}'` Confirm that the patches are in place: Run the following command to set the project: `oc project ${WKC_NAMESPACE}` Confirm that the RSI patch is installed by running: `cpd-cli manage get-rsi-patch-info --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=rsi-pjm-scaling` The following is an example of the output: `PATCH_NAME PATCH_ID PATCH_INJECTION_STATUS NAMESPACE POD_NAME READY POD_STATUS rsi-pjm-scaling 206 True wkc portal-job-manager-7f857765c9-qpqh9 1/1 Running` You can also double check the portal-job-manager pod (not deployment), and make sure new limits are set correctly: `oc describe pod portal-job-manager-xxxxxxxxx-xxxxx` Then, confirm that the following limitations are set: `Limits: cpu: 2 ephemeral-storage: 12Gi memory: 8Gi Requests: cpu: 30m ephemeral-storage: 10Mi memory: 128Mi` Confirm that the CCS CR patch is applied by checking the CCS-CR from the `oc get ccs ccs-cr -o yaml` results, under the `spec` section: catalog_api_jvm_args_extras: -Dfeature.disable_lineage_publishing=true -Dfeature.disable_rabbitmq_publishing=true catalog_api_properties_enable_activity_tracker_publishing: "false" catalog_api_properties_enable_global_search_publishing: "false" catalog_api_properties_enable_global_search_rabbitmq_publishing: "false" catalog_api_properties_global_call_logs: "false" couchdb_search_resources: limits: cpu: "2" memory: 3Gi requests: cpu: 250m memory: 256Mi dap_base_asset_files_resources: limits: cpu: "4" memory: 12Gi Confirm that the WKC CR patch is applied by checking the WKC-CR from the `oc get wkc wkc-cr -o yaml` results, under the `spec` section: `bg_resources: limits: cpu: "2" ephemeral_storage: 2Gi memory: 4Gi requests: cpu: 250m ephemeral_storage: 50Mi memory: 512Mi` Scale the PJM replicas down Scale the replicas down by first scaling down the portal-job-manager using: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=1` Put CCS into maintenance mode to prevent CCS reconcile: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": true}}'`
Reverting changes	Reverting configuration changes for Migration Note: After the migration or if migration fails, you will need to revert these cluster tuning changes back. Reverting changes for small-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Reverting changes for medium-scale clusters After the migration, you will need to run the following steps to rollback the changes done during the cluster tuning. Disable RSI for PJM: `cpd-cli manage create-rsi-patch --cpd_instance_ns=${WKC_NAMESPACE} --patch_name=pjm-scaling --state=inactive` Remove the CCS changes for resource limits and feature settings. Note: You need to double check whether any of the following parameters have been changed for the cluster before or not. If you need any specific settings afterwards, you will need to reset those to the desired values. oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type json -p '[{ "op": "remove", "path": "/spec/catalog_api_jvm_args_extras" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_activity_tracker_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_enable_global_search_rabbitmq_publishing" },{ "op": "remove", "path": "/spec/catalog_api_properties_global_call_logs" },{ "op": "remove", "path": "/spec/couchdb_search_resources" }]' Remove the glossary service resource limit changes: `oc patch wkc wkc-cr --type json -p '[{"op": "remove", "path": "/spec/bg_resources" }]'` Scale the PJM replicas back up by first scaling up the portal-job-manager by running: `oc scale -n ${WKC_NAMESPACE} deployment portal-job-manager --replicas=3` Disable CCS maintenance mode: `oc patch -n ${WKC_NAMESPACE} ccs ccs-cr --type merge --patch '{"spec": {"ignoreForMaintenance": false}}'` Reverting the migration toolkit support image changes Follow these steps to revert the migration toolkit support image patches: Run the following command to remove image updates from the Common Core Services (CCS) custom resource: `oc patch ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS} --type=json --patch '[{"op":"remove","path":"/spec/image_digests/catalog_api_aux_image"},{"op":"remove","path":"/spec/image_digests/catalog_api_image"},{"op":"remove","path":"/spec/image_digests/asset_files_api_image"},{"op":"remove","path":"/spec/image_digests/portal-job-manager_image"}]'` Wait for the CCS operator reconciliation to complete. Run the following command to monitor the reconciliation status: `oc get ccs ccs-cr -n ${PROJECT_CPD_INST_OPERANDS}` After a period of time, the portal-job-manager pod, catalog-api pod and asset-files pod in ${PROJECT_CPD_INST_OPERANDS} should be up and running.
Re-sync processes	Re-sync processes After migrating all data over from an InfoSphere Information Server, you need to run through the following two steps to re-sync the processes to ensure imported assets are synced within Watson Knowledge Catalog (WKC). Some re-sync jobs might take time to complete based on how many assets need to be re-synced during migration. To re-sync Global Search (GS) and Graph Lineage, download and run the following shell script: cpd_gs_graph_resync.sh The script asks for the namespace where WKC is installed. The script asks for the catalogs to sync. You can specify the catalog(s) where they import migration assets in, or press enter to select all catalogs to re-sync. The script creates two jobs to sync GS and Graph Lineage separately: `wkc-search-reindexing-job`: for resync Global Search with Catalog `wkc-search-lineage-job`: for resync Graph Lineage with Catalog Let the two jobs run. The re-sync will be done after the related job pods run to Completed state. You can check the re-sync progress by checking the related pod status or the log by running: `oc get pod -n $WKC_NAMESPACE \|grep wkc-search` or `oc logs -n $WKC_NAMESPACE wkc-search-reindexing-job-xxxxx --tail 10` To re-sync Activities Lineage, follow the instructions outlined in this support page: How to re-synchronise and patch events in Activity Lineage post running migration

[{"Type":"MASTER","Line of Business":{"code":"LOB76","label":"Data Platform"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCLA7","label":"IBM Knowledge Catalog"},"ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Tips

Migration from IBM InfoSphere Information Server to IBM Knowledge Catalog: Applying patches and toolkit to a new IBM Knowledge Catalog 4.8.x or 5.0.x or 5.1.x or 5.2.x installation (Part 2 of 2)

Preventive Service Planning

Abstract

Content

Was this topic helpful?

Document Information

UID

Share your feedback

Need support?