Migration from OPA or OCP
You already run Open Policy Agent (or a self-hosted OPA Control Plane pipeline) and want EnforceAuth as the enterprise control plane — without rewriting Rego or redeploying every PDP on day one.
This guide is for teams with an existing OPA footprint. If you are migrating from Styra DAS™, use Migration from Styra DAS™ / EOPA instead.
What changes vs what stays
| Layer | Typical today | After migration |
|---|---|---|
| Policies | Git repo, manual bundles, or OCP build | Git-backed source in EnforceAuth — same Rego |
| PDP | OSS OPA or EOPA sidecars/daemons | Keep your PDP — change bundle URL and telemetry |
| Control plane | OCP, scripts, or ad-hoc CI | EnforceAuth — build, test, promote, audit |
| Decision logs | Splunk, files, or none | EnforceAuth ingestion for replay and compliance |
EnforceAuth does not replace OPA on the request path. You point existing PDPs at EnforceAuth-published bundles and API keys for decision_logs / status.
Phased approach
| Phase | Activity |
|---|---|
| 1. Connect | Create tenant, system entity, policy source, bundle destination — Quickstart Steps 1–3 |
| 2. Parallel build | EnforceAuth builds bundles from your Git repo; compare output to your current OCP or script artifacts |
| 3. Parallel run | Point a non-production PDP fleet at the EnforceAuth bundle destination; compare decisions via logs |
| 4. Cutover | Per environment: promote bundle, update PDP config.yaml polling URL, wire API keys — PDP integration |
| 5. Decommission | Retire self-hosted OCP or manual pipeline once all PDPs poll EnforceAuth |
PDP checklist
For each OPA or EOPA instance:
- Bundle service — poll your EnforceAuth bundle destination (S3/GCS/Azure path from deploy output)
decision_logs—service: enforceauthwith an API key (decisions:write) — API keysstatus(optional) — fleet health in console PDP Monitoring —status:write- Labels —
instance_name,environmentfor fleet views - Stagger polling in large fleets — see Deployment patterns
Rego and input shapes stay the same unless you normalize them during migration.
OCP-specific notes
If you self-host OPA Control Plane today:
- Git → bundle moves into EnforceAuth policy sources and deployments
- Promotion across environments maps to EnforceAuth entity hierarchy and multi-environment best practices
- Decision log storage maps to EnforceAuth decision logs and replay APIs
You do not need to run OCP and EnforceAuth in parallel long term — EnforceAuth is the supported enterprise path for the control-plane responsibilities OCP addresses.
Choosing OSS OPA vs EOPA during migration
Existing PDP binary choice is independent of the control-plane cutover. See OPA vs EOPA if you are evaluating EOPA for masking, delta bundles, or partitioning — you can migrate the control plane first and revisit PDP runtime later.