Quest1
Solutions · TEMPORAL · MIGRATION

Shinro for Temporal Migration

Migration from BPMN platforms to Temporal, for the teams running the move. Inventory the estate, grade the processes, generate Temporal-native workflow code, validate it against the source analysis and the Temporal design rubric. The deterministic work compresses into hours and days. The engineering judgment stays with you.

Demo of migration from Camunda 8 to Temporal
$ cat what-it-is.md

What it is.

Shinro for Temporal Migration is Quest1's AI-assisted platform for migrating BPMN-based process automation to Temporal. It covers the full arc of a migration: source inventory, worker code analysis, process grading, Temporal-native code generation, and static validation of the generated code. Built for engineering teams moving an existing BPMN estate onto a code-first durable execution platform.

Camunda 8 is the first supported source, validated against versions 8.7 through 8.9. Other Camunda versions and other BPMN platforms are on the roadmap. Targets are Temporal Cloud or self-hosted Temporal, and generated code targets the Temporal Go and Java SDK. The platform installs into your own environment and runs inside your network.

The platform compresses the deterministic work into hours and days instead of weeks: estate inventory, model-to-code translation, worker code analysis, and per-process validation. The engineering judgment stays with you: workflow decomposition and Activity boundaries, in-flight instance strategy, user task and operational tooling decisions, versioning and rollout policy, and cutover sequencing.

Part of the Shinro family, Quest1's umbrella brand for AI-assisted engineering tooling, built to accelerate adoption of the technologies we partner on.

$ ls deliverables/

What you get.

Shinro Connector.
Connects read-only to the source BPMN engine and validates cluster access with the credentials you supply. Access is restricted in code to query and metadata endpoints. No deploy, cancel, or modify endpoint is reachable. Output is a verified connection profile before any analysis runs.
Shinro Analyzer.
Inventories processes, decisions, and job workers across the deployment. Scans worker source code and extracts per-worker metadata: job types, variables, call graphs, side effects, and error mappings, with file-and-line citations. Output is the deployment inventory and a severity-graded worker code scan.
Shinro Assessor.
Classifies BPMN constructs against their Temporal equivalents and scores each process on a complexity rubric, graded A to E for automation readiness, with complexity analysis covering user tasks, message correlation, and DMN. Output is the readiness assessment and migration recommendations.
Shinro Code-Gen.
Generates Temporal-native Workflow and Activity definitions in Go from the models and worker analysis, including custom connectors. Translates expressions, gateways, timers, error boundaries, and retry policies into code. Every DMN decision table is generated as its own Go or Java file, with nothing left as a manual stub. Generated code is written into your repository.
Shinro Validator.
Statically reconciles the generated code against the source analysis, checking construct coverage, code mapping, and workflow determinism, then runs an LLM review of the generated Workflows against a Temporal design rubric. Output is a validation summary report with discrepancies flagged for engineer review.
Conversational interface plus CLI.
Web-based conversational interface for assessment and reporting. Companion command-line utilities for code generation and validation, so those steps sit in the pipeline your team already runs.
$ ls scenarios/

Built for.

Four common migration scenarios where the platform compresses time and risk.

01
Migrating a Camunda 8 estate to Temporal
Full-estate migration from Camunda 8 to Temporal Cloud or self-hosted Temporal. The Connector and Analyzer handle inventory and worker code extraction. Code-Gen produces Temporal-native Workflow and Activity definitions in Go or Java, with expressions, gateways, timers, error boundaries, and retry policies rebuilt in code.
02
Assessing migration readiness before committing
Run the Connector and Analyzer against the source deployment to get a full inventory, then let the Assessor grade each process A to E for automation readiness and flag the complexity drivers: user tasks, message correlation, and DMN decisions. Use the output to size the work, identify the processes that need engineering attention, and decide go or no-go before any code is written.
03
Translating job worker code for Temporal
Scan an existing worker codebase to extract job types, variables, call graphs, side effects, and error mappings, then get Temporal Activity code generated against those findings. Useful as a standalone exercise ahead of the estate move, when the question is how much of the worker layer actually carries over.
04
Checking generated code before cutover
Run the Validator across generated workflow code to reconcile it against the source analysis: construct coverage, code mapping, and workflow determinism, plus an LLM review against a Temporal design rubric. Useful for migrations executed manually or with other tools, where nobody has systematically checked that the target code covers what the source models actually did.
$ cat how-it-works.md

How it works.

A migration runs in six phases. Shinro automates the deterministic work across the first four. Cutover and optimization stay with engineers, because they are decisions rather than steps. Assessment and reporting run through a web-based conversational interface, and code generation and validation run through companion command-line utilities.

Assessment and analysis begins with Shinro Connector verifying credentials and testing the connection to the source engine, read-only. Shinro Analyzer then builds the inventory: BPMN models, DMN decisions, job workers, and deployment topology. A questionnaire fills the gaps the automated inventory leaves, covering the context that does not live in the deployment itself. A static scan of worker source code runs alongside, extracting job types, variables, and side effects, so the shape of the work is known before any of it starts.

Strategy and design is where Shinro Assessor grades each process A to E for automation readiness and analyses the complexity drivers: user tasks, message correlation, and DMN decisions. The target environment is settled here, Temporal Cloud or self-hosted, and the assessment report and migration recommendations come out of this phase. Workflow decomposition and Activity boundaries are decided by engineers against the graded estate.

Conversion and migration is where Shinro Code-Gen translates the expressions and rules held inside the models, converts job workers, retries, and connectors into code, matches error behaviours and response types, and emits Temporal Go or Java SDK code. DMN decision tables are generated as Go or Java files alongside the workflows. Generated code is written into your repository, where your engineers review it with the diff and review process they already use.

Verification is where Shinro Validator reconciles the generated code against the source analysis. It checks that every construct the Analyzer found is covered in the target code, that the mapping from model to code holds, and that the generated Workflows satisfy Temporal's determinism constraints. An LLM review then assesses the generated code against a Temporal design rubric. Output is a validation summary with discrepancies flagged. The phase closes when coverage is complete and every flagged item has been triaged by an engineer.

Cutover is engineer-led. New process instances stop on the source engine and new starts route to Temporal. In-flight work is drained rather than re-bound, because BPMN engines and Temporal have no shared re-binding mechanism, so the sequencing and the drain window are planning decisions made ahead of the move. Source process definitions, job workers, and exporters retire once the queue is clear, and incident triage moves onto the Temporal operations surface.

Optimization and operation is engineer-led too. The source engine is decommissioned once in-flight instances drain. Remaining runtime slices are integrated on the new surface, including operations console, user tasks, and forms. Monitoring, alerting, and access policy are established on Temporal, and capacity planning follows for the new deployment.

$ cat roadmap.md

Roadmap.

What's coming next, in order of likely release.

01
Migration health signals.
Progress and risk signals across the migration estate.
02
Additional SDK language support.
Languages beyond Go and Java, plus more libraries and frameworks in Shinro Code-Gen and Shinro Analyzer.
03
Other BPMN platforms.
Support for other Camunda versions and other platforms including Pega and TIBCO.
04
Operational tooling.
Equivalents for platform operations consoles, specifically Camunda Operate and Camunda Tasklist.
05
In-flight instance migration.
Deterministic replay against a snapshot, plus a cutover rollback path.
$ cat faq.md

FAQ.

Who is this for?
Engineering teams migrating an existing BPMN estate to Temporal. Useful both for teams running the migration and for teams that want to assess and de-risk before committing to a full engagement.
Which phases does the platform automate?
The first four: assess and analyze, strategy and design, conversion and migration, and verification. Cutover and optimization stay with engineers. Architectural calls stay with engineers throughout, including workflow decomposition and Activity boundaries, in-flight instance strategy, user task and operational tooling decisions, versioning and rollout policy, and cutover sequencing.
Does it replace migration engineering work?
No. It compresses the deterministic work of inventory, model-to-code translation, worker code analysis, and validation, so engineering time goes to the judgment calls. Quest1 also runs full-engagement migrations where our engineers handle those calls. See the Temporal Workflow Migration service for that path.
Which source platforms are supported today?
Camunda 8 is the first supported source, validated against versions 8.7 through 8.9. Other Camunda versions and other BPMN platforms including Pega and TIBCO are on the roadmap. Tell us your platform if you do not see it listed.
Does it support Temporal Cloud and self-hosted as targets?
Yes. Migrations land on either Temporal Cloud or self-hosted Temporal.
Which Temporal SDK languages does it generate?
Go and Java. Additional SDK languages are on the roadmap.
How are DMN decisions handled?
Every DMN decision table is generated as its own Go or Java file. Nothing is left as a manual stub. DMN is also inventoried during assessment and factored into the complexity analysis that grades each process.
How is the generated code reviewed?
Generated Workflow and Activity definitions are written directly into your repository. Review and editing happen in your own tools, against your own diff and review process. There is no separate in-platform editing surface to learn or to keep in sync with your codebase.
What happens to in-flight process instances?
In-flight instances are drained rather than migrated. BPMN engines and Temporal share no re-binding mechanism, so new starts route to Temporal while existing instances complete on the source engine, and the source is decommissioned once the queue clears. The drain window is a planning decision made during design. Deterministic replay against a snapshot is on the roadmap.
What about user tasks, forms, and the operations console?
Those runtime slices are integrated on the Temporal surface during the optimize and operate phase, and the platform flags them during complexity analysis so they are scoped ahead of the move rather than discovered at cutover. Generated equivalents for platform operations consoles such as Camunda Operate and Tasklist are on the roadmap.
How is the migration validated?
Shinro Validator dual-runs the generated workflows and the source originals on identical inputs and compares outputs per process, with replay tests against captured histories in CI. Output is a parity audit trail with discrepancies flagged for review.
How is it delivered?
Shinro installs into your own environment. Customers typically deploy it in their own cloud infrastructure and run it inside their own network, behind their firewall. Assessment and reporting run through a web-based conversational interface; code generation and validation run through companion command-line utilities. The platform is not licensed separately. Shinro is included in Quest1's Temporal migration engagements, so access comes with the work rather than as a standalone product purchase.
Is my data safe?
Shinro runs inside your network. The platform connects read-only to your source engine, and worker source code is analysed on the Shinro instance you deployed, in your own infrastructure. Secrets are redacted during analysis while the business logic is preserved, because the logic is what the generated Temporal code has to reproduce. Code generation and review calls run against the AI provider you configure, using your own keys, so the AI path is under your control and your contract. The platform reports nothing back to Quest1. The read-only source connection is enforced in code against a fixed allowlist of query and metadata endpoints, covering search, XML export, statistics, topology, and status. No deploy, cancel, or modify endpoint is reachable from the connector.
$ cat next-steps.md

Two ways forward.

Get Shinro

Shinro is included in Quest1's Temporal migration engagements. Tell us about your estate and we'll scope the work.

Let's Talk

Want Quest1 engineers to run the migration with you? See the Temporal Workflow Migration service: full-lifecycle migration to Temporal with our team in the loop.