Migrate from Netflix Conductor OSS to Orkes: recommended approach, data migration, and cutover plan

Quick Answer: The safest way to migrate from Netflix Conductor OSS to Orkes is to treat it like any other mission-critical platform move: align versions, replicate configuration and definitions first, validate against Orkes in parallel, backfill or snapshot historical data only if you need it, then perform a controlled cutover with a rollback path.

Frequently Asked Questions

What’s the recommended overall approach to migrate from Netflix Conductor OSS to Orkes?

Short Answer: Standardize on a compatible Conductor version, mirror your workflows and tasks into Orkes, run a parallel test environment, and then cut traffic over incrementally with a clear rollback plan.

Expanded Explanation:
Orkes Conductor is built by the original creators of Netflix Conductor and extends the core OSS engine into a fully managed, enterprise-grade platform. That means most of your workflow and task definitions, and a lot of your client code, can move over with minimal change—if you plan the migration carefully. The high‑level strategy is: stabilize what you have on OSS, replicate the logical model (workflows, tasks, queues, configs) into Orkes, validate behavior and performance using non‑production or mirrored traffic, then move production traffic in stages while you monitor SLAs and error rates.

Think of this as a platform migration, not a “lift-and-pray.” You want: version alignment, config parity, observability baselines, and clear ownership of who flips which switches. The more you treat this like any other critical distributed system migration—rehearsals, playbooks, dry runs—the smoother it will be.

Key Takeaways:

• Align Conductor OSS and Orkes Conductor versions, then mirror workflow/task definitions and configuration first.
• Use a parallel Orkes environment for validation, then perform staged traffic cutover with metrics, alerts, and rollback defined.

---

How do I practically migrate my workflows, tasks, and configuration into Orkes?

Short Answer: Export your workflow and task definitions from OSS, recreate or import them into Orkes, update workers to use Orkes endpoints/credentials, and validate end‑to‑end flows in a non‑production Orkes environment.

Expanded Explanation:
From a mechanics standpoint, Conductor OSS and Orkes share the same underlying model: workflows are definitions (JSON/UI/SDK), tasks are units of work executed by workers, and executions are managed with retries, timeouts, and state. Migrating is largely about moving those definitions and redirecting worker and client traffic to Orkes.

In practice, you’ll:

• Inventory your existing system (workflows, tasks, event handlers, worker languages, queues, and external dependencies).
• Set up an Orkes organization/environment (Dev/Stage/Prod) and SSO/RBAC so multiple teams can work safely.
• Import or recreate your workflow and task definitions in Orkes via UI, JSON, or SDKs; align names, versions, and input/output contracts.
• Point workers and client applications to Orkes (e.g., https://api.orkes.io) using Orkes-authenticated SDKs/credentials.
• Use Orkes’s execution tracing, logs, and metrics to validate behavior before sending live production load.

Steps:

1. Inventory and align versions: Document workflows, tasks, workers, and dependencies; ensure your OSS Conductor version is compatible with Orkes (or plan a pre‑migration OSS upgrade).
2. Mirror definitions in Orkes: Import/create workflow and task definitions, event handlers, and dynamic configs using the Orkes UI, JSON, or SDKs/CLI.
3. Repoint workers and clients: Update Conductor workers and client apps to talk to Orkes APIs with appropriate authentication; test end‑to‑end flows in a lower environment before production cutover.

---

How should I think about data migration—do I need to move all my historical executions?

Short Answer: You usually don’t need to migrate all historical workflow data; treat OSS as your historical archive, and only move state that’s actively required (e.g., long‑running in‑flight workflows or compliance‑critical history).

Expanded Explanation:
Conductor store schemas and implementations vary by your OSS setup (MySQL, Postgres, Redis, ES, etc.). Orkes runs and manages its own durable, high‑availability backing stores. Direct database‑to‑database migration isn’t just discouraged—it’s a recipe for subtle corruption plus painful debugging. The operationally sane approach is to separate configuration migration (definitions, queues, events) from execution/data migration.

For most teams, keeping OSS read‑only for historical queries and letting new workflows start on Orkes is enough. If you have long‑lived workflows or regulatory requirements, you can model “handoff” patterns (e.g., marking OSS workflows as completed once an equivalent Orkes workflow finishes) or export summaries to your data warehouse instead of trying to replay raw internal state. Ask whether you actually query raw Conductor tables, or if you can meet requirements with logs, summaries, or observability exports.

Comparison Snapshot:

• Option A: No historical migration (recommended default)
  Keep OSS for history, start all new executions on Orkes.
• Option B: Partial migration of critical/in‑flight items
  Handle in‑flight workflows via domain logic (e.g., restart equivalent workflows on Orkes), and optionally export limited history into a data warehouse.
• Best for: Enterprises that want to minimize risk, preserve auditability, and avoid brittle schema‑level data moves.

---

What does a production cutover plan from OSS to Orkes look like?

Short Answer: Implement a staged cutover: start with non‑critical workflows in Orkes, then gradually move more traffic while watching metrics, with feature flags or routing rules in place to roll back if needed.

Expanded Explanation:
A good cutover plan acknowledges that your team cares about SLAs and on‑call load, not a “big bang” story. Start by mirroring a few low‑risk workflows to Orkes and running them in parallel to validate behavior, performance, and observability. Then introduce a routing abstraction (feature flags, config toggles, or gateway rules) to choose between OSS and Orkes per workflow or per tenant. As confidence grows, shift more traffic. Leave OSS in a “drain” mode handling remaining in‑flight instances until they complete or are intentionally terminated.

You’ll also want to configure Orkes observability from day one: export metrics to Prometheus/Grafana or Datadog, wire alerts for failure rates and latency, and ensure your team knows how to use Orkes’s execution tracing and audit logs when something goes wrong.

What You Need:

• Traffic control: Feature flags, config toggles, or API gateway/routing rules to send selected workflows or tenants to Orkes while others remain on OSS.
• Runbooks and observability: Dashboards, alerts, and clear runbooks for when to fail back to OSS, how to pause new starts, and how to debug executions in Orkes.

---

How should we think strategically about moving from self‑hosted OSS to Orkes in the long term?

Short Answer: Treat the migration as replacing brittle, self‑managed orchestration with a governed, enterprise‑grade execution layer that reduces on‑call toil, centralizes agentic workflows, and de‑risks future scale.

Expanded Explanation:
Running Netflix Conductor OSS yourself works—until your organization relies on it. At that point the pain shows up as on‑call pages during upgrades, uneven observability across teams, and governance gaps about who can change workflows, secrets, or SLAs. Orkes Conductor is designed as the next step: it’s built on the same core engine, but adds the production controls enterprises actually need—RBAC, audit logs, Git‑like versioning with rollback, deep metrics, and up to 99.99% availability SLAs on managed infrastructure.

Strategically, moving to Orkes isn’t just about offloading infrastructure. It’s about establishing orchestration as a shared production layer for AI agents, humans, and services: a place where LLM‑driven decisions live inside guardrails, human approvals are first‑class tasks, and every execution is traceable end‑to‑end. That’s the layer that moves you from one‑off agent demos and brittle microservice wiring to a platform you can safely scale across teams.

Why It Matters:

• Reduced operational risk and toil: You offload cluster management, upgrades, and datastore tuning, while gaining consistent observability, RBAC, and auditability across all teams.
• Future‑proof orchestration for agents and services: Orkes gives you a unified platform for microservices orchestration and agentic workflows, so when AI usage grows, you’re not re‑architecting under pressure.

---

Quick Recap

Migrating from Netflix Conductor OSS to Orkes is most successful when you treat it as a structured platform migration: align versions, mirror workflow and task definitions into Orkes, and stand up a parallel environment for validation. For data, avoid database‑level moves; keep OSS as a historical archive and focus on clean cutover for new executions, with special handling only for truly critical in‑flight workflows. Design a staged cutover that shifts traffic incrementally, backed by robust observability, clear runbooks, and a rollback path. Strategically, the move replaces self‑managed, brittle orchestration with an enterprise‑grade execution layer for microservices and agentic workflows, backed by SLAs, governance, and scale proven across 1,000s of organizations.

Next Step

Get Started