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.

Draining comes first, and it is the step that takes time. Stop starting new workflows on Dapr OSS, let the running ones finish there, and only then move on. A workflow that is still running when you scale the Dapr OSS app to zero does not resume anywhere — it stops where it is.

The whole sequence, in order:

  1. Drain. Stop new asynchronous work on Dapr OSS and let what is in flight complete.
  2. Verify. Confirm the Catalyst project is healthy, as below.
  3. Redirect. Move request traffic to the Catalyst apps.
  4. Stop. Scale the Dapr OSS apps to zero.
  5. Decommission. Remove the Dapr OSS control plane.

Steps 3 and 4 are close together on purpose. Between them, both copies are consuming.

Verify the project in Catalyst​

  • Confirm each app shows as connected in the Catalyst console.
  • Confirm all Dapr resources loaded correctly under your apps.
  • 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​

The two copies of an app cannot both run. This is not a race that usually resolves in your favour — it is how the building blocks work:

  • Pub/sub deliveries split between them. Dapr names the consumer group after the app ID, so both copies join the same group and the broker hands each message to exactly one of them. Half your events are processed by the side you thought was idle.
  • Actors can activate twice. Dapr OSS and Catalyst run separate placement services, and nothing coordinates them. The same actor ID can be active on both sides at once, writing to the same state store. Actor state relies on single activation, so this loses writes silently rather than failing.
  • Input bindings fire on both. Each copy holds its own trigger.

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>

Scaling to zero is what stops consumption. Redirecting request traffic alone does not: an app with no inbound requests still consumes pub/sub messages, still fires its input bindings, and still hosts actors.

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.

warning

Do not remove the Dapr CRDs. Your migrated resources are still Dapr Component, Subscription, Configuration and Resiliency objects — deleting the CRDs deletes every one of them, in every namespace, including the ones Catalyst is now reconciling.

Only one of the commands below can do that: dapr uninstall -k --all. Use dapr uninstall -k without the flag.

helm uninstall is safe either way. The Dapr chart ships its CRDs in the chart's crds/ directory, and Helm never deletes those on uninstall, for exactly this reason. This holds however Dapr was installed — dapr init -k deploys the same chart, which is why you will find a Helm release named dapr even if you never ran Helm yourself.

Confirm they are still there afterwards:

kubectl get crd | grep dapr.io

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

helm uninstall dapr --namespace dapr-system

The Dapr dashboard, if you installed it, is a separate Helm release in the same namespace and is not removed with the control plane:

helm uninstall dapr-dashboard --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

Confirm nothing broke. Removing the control plane should change nothing for the migrated applications, because they no longer talk to it. Exercise them once afterwards — state, service invocation, pub/sub, jobs, actors and workflows — and confirm the Dapr CRDs and your migrated resources are still there:

kubectl get crd | grep dapr.io
kubectl get components.dapr.io,subscriptions.dapr.io,configurations.dapr.io,resiliencies.dapr.io --all-namespaces
Last updated on