Console Mode

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.

Scripting and automation

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

Vision illustration

How does it work?

One command, one JSON file:

OmniLoader.exe -job \path\to\the\file.json

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.

Why teams reach for console mode

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.

Mission illustration

SQL Server authentication

{
  "SqlServer": {
    "Server": "{{server}}",
    "Database": "{{database}}",
    "Username": "{{username}}",
    "Password": "{{password}}"
  }
}

Omni Loader

console arguments

Run a job and exit. Built for automated migrations and CI/CD pipelines.

--job {path-to-json-file}

A JSON job specification to use. A typical example would be:

OmniLoader.exe --job c:\jobs\sql2synapse.json

--cluster

Run Omni Loader in a distributed cluster mode. Omni Loader becomes a cluster orchestrator and waits for agents to connect to it.

OmniLoader.exe --cluster

--urls {http(s)://ip-range:port}

Listen for incoming connections. A typical example would be:

OmniLoader.exe --urls http://0.0.0.0:5000

--listen-at {http(s)://ip:port}

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.

OmniLoader.exe --cluster --urls http://0.0.0.0:5000 --listen-at http://192.168.1.100:5000

--activate {activation code}

In console mode and CI/CD workflows, you can activate Omni Loader even without firing up the GUI.

OmniLoader.exe --job c:\jobs\sql2synapse.json --activate 12345-6789-0000

The operationalization problem

The migration worked once. Now make it repeatable without the person who clicked it.

A successful pilot proves the path. Production asks a different set of questions: Which settings were used? Who approved them? Can the same job run in staging tonight and production Saturday? What will the scheduler see if it fails?

If the answers live in screenshots, operator memory, and a runbook full of clicks, the migration is not automated. It is merely unattended between manual steps.

Capture the complete migration in a reviewable file so the same intent survives environments, schedules, handoffs, and audits.

You are here when…

The old plan stops being credible.

01

Change control requires review

Source, target, selection, mappings, and overrides need to be visible in a pull request before the production window begins.

02

The job must run after hours

A scheduler or deployment pipeline—not a person keeping a browser open—should start the run and receive a useful exit result.

03

The pattern repeats

Environment refreshes, rehearsals, phased migrations, and many-source programs need the same contract to run more than once.

Before

Before: the configuration disappears into the interface

Teams compare screenshots, transcribe values into tickets, and discover during a handoff that one table had a special filter nobody documented. Reproducing the job means reproducing the operator’s memory.

After

After: the migration becomes a deployable artifact

Define sources, targets, table selection, mappings, performance choices, and overrides in JSON. Run the file with the console, keep it in source control, and give automation structured logs and an exit status it can act on.

Use this capability when

The situation, not the feature list, says yes.

✓ Migration configuration must pass peer review or formal approval.
✓ You need the same job across development, rehearsal, and production environments.
✓ A scheduler or CI/CD system owns the execution window.
✓ Operations needs an audit trail that explains both the declared intent and the observed run.

Progress you can see

Review before execution

Treat migration configuration like deployment configuration: diff it, approve it, version it, and roll it back.

Reliable handoffs

A teammate can understand what will run without reconstructing choices from a UI session.

Automation with the full feature set

Headless execution keeps table selection, mappings, overrides, and deployment options instead of becoming a reduced second interface.

The job file is the migration contract.

The command starts the process. The durable value is the specification beside it: a readable statement of what moves, where it goes, which exceptions apply, and what another operator can safely run again.

Save time. Get the job done.

Bring a real source and target. We'll scope the migration and show you live throughput on your data.