How-to

Migrate a script

The migration tool produces native Sirius integrations — idiomatic sirius.*, not a compatibility shell that still thinks in the old vocabulary.

In the console

Open Migrate.
Paste or import a script from the engine you run today. The {engine} segment on the API is just the source dialect.
Analyze first if you want the report without writing files.
Translate in native mode.
Read the report. Every recognized call site is classified.
Open the output in Studio. Bind connectors. Run it on your samples. Then cut over.

What the report means

Class	What you do
Native	Mapped to a `sirius.*` helper. Already done.
Connector	I/O rewritten to HTTP, database, file, or network calls. Bind a connector and an allowlist.
Needs a look	No safe equivalent. The line stays unchanged and is highlighted. Nothing is silently invented.

A clean script gets a clean translation. A messy one gets a precise list.

From the API or CI

curl -s -X POST "$SIRIUS/migration/<engine>/analyze" \
  -H 'content-type: application/json' \
  -d '{"source":"…script text…"}'

curl -s -X POST "$SIRIUS/migration/<engine>/translate" \
  -H 'content-type: application/json' \
  -d '{"source":"…script text…","mode":"native"}'

Inventory and scaffold routes exist on the same prefix when you are moving many interfaces at once. The output is always Sirius.

The in-product agent can drive the same flow. There is no privileged back-channel — it calls these routes under your RBAC.

After translate

Create the missing connectors. Probe them.
Replace leftover host interop with sirius.http / sirius.db / sirius.file.
Add samples and golden tests in Studio.
Promote a milestone, then wire the transform into a graph.

See the longer Migrate page and the product story.