Migrating projects to support new features - Precisely Data Integrity Suite

Prerequisites

Before beginning the migration, update discli to the latest version. If discli is already up to date, the command confirms that no update is needed.

./discli updateCli

Ensure that the dynamic-runtime-manager service is running on your agent.

Run the following command:

./discli agent status | grep 'dynamic-runtime-manager'

If the service is not running, make sure that you are on the latest operator version and follow the operator update instructions.

Obtain the operator pod name before updating the dynamic-runtime-manager certificates. Use the command for your installation.

Agents installed in June 2026 or later

/usr/local/bin/k3s kubectl get pods | grep operator

Agents installed between February and June 2026

/usr/local/bin/k3s kubectl get pods -n precisely-agent-operator-ns

Agents installed before February 2026

sudo KUBECONFIG=/home/k3s/.kube/k3s.yaml /usr/local/bin/k3s kubectl get pods -n precisely-agent-operator-ns

After ensuring the operator is on the latest version, run the command for your installation to update the dynamic-runtime-manager certificates. Replace <operator_pod> with the operator pod name.

Agents installed in June 2026 or later

/usr/local/bin/k3s kubectl exec -it <operator_pod> -- sh -c '/home/scripts/ensure_dynamic_runtime_manager_certs.sh'

Agents installed between February and June 2026

/usr/local/bin/k3s kubectl exec -it -n precisely-agent-operator-ns <operator_pod> -- sh -c '/home/scripts/ensure_dynamic_runtime_manager_certs.sh'

Agents installed before February 2026

sudo KUBECONFIG=/home/k3s/.kube/k3s.yaml /usr/local/bin/k3s kubectl exec -it -n precisely-agent-operator-ns <operator_pod> -- sh -c '/home/scripts/ensure_dynamic_runtime_manager_certs.sh'

Reset resources requests for tuned services (if applicable)

If you have previously applied resource tuning to the connect-cdc or cloud-applier pods, reset the Kubernetes requests values to their defaults before migrating projects so that migrated projects can reserve the required resources.

For connect-cdc

Edit the StatefulSet using the appropriate command for your installation.

Agents installed in June 2026 or later

/usr/local/bin/k3s kubectl edit statefulset connect-cdc

Agents installed between February and June 2026

/usr/local/bin/k3s kubectl edit statefulset -n precisely-connect-cdc-ns connect-cdc

Agents installed before February 2026

sudo KUBECONFIG=/home/k3s/.kube/k3s.yaml /usr/local/bin/k3s kubectl edit statefulset -n precisely-connect-cdc-ns connect-cdc

In the resources settings, change only the requests values back to their defaults.

requests:
    cpu: 50m
    memory: 500Mi

Do not modify any custom limits values.

For cloud-applier

Edit the StatefulSet using the appropriate command for your installation.

Agents installed in June 2026 or later

 /usr/local/bin/k3s kubectl edit statefulset connect-cloud-applier

Agents installed between February and June 2026

/usr/local/bin/k3s kubectl edit statefulset -n precisely-cloud-applier-ns connect-cloud-applier

Agents installed before February 2026

sudo KUBECONFIG=/home/k3s/.kube/k3s.yaml /usr/local/bin/k3s kubectl edit statefulset -n precisely-cloud-applier-ns connect-cloud-applier

In the resources settings, change only the requests values back to their defaults.

requests:
    cpu: 100m
    memory: 2Mi

Do not modify any custom limits values.

Service updates

Before proceeding with project migration:

• Upgrade connect-cdc and connect-hub to the latest supported versions by following Update agent.

If your environment includes BigQuery targets, configure the BigQuery region before proceeding (see Setting BigQuery region below).

Project migration procedure

Perform the following steps for each project labeled for migration:

1. Log in to your workspace.
2. Open the target project.
3. Stop LogReaders (if applicable):
   • Select all pipelines.
   • Open the options menu (⋮) and select Stop All LogReaders.
   • Confirm the action.
4. Allow pipeline backlogs to drain completely.
5. Stop pipelines:
   • For cloud targets (for example, BigQuery or Snowflake): Wait an additional duration equivalent to the pipeline batch interval before stopping pipelines.
   • For non-cloud targets: Stop pipelines immediately.
6. Verify backlog clearance (cloud targets only):
   • Follow the backlog verification procedure.
7. Stop all pipelines:
   • With all pipelines selected, choose Stop.
   • Confirm the action when prompted.
8. Stop the project.
9. Initiate migration:
   • Select Migrate at the top of the project page.
   • Select Apply to begin migration.

Verifying Cloud Applier Kafka backlog

To ensure that all data has been processed before migration, verify the Kafka backlog for Cloud Applier pipelines.

1. Download the cloud_applier_backlog.sh script from the download package to your agent VM.
2. Make the script executable:

   chmod +x cloud_applier_backlog.sh

3. Run the script:

   ./cloud_applier_backlog.sh

The script outputs a ranked summary of Kafka consumer lag, sorted by highest backlog.

Filtering results

To check a specific project:

./cloud_applier_backlog.sh | grep <project_name>

• If the project does not appear, there is no backlog.

Configure the BigQuery dataset region

If your environment uses BigQuery targets, configure the BigQuery dataset region before migrating projects. For instructions, see Configure BigQuery region.