Skip to main content

Cut over and decommission Dapr OSS

Your workloads are now wired to Catalyst, but the Dapr OSS stack is still running alongside it. This page covers the final phase: confirm the migrated project works, understand what data does not carry over, then move live traffic onto Catalyst and remove Dapr OSS.

Data migration​

Dapr OSS runs a stateful Scheduler service, backed by an embedded etcd, that persists scheduled jobs, actor reminders, and the actor reminders that drive workflows.

When you migrate from the Dapr OSS Scheduler to the Dapr control plane served by Catalyst, you will lose:

  • Scheduled jobs created through the Jobs API.
  • Actor reminders.
  • Workflows — Dapr Workflows are driven by actor reminders, so any in-flight workflow instances will not resume on Catalyst.

There is no documented path for migrating scheduler data from Dapr OSS into Catalyst. If you self-host your own Catalyst region, you may be able to migrate the underlying scheduler data directly, but this is neither officially supported nor documented. If you are in this situation, please contact support@diagrid.io for further guidance.

Therefore, before you cut over, complete or drain any critical in-flight workflows, and record any scheduled jobs and reminders you will need to recreate in Catalyst.

Verify the project in Catalyst​

  • Confirm each App ID shows as connected in the Catalyst console.
  • Confirm all Dapr resources loaded correctly under your App IDs.
  • Send test requests through the Dapr APIs and confirm they arrive at the app and backing infrastructure as expected.

Once the project is verified, you're ready to cut over to Catalyst and retire Dapr OSS. Work through it per app or per namespace so you can roll back a single step if something misbehaves.

Cut over your traffic​

1. Redirect request traffic to the Catalyst apps​

For apps that serve requests — service invocation callers, HTTP/gRPC ingress, or other clients — update the routing (ingress rules, DNS, service mesh, or client configuration) to send requests to the Catalyst-connected apps instead of the Dapr OSS ones.

2. Stop the Dapr OSS apps from processing work​

While both the Dapr OSS and Catalyst copies of an app are running, each one keeps consuming from its sources — any pub/sub message or input binding event may be handled.

Once traffic is redirected, scale down (or delete) the Dapr OSS app deployments so only the Catalyst-connected apps process events:

kubectl scale deployment <app> --replicas=0 --namespace <app-namespace>

Confirm the Catalyst apps are handling all request, pub/sub, and binding traffic before you continue.

Decommission the Dapr OSS control plane​

Once all traffic runs through Catalyst and no workloads still depend on the OSS installation, you can safely remove the Dapr OSS control plane.

Be careful not to uninstall the Dapr CRDs or any resources that have been migrated to Catalyst.

Uninstall the Dapr control plane from the dapr-system namespace:

helm uninstall dapr --namespace dapr-system

Clean up leftover resources. Remove the dapr-system namespace, which also deletes the Scheduler's etcd PersistentVolumeClaims and any remaining control-plane state:

kubectl delete namespace dapr-system
Last updated on