Migrate an existing KEDA installation

Migrate an existing KEDA installation only when the selected Kedify capability requires it. First read KEDA, HPA, and Kedify and Scaling capabilities; a working upstream setup is a valid stopping point.

Migration Overview

Inventory the current KEDA/HTTP add-on releases, CRDs, authentication resources, ScaledObjects/ScaledJobs, generated autoscalers and routing owners. Record versions and save the maintained Helm values, manifests and GitOps revision before migration. Preserve credentials in the approved secret store and persistent predictor/history data separately.

Prepare controller and traffic ownership

Do not uninstall the active control plane as a diagnostic shortcut. Establish safe workload capacity and direct HTTP routing during the handoff. Rehearse the selected source/target versions, CRD retention and chart-hook behavior in a disposable environment before production migration. A generic delete-manifest command can delete CRDs and stored scaling resources.

Uninstall KEDA HTTP Add-on

Before any approved add-on removal, route traffic to ready workload services and verify host/path/TLS behavior, including in-flight requests. Preserve the old route and release configuration for a compatible recovery. Use the existing installation owner’s reviewed removal process only after this traffic handoff.

Uninstall KEDA

The exact removal/retention sequence depends on how the installed KEDA version was deployed. Inspect release manifests/hooks and CRD ownership, and perform the rehearsed owner handoff. Do not delete CRDs or custom resources merely to clear an installation conflict.

Step 2: ScaledObjects Compatibility

Compare existing trigger/authentication contracts against the selected component versions. Retain the ScaledObject desired state where compatible, but validate each source integration and generated HPA behavior; do not assume every cross-version configuration is unchanged. Keep HPA initially, and treat KPA selection as a separate later change after migration is healthy.

Step 3: Migrate HTTPScaledObjects to ScaledObjects

If you were using HTTPScaledObjects from the KEDA HTTP Add-on, you need to migrate them to ScaledObjects using the Kedify HTTP Scaler.

HTTPScaledObject vs ScaledObject Comparison

The HTTPScaledObject resource from KEDA HTTP Add-on needs to be converted to a ScaledObject with a kedify-http trigger. Here’s how the key fields map:

HTTPScaledObject Field	ScaledObject Equivalent	Notes
spec.hosts	triggers[].metadata.hosts	Comma-separated string in ScaledObject
spec.pathPrefixes	triggers[].metadata.pathPrefixes	Comma-separated string in ScaledObject
spec.scaleTargetRef.service	triggers[].metadata.service	Service name
spec.scaleTargetRef.port	triggers[].metadata.port	Port as string
spec.scaleTargetRef.portName	triggers[].metadata.portName	Port name
spec.scaleTargetRef.name	spec.scaleTargetRef.name	Deployment name
spec.scaleTargetRef.kind	spec.scaleTargetRef.kind	Resource kind
spec.scaleTargetRef.apiVersion	spec.scaleTargetRef.apiVersion	API version
spec.replicas.min	spec.minReplicaCount	Minimum replicas
spec.replicas.max	spec.maxReplicaCount	Maximum replicas
spec.scaledownPeriod	spec.cooldownPeriod	Cooldown period
spec.scalingMetric.concurrency.targetValue	triggers[].metadata.targetValue + scalingMetric: concurrency	Concurrency metric
spec.scalingMetric.requestRate.targetValue	triggers[].metadata.targetValue + scalingMetric: requestRate	Request rate metric
spec.scalingMetric.requestRate.window	triggers[].metadata.window	Time window for rate calculation
spec.scalingMetric.requestRate.granularity	triggers[].metadata.granularity	Time granularity

Migration Example

Here’s a practical example showing how to migrate an HTTPScaledObject to a ScaledObject:

Original HTTPScaledObject:

apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
metadata:
  name: http-demo
  namespace: default
spec:
  hosts:
    - www.my-app.com
  pathPrefixes:
    - "/"
  scaleTargetRef:
    name: http-demo-deployment
    apiVersion: apps/v1
    kind: Deployment
    service: http-demo-service
    port: 8080
  replicas:
    min: 0
    max: 10
  scalingMetric:
    requestRate:
      targetValue: 10
      window: 1m
      granularity: 1s
  scaledownPeriod: 300

Migrated ScaledObject:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: http-demo-scaledobject
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: http-demo-deployment
  minReplicaCount: 0
  maxReplicaCount: 10
  cooldownPeriod: 300
  triggers:
    - type: kedify-http
      metadata:
        hosts: www.my-app.com
        pathPrefixes: "/"
        service: http-demo-service
        port: "8080"
        scalingMetric: requestRate
        targetValue: "10"
        window: "1m"
        granularity: "1s"

Key Migration Notes

1. Hosts and Path Prefixes: Convert arrays to comma-separated strings
2. Port Values: Convert numeric ports to strings
3. Scaling Metrics: Specify the metric type explicitly (requestRate or concurrency)
4. Target Values: Convert to strings
5. Trigger Type: Use kedify-http as the trigger type

Step 4: Install Kedify

Follow Install with Helm using the reviewed target release and values. Let the intended configuration owner create/reconcile the compatible scaling resources. For HTTP, author the ScaledObject and let the Agent manage the generated HTTPScaledObject and routing; do not keep two owners for the same traffic/target.

Verification

Verify component readiness, external metrics availability, ScaledObject Ready/Active state, generated autoscaler ownership and target readiness. Exercise a representative existing trigger, HTTP activation/routing where applicable, and scale-in/drain. Compare application latency/errors and backlog with the pre-migration baseline. Record a passing result before expanding the migration.

Recovery

Stop rollout when a gate fails. Maintain safe workload capacity and known-good traffic routing. Restore the saved source/controller configuration only after confirming CRD/data compatibility with the prior release; Helm rollback alone is not a complete CRD/data recovery mechanism. Collect diagnostics for unresolved ownership or compatibility failures.

Get migration help

Collect sanitized installation and controller evidence and the before/after release versions when escalation is needed. Keep the previous release and ownership record available; do not remove CRDs while diagnosing a failed handover.