Introduction

The old stable/cert-manager chart is deprecated, and supported installations now come from Jetstack. The migration is not just a repo rename: you need to preserve your existing cert-manager resources, install the maintained chart correctly, and verify that certificate reconciliation still works afterward.

Inventory the Current Installation

Start by checking what is already in the cluster:

helm list -A | grep cert-manager
kubectl get pods -n cert-manager
kubectl get issuer,clusterissuer,certificate -A

This tells you:

• which Helm release exists
• which namespace the controller uses
• which issuer and certificate resources already depend on cert-manager

That inventory matters because the real goal is to move the controller installation, not to lose the certificate state your cluster already uses.

Back Up the Important Resources

Before changing Helm repos or uninstalling anything, export the cert-manager resources:

kubectl get issuer,clusterissuer,certificate -A -o yaml > cert-manager-resources.yaml
kubectl get secret -A -o yaml > cert-manager-secrets.yaml

This gives you a recovery path if the controller installation changes and something fails to reconcile afterward.

The secret backup is intentionally broad. In production, you may narrow it to only the namespaces and certificate secrets you actually care about, but the key idea is the same: do not migrate blind.

Add the Supported Chart Repository

Installations should come from Jetstack's chart repository:

helm repo add jetstack https://charts.jetstack.io
helm repo update

Once that is in place, stop using the old stable chart source. The supported chart name is jetstack/cert-manager.

Reinstall from the Jetstack Chart

The standard installation shape is:

1helm upgrade --install cert-manager jetstack/cert-manager \
2  --namespace cert-manager \
3  --create-namespace \
4  --set crds.enabled=true

This installs the maintained cert-manager chart into the cert-manager namespace. After the install or upgrade, confirm that the main components are running:

kubectl get pods -n cert-manager
kubectl describe deployment -n cert-manager cert-manager

You typically expect the controller, webhook, and cainjector to come up cleanly.

Be Careful with CRDs

cert-manager relies on CRDs such as Certificate and Issuer. That means a careless uninstall can be far more damaging than a normal app chart removal if it removes APIs that live resources still depend on.

The safe mental model is:

• replace the chart source and controller installation
• preserve the custom resources and let the new controller continue reconciling them

If you treat CRDs as disposable during the migration, you risk breaking the certificate resources you were trying to preserve.

Validate the Migration Operationally

A successful Helm command is not enough. After the new installation is up, check whether cert-manager is still handling your existing resources:

kubectl get certificate -A
kubectl describe certificate -A
kubectl get challenge,order -A

You want to see that the controller recognizes the existing issuers and certificates and continues normal issuance or renewal behavior.

That is the real success condition. The migration is only complete when certificate management still works.

Common Pitfalls

• Treating the move from stable/cert-manager to jetstack/cert-manager as only a chart URL change.
• Uninstalling first without exporting Certificate, Issuer, and ClusterIssuer resources.
• Ignoring CRD handling and accidentally removing APIs that the live resources depend on.
• Checking only the Helm release status and not the certificate reconciliation status.
• Mixing assumptions from a very old installation with the current Jetstack chart commands without inspecting the live cluster first.

Summary

• Migrate from the deprecated stable/cert-manager chart to the supported jetstack/cert-manager chart.
• Back up cert-manager resources and related secrets before changing the installation.
• Install from the Jetstack repo and confirm the controller components start cleanly.
• Preserve CRDs and existing certificate resources during the migration.
• Validate success by checking real certificate and issuer behavior, not just Helm output.