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.
| Mode | Behavior |
|---|---|
preserve (default) | Keep tracking data; required to use --resume |
truncate | Delete the content of all tracking tables (all runs), keep the tables |
drop | Drop 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
- SQL Server -- full connection reference
- Database Connections -- auth file format and security