embedded/shared process engine
JavaDelegate
ExecutionListener
TaskListener
Spring/Jakarta bean resolution
JDBC transaction integration
Camunda database schema
Cockpit/Tasklist
External Task workers if used

remote distributed orchestration engine
Zeebe brokers and gateways
job workers
Operate/Tasklist/Identity/Optimize
exporters and secondary storage
Kubernetes/SaaS/self-managed deployment
remote API/client interaction

Camunda 7 solution
= BPMN model
+ engine configuration
+ Java code/delegates/listeners
+ external task workers
+ process variables
+ database/history
+ operational tooling
+ deployment pipeline
+ runbook
+ user task behavior
+ audit/compliance evidence

BPMN/DMN model migration
Application code migration
Running system migration

JavaDelegate tidak jalan langsung di Zeebe
Camunda 7 internal APIs tidak tersedia
transaction boundary berubah
variable serialization berubah
history/tooling berbeda
human task implementation berbeda
external task behavior tidak identik dengan Zeebe job
operations model berubah

Prefer draining old process instances when possible.
Prefer parallel run for bounded period when business allows.
Prefer migrating only when strong reason exists.
Prefer forward recovery over rollback illusion.
Prefer explicit compatibility contracts over hopeful deployment.

Application / Container
  -> Process Engine
  -> Job Executor
  -> Camunda DB schema
  -> Runtime/Repository/Task/History services
  -> JavaDelegate / listener / external task
  -> Cockpit / Tasklist

Java classpath matters
transaction integration matters
DB schema pressure matters
engine config in application matters
job executor competes with app resources

Client / Worker / API
  -> Gateway / Orchestration API
  -> Zeebe brokers
  -> partitions / log stream / state
  -> exporters
  -> secondary storage
  -> Operate / Tasklist / Identity / Optimize

network boundary matters
worker lifecycle matters
job timeout/retry matters
broker/gateway health matters
secondary storage freshness matters
Kubernetes/SaaS/self-managed operations matter

synchronous in-transaction delegate -> remote job execution
local Java exception -> job failure/BPMN error command
local DB transaction boundary -> worker-managed transaction boundary
local engine API -> Camunda 8 client/API
Cockpit model -> Operate model
Camunda 7 DB history -> Camunda 8 exported/secondary storage model

process key / BPMN ID
current deployed versions
running instance count
average duration
max duration
active activities
events used
gateways used
subprocess/call activity usage
compensation/error/escalation usage
DMN/business rule task usage
user task usage
service task implementation
listeners/extensions/custom attributes

start events
end events
service tasks
user tasks
business rule tasks
call activities
subprocesses
event subprocesses
boundary events
message events
timer events
error events
escalation events
compensation events
gateways
input/output mappings
expressions
extension properties

${bean.method(execution)}
Java class delegate reference
expression delegate
listener class
field injection
script task
execution/task listener
custom extension properties

public class ValidateOrderDelegate implements JavaDelegate {
  public void execute(DelegateExecution execution) {
    // read variables
    // call service
    // set variables
    // throw exception or BpmnError
  }
}

activate job by type
read job variables
perform work
complete/fail/throw BPMN error
set output variables

execution object hilang
engine-local transaction boundary hilang
classpath-bound delegate hilang
bean expression tidak otomatis sama
job timeout/retry harus dipikirkan
worker deployment/versioning terpisah
network failure menjadi bagian model

[ ] Inventory semua JavaDelegate.
[ ] Klasifikasikan delegate: pure computation, DB write, API call, event publish, mixed side effect.
[ ] Identifikasi variable input/output.
[ ] Identifikasi exception behavior.
[ ] Identifikasi BpmnError behavior.
[ ] Identifikasi transaction dependency.
[ ] Identifikasi injected services/repositories.
[ ] Identifikasi hidden business rules.
[ ] Tentukan job type untuk worker baru.
[ ] Tentukan idempotency key.
[ ] Tentukan retry/timeout/backoff.
[ ] Tambahkan tests untuk happy path and failure path.

BPMN service task job type: validate-order
Worker method: validateOrder(job)
Input variables: orderId, tenantId, correlationId
DB reads/writes: explicit via service/repository
Output variables: validationResult, validationReason
Failure: technical fail with retries
Business error: throw BPMN error with code
Idempotency: processed_job/job_key/business_command table
Observability: metrics/log/trace by processInstanceKey/orderId/jobType

fetch and lock
external task topic
worker ID
lock duration
complete
handleFailure
handleBpmnError
extendLock
retries

activate jobs
job type
worker name
job timeout
complete job
fail job
throw BPMN error
retries
backoff
max jobs active

[ ] Map external task topic to Zeebe job type.
[ ] Map lock duration to job timeout.
[ ] Map worker ID to worker name/identity.
[ ] Map handleFailure to fail job with retries/backoff.
[ ] Map handleBpmnError to throw BPMN error.
[ ] Map long polling config to job activation/polling/streaming behavior.
[ ] Review variable fetch list vs job variable payload.
[ ] Review duplicate execution behavior after timeout.
[ ] Review worker graceful shutdown.
[ ] Review scaling/concurrency/backpressure.

"External task worker already exists, so just change the client."

worker concurrency semantics may change
variable payload shape may change
error reporting may change
retry/backoff behavior may change
observability dashboard may change
incident workflow may change
security credentials may change

Java serialized object variables
large payload stored as variable
class version dependency
custom serializers
sensitive data in history
object mutation by delegates
parallel variable overwrite
input/output mapping behavior
variable scope differences

[ ] Inventory all variable names/types.
[ ] Identify Java serialized object variables.
[ ] Identify large payload variables.
[ ] Identify sensitive variables.
[ ] Identify variables used by gateways/expressions.
[ ] Identify variables used by listeners/delegates/workers.
[ ] Define JSON schema or lightweight variable contract.
[ ] Move large domain payload to business DB if needed.
[ ] Define variable compatibility for old/new workers.
[ ] Define audit/retention policy for migrated variables.

orderId
quoteId
tenantId
correlationId
approvalDecision
validationStatus
falloutReasonCode

fullOrderPayload
entireCustomerProfile
rawExternalApiResponse
accessToken
hugeSerializedJavaObject
mutableNestedObjectSharedAcrossParallelBranches

candidate users/groups
assignee
claim/unclaim
complete
task forms
embedded vs linked forms
due date/follow-up date
task listener behavior
authorization
tenant visibility
audit trail
custom task UI/API

[ ] Inventory all user tasks.
[ ] Identify forms and form technology.
[ ] Identify assignment expressions.
[ ] Identify task listeners.
[ ] Identify custom task APIs.
[ ] Identify task search/filter requirements.
[ ] Identify authorization/tenant requirements.
[ ] Identify SLA/due-date behavior.
[ ] Test claim/complete/concurrent completion behavior.
[ ] Verify audit trail equivalence.

assigning task dynamically
writing audit records
sending notification
setting variables
creating comments
calling external systems

decision table compatibility
hit policy
input expression
output names/types
FEEL/expression difference
business rule task binding
versioning
existing audit expectation
testing fixtures

[ ] Inventory DMN decisions.
[ ] Map process tasks to decisions.
[ ] Verify expression compatibility.
[ ] Verify hit policy behavior.
[ ] Verify no-match/default behavior.
[ ] Re-run decision test cases.
[ ] Validate with BA/Product for business equivalence.

RepositoryService
RuntimeService
TaskService
HistoryService
ManagementService
ExternalTaskService
IdentityService

[ ] Inventory Camunda 7 API usage.
[ ] Identify RuntimeService start/correlate usage.
[ ] Identify TaskService query/complete usage.
[ ] Identify HistoryService reporting usage.
[ ] Identify ManagementService job/incident operations.
[ ] Identify custom admin/repair tools.
[ ] Map to Camunda 8 API/client/tooling.
[ ] Review eventual consistency of query/read endpoints where relevant.
[ ] Update JAX-RS façade contracts if exposed to other teams.

audit trail
customer dispute
SLA proof
approval trace
incident investigation
compliance evidence
business reporting
root cause analysis

[ ] Identify current history queries/reports.
[ ] Identify compliance retention requirement.
[ ] Identify audit fields required by business.
[ ] Identify whether historical Camunda 7 data must be migrated.
[ ] Identify whether old Cockpit/history remains read-only during transition.
[ ] Identify reporting impact for Optimize/internal BI/dashboard.
[ ] Define evidence continuity plan.

Camunda 7 ACT_HI_* query = same query in Camunda 8
Cockpit screen = Operate screen
old history retention = new retention
old audit report = new audit report

Drain old instances in Camunda 7; start new instances in Camunda 8.
Run Camunda 7 and Camunda 8 in parallel for different process versions.
Migrate selected running instances.
Restart/cancel and recreate instances with business approval.
Keep Camunda 7 read-only for history while new work moves to Camunda 8.
Bridge Camunda 7 process to Camunda 8 process temporarily.

process duration
number of active instances
business criticality
current activity distribution
manual tasks in progress
external side effects already performed
compensation feasibility
audit requirement
customer impact
migration tooling maturity
rollback/repair ability

process duration is short or bounded
active instance count is manageable
new process can start only for new business cases
old process can be supported for a transition window

old version has production bug
long-running instances cannot wait to finish
operational complexity of dual-running is too high
regulatory/business requirement demands consistent model

source/target definition
activity mapping
variable mapping
task mapping
job/timer/message mapping assessment
incident handling
dry run
backup/rollback/forward repair plan
operator approval
customer impact plan

engine health
job executor health
Camunda DB schema
history cleanup
failed jobs/incidents
Cockpit/Tasklist
application deployment
classloading
database backup/restore

Zeebe broker health
Gateway health
partition leadership
backpressure
exporter health
secondary storage health
Operate/Tasklist/Identity
worker connectivity
Kubernetes/Helm
backup/restore coordination
rolling upgrades

[ ] Define new runbook.
[ ] Define new dashboards.
[ ] Define new alert thresholds.
[ ] Train support/SRE on Operate/Tasklist/Identity.
[ ] Define worker deployment strategy.
[ ] Define backup/restore strategy.
[ ] Define incident response flow.
[ ] Define dual-run support model.

Camunda 7 authorization model
Camunda 8 Identity/access control model
SSO/OIDC integration
service account/client credential
worker credential
connector secret
operator access
tenant isolation
variable visibility
Tasklist access
Operate access
admin/repair privilege

[ ] Map roles and groups.
[ ] Map tenant model.
[ ] Map task access.
[ ] Map admin/operator access.
[ ] Re-evaluate least privilege.
[ ] Migrate secrets safely.
[ ] Validate audit logs.
[ ] Redact sensitive data in new logs/dashboards.

happy path
all gateway branches
all BPMN errors
technical failure/retry/incident
message correlation
timer firing
user task claim/complete
authorization failure
compensation path
duplicate worker execution
external API unknown outcome
DB commit + worker complete failure
Kafka/RabbitMQ duplicate event
process version compatibility

Camunda 7 expected behavior
Camunda 8 migrated behavior
same input
same business outcome
same audit-significant state
known acceptable differences documented

[ ] Create migration inventory.
[ ] Run model conversion.
[ ] Run worker conversion.
[ ] Deploy to test environment.
[ ] Replay representative scenarios.
[ ] Simulate incidents.
[ ] Validate task UX.
[ ] Validate dashboards/alerts.
[ ] Validate rollback/forward recovery.
[ ] Validate support runbook.

unknown BPMN incompatibility
worker rollout mismatch
history/reporting gap
operator unfamiliarity
hard rollback
running instance confusion

select one bounded process
migrate model and workers
run parallel validation
start only new instances on Camunda 8
keep Camunda 7 for old instances/history
learn and iterate

shadow run must not call external side-effecting systems
shadow run must not publish real business events
shadow run must clearly separate test variables/audit

route new tenant/customer/process type to Camunda 8
route existing long-running cases to Camunda 7
disable routing if incident rate rises
preserve idempotency across route change

[ ] Treating Camunda 8 as Camunda 7 with new branding.
[ ] Migrating BPMN files without migrating delegate/listener semantics.
[ ] Turning every JavaDelegate into a worker without redesigning idempotency.
[ ] Keeping huge Java object variables.
[ ] Ignoring running instances.
[ ] Ignoring history/audit/reporting.
[ ] Ignoring human task UX and authorization differences.
[ ] Migrating all processes in one big bang.
[ ] Assuming retry behavior is equivalent.
[ ] Assuming Cockpit operations map one-to-one to Operate.
[ ] Ignoring worker deployment/version compatibility.
[ ] Not training support/SRE on new incident model.
[ ] Not writing migration runbooks.

[ ] Apakah CSG Quote & Order memakai Camunda 7, Camunda 8, keduanya, atau tidak memakai Camunda?
[ ] Apakah ada active migration initiative?
[ ] Apakah ada Camunda 7 JavaDelegate di codebase?
[ ] Apakah ada External Task workers?
[ ] Apakah ada Zeebe job workers?
[ ] Apakah BPMN models punya Camunda 7-specific extension?
[ ] Apakah ada execution/task listeners?
[ ] Apakah ada process variables berupa Java serialized object?
[ ] Apakah ada large payload process variables?
[ ] Apakah ada custom Tasklist/task UI?
[ ] Apakah ada custom Cockpit/admin/repair tooling?
[ ] Apakah HistoryService/ACT_HI_* digunakan untuk reporting/audit?
[ ] Apakah process instances long-running selama hari/minggu/bulan?
[ ] Apakah order/quote state dipengaruhi running process instances?
[ ] Apakah ada migration/runbook/ADR yang sudah dibuat?
[ ] Siapa owner migration: backend, platform, SRE, product, solution architect, BA?
[ ] Bagaimana customer impact dinilai?

Which processes are in scope and why?
What is the current active instance count per process/version?
Can old instances drain naturally?
What JavaDelegate/listener behavior is hidden behind BPMN?
What external side effects exist per service task?
What variables are business-critical?
What data/history must be retained?
What dashboards/reports depend on Camunda 7 history?
How will workers be deployed and versioned?
How will user tasks and forms change?
How will incidents be handled in the new platform?
What is the rollback or forward recovery plan?
What is the smallest safe migration slice?

1. Inventory
   BPMN, DMN, workers, delegates, variables, APIs, reports, incidents.

2. Categorize
   Simple, medium, high-risk process groups.

3. Choose pilot
   Low-risk but representative process.

4. Convert model
   Remove Camunda 7-specific implementation details.

5. Convert code
   JavaDelegate/external task -> job worker/connector where appropriate.

6. Redesign variable contract
   Small JSON-compatible variables, DB for domain state.

7. Build tests
   Scenario, worker, integration, failure, migration tests.

8. Build operations
   Dashboards, alerts, runbook, support training.

9. Deploy parallel
   Start new instances in Camunda 8, drain old in Camunda 7 if possible.

10. Expand gradually
   Process-by-process migration with lessons learned.

Java-local/database-backed process engine

remote distributed orchestration platform with job workers and operational components

same business outcomes
safe retry behavior
idempotent side effects
clear user task ownership
valid audit trail
secure access model
observable operations
controlled rollout
safe recovery path

Can the BPMN be converted?

Can the entire workflow solution be operated, debugged, audited, secured, and evolved safely after migration?