--job {path-to-json-file}
A JSON job specification to use. A typical example would be:
Run any migration from a JSON file. Drop it in CI/CD, schedule it, audit it. The full UI feature set is available headless. No exceptions.


Every option you can click is also a JSON key. No second-class headless API.

One command, one JSON file:
By default, every table from every source moves to the target. Want to copy a subset? List them in the JSON. Need per-table customization? It's per-table in the JSON, too. Multi-source migrations use a Sources array instead of a single Source. The docs cover the rest.
Declarative JSON beats clicking through tabs. Every customization is right there in front of you. No hunting through screens to remember what was set last.
When a teammate picks up the project, the file tells them everything they need to know in five minutes.
And because it's a file, it goes in source control. Code review, audit trail, and rollback for free.

SQL Server authentication
{
"SqlServer": {
"Server": "{{server}}",
"Database": "{{database}}",
"Username": "{{username}}",
"Password": "{{password}}"
}
}Run a job and exit. Built for automated migrations and CI/CD pipelines.
A JSON job specification to use. A typical example would be:
Run Omni Loader in a distributed cluster mode. Omni Loader becomes a cluster orchestrator and waits for agents to connect to it.
Listen for incoming connections. A typical example would be:
In cluster mode, this is a public orchestrator IP:port combination that will be sent to agents when they connect. Agents will send data to the API on specified port.
In console mode and CI/CD workflows, you can activate Omni Loader even without firing up the GUI.
Tell us what you're moving.