Skip to main content
Version: 0.7 (Latest)

SQL Server as Migration Tracking

The migration tracking database is required for every MigratorXpress migration. It can be SQL Server (this page) or PostgreSQL. It records run history, per-run metadata snapshots, per-table task status, row counts, constraint copy results, and event logs. This database also enables --resume for interrupted migrations.

For the complete connection reference and troubleshooting, see the canonical SQL Server page.

Tracking-specific Permissions​

-- Full access to the migration tracking database
ALTER ROLE db_owner ADD MEMBER migratorxpress_user;

The tracking user needs full access to create and manage the internal tables that record migration runs, task statuses, and resume state.

Migration DB Modes​

The --migration_db_mode flag controls how MigratorXpress treats the tracking schema at startup.

ModeBehavior
preserve (default)Keep tracking data; required to use --resume
truncateDelete the content of all tracking tables (all runs), keep the tables
dropDrop and recreate all tracking tables

Upgrading from 0.6​

Tracking databases created by 0.6.x are upgraded in place to the 0.7 schema (run_id added to the catalog primary keys), automatically on the first 0.7 run or manually with --upgrade_migdb. Back up the database first; on large tracking databases the clustered primary key rebuild is the slowest step. See Upgrading the tracking database.

Example Auth Entry​

{
"migration_tracking": {
"ds_type": "mssql",
"auth_mode": "classic",
"info": {
"username": "migrator",
"password": "********",
"server": "sql-host.company.com",
"port": 1433,
"database": "migration_log"
}
}
}

Reference it on the command line with --migration_db_auth_id migration_tracking. The tracking tables are created in the default schema of the login (normally dbo). The tracking entry can also use auth_mode connection_string, trusted or odbc (see Authentication modes).

See Also​

Copyright © 2026 Architecture & Performance.