Build migration workflows, not a turnkey migration engine.
Move records from an export into a SQL table as a workflow you can read: mapping, type checks, unique keys, batches and retries, then a reconciliation you design and a rollback someone owns.
Three workflows teams build here first.
- 01
A one-off move from a legacy system’s CSV export into a MySQL table, mapped column by column and keyed so a rerun updates rows instead of duplicating them.
- 02
A repeated sync while two systems run side by side, on a schedule, until the old one is switched off.
- 03
A reconciliation after each run: row counts and checksums on both sides, with a named person deciding what happens when they differ.
What runs, step by step.
The template’s steps up to the upsert, then a worked design for the rest: counts and checksums compared on both sides, a report when they match and a named owner deciding on rollback when they do not.
- 01Start a migration run
- 02Download the export
- 03Parse CSV
- 04Map columns, check types
- 05Check unique keys
- 06Work through in batches
- 07Upsert by key, with retry
- 08Count and checksum (worked design)
- 09Totals match?
- 10Owner decides on rollback
- 11Report the run
Every step is a node type in the catalog. Diagram only: no data, no live run.
Before you start
- An export of the source data as CSV at a URL the workflow can reach, with a header row.
- A MySQL or MariaDB connection for the target table, with the table already created: SQL steps refuse DDL.
- A written column mapping, the types each target column accepts, and the key that makes a row unique.
- The count and checksum queries you will reconcile with, run against both the source and the target.
- A named owner for rollback, and a backup or snapshot of the target taken before the first run.
What you get
Each run leaves a record of what was read, mapped, rejected and written, step by step, with the reconciliation results beside it and any rollback decision made by the person who owns it.
Limitations
- This is a set of workflow steps you assemble and test, not a migration engine. Schema design, data cleansing rules and cut-over planning stay with your team.
- The template’s upsert writes one row per call to MySQL or MariaDB. Other targets, including Postgres, are written as SQL in a query step.
- Count and checksum reconciliation and the rollback step are a worked design: we have not yet published a demonstrated example of them.
- OCNORA does not roll back writes. Undoing a run means your own backup, snapshot or reverse script, run by the owner who decides it.
- A query step fails rather than return more rows than its limit, so large checks are written as aggregates (counts, checksums), not full reads.
Source: src/data/templates.json#data-csv-sync-to-sql (npm run sync:templates); evidence register C09 (OCNORA_WEBSITE_IMPROVEMENTS task WEB-044) · illustrative · checked 2026-09-28.
Nightly CSV feed to SQL
Download a CSV export every night, parse it, normalise the columns with the Process engine and upsert into a table.
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.
Starts from a template
The Nightly CSV feed to SQL template downloads an export, parses it, normalises the columns and upserts each record. Import it and change the mapping.
Mapping and type checks in one step
The Process engine maps source columns to target fields and applies rules; a rule set to error stops the run on a bad row instead of writing it.
Unique keys, so reruns are safe
The upsert is keyed on the columns you choose. Running the same batch again updates the existing rows rather than adding copies.
Batches and retries
A For Each step works through the parsed rows, and each step has its own retries and timeout. A step that still fails is kept with its input and error.
Reconciliation you can read
Counts and checksums are ordinary SQL query steps whose results sit on the run, so the comparison is on the record. Shown here as a worked design.
A person owns the rollback
When the totals differ, an approval step asks a named owner what to do. OCNORA does not undo writes on its own.
Start from one of these.
Each one imports into a workspace; swap the connections and run it.
- Nightly CSV feed to SQLDownload a CSV export every night, parse it, normalise the columns with the Process engine and upsert into a table.
- Fan out a list to an APIReceive a list of items by webhook and call an API once per item, five in parallel, continuing past individual failures.
- Delay, retry and dead-letterCall a flaky endpoint with backoff retries; on final failure wait, try a fallback endpoint, and if that also fails email an operator.
Apps this kind of workflow usually touches.
Each one has its own page with operations, triggers and auth.
MySQL
PostgreSQL
Amazon S3
Google Sheets
SlackRead 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 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.