Upgrades & Migration

Upgrading the operator

The operator is upgraded the same way it was installed:

Helm

helm upgrade navique-ai-core-operator \
  oci://ghcr.io/scigility/charts/navique-ai-core-operator \
  --namespace navique-system

kustomize

make deploy IMG=ghcr.io/scigility/navique-ai-core-operator:<new-tag>

OLM

# Managed by the Operator Lifecycle Manager's upgrade channel.

On startup the new operator reconciles all existing resources. Capability-operator releases it owns are upgraded to the versions bundled with the new operator build; adopted releases are left untouched. Because every apply is idempotent and the reconcile model is readiness-gated, an upgrade is non-destructive — workloads keep running while the operator converges.

Always review the release notes for CRD schema changes. Applying updated CRDs (make install or the Helm/OLM upgrade) is additive within v1alpha1.

Changing a resource's mode or type

Datastore resources support changing mode (managed ↔ adopt ↔ external) and type. When you do, the operator performs a migration garbage-collection: it diffs old vs new status and removes only the now-orphaned operator-owned resources, then releases any capability operator no longer needed. Adopted and external resources are never touched. See Provenance & Lifecycle.

For example, switching a PostgresCluster from managed to external:

1. The operator wires the supplied external connectionSecretRef.
2. It deletes the CNPG Cluster it had created.
3. If no other consumer needs CloudNativePG, it uninstalls the operator (only because the operator owns it).

Data migration is your responsibility

Switching a datastore's mode changes where data lives, not the data itself. The operator does not copy data between a managed cluster and an external host — migrate the data (dump/restore, replication) before or after the switch as appropriate.

Migrating from the Helm + ArgoCD deployment

The operator replaces the platform's previous Helm + ArgoCD delivery. The migration path:

1. Stand up the operator alongside the existing deployment.
2. Adopt, don't fight. Point datastore resources at the existing in-cluster datastores with mode: adopt, or at external hosts with mode: external, so the operator does not try to re-create what already runs. Adopt any capability operators you already installed — the operator detects and coexists with them.
3. Rotate the previously-committed secrets. The old charts committed live secrets to git; rotate them in your vault and source them via SecretsManagement. See Secrets Management.
4. Cut over workloads by creating Gateway, Observability, and ChatUI resources that reference the adopted datastores.
5. Decommission ArgoCD for the platform once the operator owns the workloads.

Because the operator is provenance-aware, you can migrate incrementally without it clobbering resources you still manage by hand.

Bundled chart versions

Each operator build pins specific upstream chart versions (see Bundled Charts). Upgrading the operator is how you move to newer bundled charts for the releases the operator owns. Version bumps are driven upstream by Renovate/Dependabot watching the source chart repositories.