Evidence-based drift auditor and migration toolkit for SQL Server: verifies every migration against the live database with ScriptDom, cross-checks DbUp and Flyway journals, and gates CI with JSON reports.
Migration tools like DbUp and Flyway decide a script ran because a row exists in their history table. They never look at the schema. SchemaScope is evidence-based: it parses every versioned T-SQL script with Microsoft's ScriptDom and verifies it object-by-object against the live SQL Server database, so a hand-edited database, a half-failed script, or a lying journal cannot hide. The walkthrough below follows the everyday flows, one screen at a time.
Launching SchemaScope opens a full-screen dashboard: status pills for the database, server, script count, and auth mode, connection and workspace cards, and a grouped, searchable menu. Every action opens on a clean screen and returns here when it finishes.
First run opens a six-step wizard: server, authentication with a live connection test, a database picker straight from sys.databases, script-folder validation with a live count of matching files, and naming-scheme presets. Passwords live in an environment variable or a masked session prompt, never on disk unless you opt in. Rerun it any time from Settings.
One command probes every script in range and classifies each as applied, partial, missing, or no-DDL, then splits real pending work from historical drift caused by later drops and renames. The report drills to object level: which table, column, index, or procedure is absent or different, and why.
Already on DbUp or Flyway? SchemaScope reads their history table and verifies every claim against the schema. It catches journal lies (recorded as applied but absent from the database), untracked scripts (applied by hand, never journaled), orphaned entries, and failed Flyway rows.
Evidence cannot see a data fix, so an opt-in history table records every run with duration and outcome. The audit then cross-checks SchemaScope's own history like any other journal: DDL claims are verified against the schema, and a data script with no record is flagged as possibly never run.
A dry run prints the execution plan without opening a database connection: how many batches each script splits into, which DDL objects it declares, and any T-SQL parse errors, so a broken script is caught before it touches anything.
Full heal applies everything pending in order, with prepatch support. Per-script transactions roll back on failure, so a script that dies halfway leaves no partial changes behind and the database stays in a known state.
Backup, restore, and clone run with live progress bars. Clone backs up a source database and restores it under a new name in one step, so a production-shaped test database is a single command instead of a manual backup-restore dance.
Every read-only command speaks JSON: pure payload on stdout, diagnostics on stderr, deterministic exit codes. A composite GitHub Action runs the audit with a markdown job summary, a Docker image covers any other runner, and the same binary installs as a global dotnet tool.