Back up everything (this is your rollback)

Before changing anything, snapshot the current world: your ScaledObjects, your TriggerAuthentications, and the Secrets those auths point at. DevZero's KEDA reads the very same TriggerAuthentications and Secrets after cutover, so we preserve them exactly. We also record current replica counts so you can confirm parity at the end. Everything is written into the keda-migration/ folder.

kubectl get scaledobjects.keda.sh -A -o yaml                 > backup-scaledobjects.yaml
kubectl get triggerauthentications.keda.sh,clustertriggerauthentications.keda.sh -A -o yaml \
                                                             > backup-triggerauth.yaml
kubectl get deploy -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,REPLICAS:.spec.replicas \
                                                             > baseline-replicas.txt
echo "backed up $(kubectl get scaledobjects.keda.sh -A --no-headers | wc -l) ScaledObject(s)"

Convert every ScaledObject into a WorkloadRule

keda-import reads a ScaledObject and prints the equivalent DevZero WorkloadRule, copying the object verbatim (all triggers, spec fields, labels, and annotations — see the blind‑copy note above). This block runs it for every ScaledObject in the cluster and drops one wr-*.yaml per object into keda-migration/. It only writes files — nothing is applied to the cluster yet, so it is completely safe to run and re‑run.

: > imported.txt   # records the exact originals we convert, for Step 3
kubectl get scaledobjects.keda.sh -A \
  -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name --no-headers |
while read -r ns name; do
  if kubectl get scaledobject "$name" -n "$ns" -o yaml | keda-import > "wr-$ns-$name.yaml" 2>/dev/null; then
    echo "$ns $name" >> imported.txt
    echo "converted  $ns/$name  -> wr-$ns-$name.yaml"
  else
    echo "SKIPPED    $ns/$name  (unsupported field, e.g. scalingModifiers or a custom HPA name)"
    rm -f "wr-$ns-$name.yaml"
  fi
done

Delete your originals (while your KEDA is still running)

Deleting a ScaledObject requires your KEDA operator to be alive: KEDA runs a finalizer that also removes the HPA it built. If you stopped KEDA first, the object would wedge in Terminating forever. So we delete the originals now, while your KEDA is still up. Deleting a ScaledObject does not touch the Deployment — it simply stops being autoscaled and holds its current replica count.

This block deletes exactly the originals you recorded in imported.txt in Step 2, so anything you SKIPPED is left alone automatically.

while read -r ns name; do
  kubectl delete scaledobject "$name" -n "$ns" --wait=true --timeout=60s
done < imported.txt
kubectl get scaledobjects.keda.sh -A     # only SKIPPED originals (if any) should remain

Stop your KEDA

Scaling your KEDA operator to zero is not enough: its cluster‑scoped pieces (the keda-admission webhook, the external.metrics APIService, its ClusterRoles) would linger and collide with DevZero's KEDA. Uninstall the release so those are removed cleanly.

helm uninstall "$KEDA_RELEASE" -n "$KEDA_NS"
kubectl get deploy -n "$KEDA_NS" | grep -i keda || echo "your KEDA controller is gone"

Hand the KEDA CRDs to DevZero

If your uninstall left the KEDA CRDs behind, they are still tagged as owned by your old release, and DevZero's Helm release would refuse to manage them. This one block re‑stamps them as DevZero‑owned so DevZero adopts them in Step 8. It is safe to run even if the CRDs are already gone (the commands simply no‑op on what isn't there).

for crd in scaledobjects.keda.sh scaledjobs.keda.sh triggerauthentications.keda.sh \
           clustertriggerauthentications.keda.sh cloudeventsources.eventing.keda.sh \
           clustercloudeventsources.eventing.keda.sh; do
  kubectl annotate crd "$crd" \
    meta.helm.sh/release-name="$DZ_RELEASE" meta.helm.sh/release-namespace="$DZ_NS" \
    --overwrite 2>/dev/null
  kubectl label crd "$crd" app.kubernetes.io/managed-by=Helm --overwrite 2>/dev/null
done
echo "CRD ownership handed to $DZ_RELEASE (where the CRDs still exist)"

Restore your TriggerAuthentications

DevZero's KEDA authenticates to your scalers using your existing TriggerAuthentications and their Secrets. If Step 4 removed the KEDA CRDs, it also removed the TriggerAuthentication objects (the Secrets always survive). Re‑applying your Step 1 backup guarantees they're present no matter what your uninstall did — and if they were never removed, re‑applying is a harmless no‑op.

Apply the backup only when it actually contains TriggerAuthentications. Guarding on the content this way keeps a real apply failure (a missing CRD, an RBAC gap, a corrupt backup) from being hidden — the naive 2>/dev/null || echo form swallowed every error and reported "nothing to do" even when the restore failed, which would leave DevZero's KEDA unable to authenticate after cutover.

if grep -qE 'kind: (Cluster)?TriggerAuthentication' backup-triggerauth.yaml; then
  kubectl apply -f backup-triggerauth.yaml     # errors surface — do not hide them
else
  echo "no TriggerAuthentications to restore (none existed) — nothing to do"
fi

Create the DevZero WorkloadRules

Now apply every WorkloadRule you generated in Step 2. No KEDA operator is running yet, so DevZero simply records each rule and (once its KEDA is on in Step 8) will render an mpa-* ScaledObject for it. Applying them now means the moment DevZero's KEDA starts, everything reconciles at once.

if ls wr-*.yaml >/dev/null 2>&1; then
  kubectl apply -f wr-*.yaml
else
  echo "no wr-*.yaml to apply (nothing converted in Step 2, or you migrated via Git)"
fi
kubectl get workloadrules.dakr.devzero.io -A     # one per converted object

Turn on DevZero's KEDA

Flip DevZero's KEDA on with a single flag. This deploys DevZero's KEDA controller, adopts the CRDs you re‑stamped in Step 5 (or creates them fresh if your uninstall removed them — either way, no conflict), and reconciles every WorkloadRule into its mpa-* ScaledObject. --reuse-values keeps every other setting from your original DevZero install exactly as it was.

helm upgrade "$DZ_RELEASE" "$DZ_CHART" -n "$DZ_NS" --reuse-values \
  --set dzkeda.enabled=true --wait --timeout 8m

Verify the cutover

DevZero's KEDA should now be the only KEDA: its adapter registers the external metrics API, and each mpa-* ScaledObject becomes READY=True with one HPA per target. This block prints the three things that prove it, plus a replica comparison against your Step 1 baseline.

kubectl get apiservice v1beta1.external.metrics.k8s.io \
  -o custom-columns=NAME:.metadata.name,AVAILABLE:'.status.conditions[?(@.type=="Available")].status'
kubectl get scaledobjects.keda.sh -A \
  -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,READY:'.status.conditions[?(@.type=="Ready")].status',OWNER:.metadata.ownerReferences[0].kind
kubectl get hpa -A | grep keda-hpa-mpa-        # one per migrated workload
diff <(sort baseline-replicas.txt) \
     <(kubectl get deploy -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,REPLICAS:.spec.replicas | sort) \
  && echo "replica counts match the pre-migration baseline"

Expect AVAILABLE=True, every mpa-* object READY=True and OWNER=WorkloadRule, and one keda-hpa-mpa-* HPA per workload. If AVAILABLE is stuck, check DevZero's metrics adapter: kubectl logs -n "$DZ_NS" -l app=keda-operator-metrics-apiserver.