# Migrate an existing KEDA installation

Migrate an existing KEDA installation only when the selected Kedify capability requires it. First read [KEDA, HPA, and Kedify](https://docs.kedify.io/concepts/keda-hpa-and-kedify/) and [Scaling capabilities](https://docs.kedify.io/features/); 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](https://docs.kedify.io/getting-started/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](https://docs.kedify.io/features/kedify-pod-autoscaler/) as a separate later change after migration is healthy.

## Step 3: Migrate HTTPScaledObjects to ScaledObjects

If you were using [HTTPScaledObjects](https://github.com/kedacore/http-add-on/blob/v0.10.0/docs/ref/v0.10.0/http_scaled_object.md) from the KEDA HTTP Add-on, you need to migrate them to ScaledObjects using the [Kedify HTTP Scaler](https://docs.kedify.io/scalers/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:**

```yaml
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:**

```yaml
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](https://docs.kedify.io/installation/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](https://docs.kedify.io/troubleshooting/collecting-kedify-configuration/) for unresolved ownership or compatibility failures.

## Get migration help

Collect [sanitized installation and controller evidence](https://docs.kedify.io/troubleshooting/collecting-kedify-configuration/) 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.

---
Canonical: https://docs.kedify.io/troubleshooting/migration-from-keda/
Source: src/content/docs/troubleshooting/migration-from-keda.md
Documentation index: https://docs.kedify.io/llms.txt