Plan and orchestrate an application migration, not a turnkey migrator.
Run a migration as a workflow your platform team can read: inventory, dependency checks, integration tests, data transfer, validation, a cutover gate a person approves, and a rollback someone owns. The migration tools stay yours; OCNORA sequences them and keeps the record.
Three workflows teams build here first.
- 01
An inventory of the applications in scope, their owners, dependencies and data stores, kept as the input every later step reads.
- 02
A rehearsal run: dependency checks and integration tests against the target environment, repeated until they pass, before any data moves.
- 03
The cutover itself: data transfer and validation, then a gate where a named approver decides to cut over or hand the run to the rollback owner.
What runs, step by step.
An orchestration pattern, not a migration engine: the plan is checked and rehearsed, data moves with your own tools, the target is validated, and a person approves the cutover or hands it to the rollback owner.
- 01Start the migration run
- 02Inventory apps and owners
- 03Check dependencies
- 04Run integration tests
- 05Transfer data
- 06Validate the target
- 07Cutover gate: approve?
- 08Cut over
- 09Rollback owner decides
- 10Report the outcome
Every step is a node type in the catalog. Diagram only: no data, no live run.
Before you start
- An inventory of the applications in scope, with an owner, dependencies and data stores for each.
- The migration tooling you already use (deploy pipelines, data transfer jobs, infrastructure scripts) reachable over HTTP or as workflows.
- Integration tests and validation queries that say whether the target works, runnable against it before cutover.
- A named approver for the cutover gate and a named rollback owner, with a rollback plan and a backup taken before the run.
What you get
Each migration run leaves a record of the inventory it used, the checks and tests it ran, the data transfer and validation results, and who approved the cutover or took the rollback.
Limitations
- OCNORA plans and orchestrates an application migration; it is not a migration engine. It does not convert, re-platform or move applications itself: that work is done by the tools and teams the workflow calls.
- The workflow shown is an orchestration pattern, not a template in the library. You assemble it from the steps shown and test it against your own environment.
- Checks catch what they test. A cutover that passes weak integration tests or validation can still fail, which is why a person approves it.
- OCNORA does not roll back a migration. Rollback means your own plan, backup or reverse script, run by the owner who decides it.
- We publish no duration, success-rate or downtime figure for migrations.
Source: evidence register C10 (OCNORA_WEBSITE_IMPROVEMENTS task WEB-045); human.prompt approval step per claims.humanApprovals · illustrative · checked 2026-09-28.
Source: coax-backend human.prompt node and router (evidence register C12, C13, C16; E07 (OCNORA_WEBSITE_IMPROVEMENTS task WEB-033)) · unverified · checked 2026-09-28.
AI screen, human approve, then send
Classify an inbound request, ask a reviewer to approve or reject it, and email the requester the outcome.
See each step's output, and approve the risky ones.
Illustrated with a support workflow; the run view and the approval request look the same for every workflow.
Built for this, not adapted to it.
Planning separated from execution
The inventory and dependency checks are their own steps, so the plan is reviewed before anything changes. The tools that move or rebuild an application are called by the workflow, not replaced by it.
Your tools, sequenced
Integration tests, data transfer jobs and deploy scripts are called over HTTP or as sub-workflows. OCNORA decides the order and records each result.
Tests gate the next step
A branch reads the test and validation results. A failing check stops the run with its output instead of carrying on to cutover.
A cutover gate a person approves
A human.prompt step suspends the run until the approver answers or its timeout lapses, and the decision is recorded with the run.
Rollback has an owner
When validation fails or the approver says no, the run goes to a named rollback owner. OCNORA does not undo a migration on its own.
One record of the migration
Each step’s input, output and error sits on the run, so the inventory, the checks, the approval and the outcome can be read afterwards in one place.
Start from one of these.
Each one imports into a workspace; swap the connections and run it.
- AI screen, human approve, then sendClassify an inbound request, ask a reviewer to approve or reject it, and email the requester the outcome.
- Nightly CSV feed to SQLDownload a CSV export every night, parse it, normalise the columns with the Process engine and upsert into a table.
- Scheduled health check with email alertPing an endpoint every 5 minutes; if it does not return 200, email the on-call address with the status code.
Apps this kind of workflow usually touches.
Each one has its own page with operations, triggers and auth.
GitHub
GitLab
Jira
Slack
PostgreSQL
MySQLRead before the first live run.
- How to test a workflow before it touches anything realStatic validation, a dry run against real config with side effects held back, then a first live run on one record. A practical order for shipping automations safely.
- How to keep an AI agent’s spending close to the number you setA retry loop, a huge tool result or a growing prompt can turn one agent into a runaway bill. Here’s how per-tenant budgets and a circuit breaker limit it.
- How much a dry run actually proves before you trust it liveA dry run executes your workflow with side effects suppressed and shows each step’s output shape. That shows the path resolves, not that the result is right.
See a workflow run on your own use case.
Book a technical demo. Bring an n8n file or pick a template, and we build it with you on the canvas while Workflow Health checks it before it ever runs.