Standard Operating Procedure — Training Lab

SQL Server → SQL Server (Docker Source, Local/On-Prem Target)

Step-by-step procedure for a same-engine SQL Server migration using the downloadable EB_SampleDB_sqlserver.sql sample database as a Docker-hosted source. Built to exercise the full feature set covered in this SOP: temporal tables, SQL Agent jobs/operators/alerts, Database Mail and SSIS detection, self-referencing foreign keys, and idempotent re-runs.

Tool: Endrias Bridge · Source: SQL Server 2022 (Docker) · Target: SQL Server (local/on-prem) · Est. time: 15–20 minutes

📚 Overview & Scope

This SOP is a training/demo lab, not a production runbook — it uses the sample database bundled with Endrias Bridge to build hands-on familiarity with the parts of a SQL Server → SQL Server migration that don't show up in a plain table-and-data copy: server-level objects (SQL Agent, Database Mail, SSIS, linked servers), system-versioned temporal tables, and self-referencing foreign keys.

ℹ

Both sides can be Docker, both can be native/on-prem installs, or one of each — the procedure is identical either way. This SOP uses Docker for the source (fastest to reset between practice runs) and a local/on-prem instance for the target, since that's the most common way support engineers will actually run this lab.

✅ What This Lab Exercises

Feature	Status	What to expect
Schema + data copy, 37 tables	Core	Full referential-integrity copy — PKs, FKs, indexes, defaults, check constraints.
System-versioned temporal table	Auto	`dbo.products` + `dbo.products_history`. SYSTEM_VERSIONING is disabled before copy and re-enabled after, automatically.
Self-referencing FK	Auto	`dbo.gov_employees.supervisor_id → gov_employees.employee_id`. Disabled with `NOCHECK` during parallel copy, re-validated after.
SQL Agent jobs, operator, alert	Opt-in	3 jobs (1 disabled by design), 1 operator, 1 alert. Requires the Migrate tab checkbox — off by default.
Database Mail	Detect only	1 sample profile. Health Check flags it; never auto-migrated (credentials are encrypted, unrecoverable).
SSIS package (legacy storage)	Detect only	1 sample package. Health Check flags it; not auto-migrated.
Views, procs, functions, triggers, table types	Auto	Applied automatically on the schema-objects step of a same-engine migration.
Post-migration verification	Auto	Row counts + checksums per table, including the temporal table's open-row sentinel.
Re-apply Schema Objects (idempotent re-run)	Auto	Safe to run any number of times after a successful migration — already-correct objects are skipped, not re-broken.

✓ Prerequisites — Source (Docker)

Requirement	Notes
Docker Desktop installed and running	Any recent version; no special configuration needed
SQL Server 2022 container, port 1433 published to the host	See Step 1 for the exact `docker run` command
`sample_databases/EB_SampleDB_sqlserver.sql` downloaded	Same file the website download serves — the `website/` and `sample_databases/` copies are kept identical
SQL Server Agent running inside the container	Starts automatically with the container; required for the SQL Agent jobs/operator/alert section of the script

✓ Prerequisites — Target (Local / On-Prem SQL Server)

Requirement	Notes
Any SQL Server 2016+ instance reachable from the migration host	Native Windows install, another Docker container, or a VM — all work identically
SQL login with rights to create databases, or the target database pre-created	The wizard auto-creates the target database if it doesn't exist and the login has `dbcreator`
SQL Server Agent running (only if testing the Agent-objects checkbox)	Not required for the base schema+data copy
ODBC Driver 18 for SQL Server installed on the migration host	Bundled with the Endrias Bridge installer

💡

You can leave the Target Database field blank — it now correctly defaults to the source database name (EB_SampleDB) instead of silently landing in whatever database your login defaults to. This applies to the initial migration and to a later "Re-apply Schema Objects" run.

Stand Up the Docker Source

Run a fresh SQL Server 2022 container and load the sample database script into it.

docker run -d --name eb-sqlserver-demo -p 1433:1433 ^
    -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=YourStrong!Passw0rd" ^
    mcr.microsoft.com/mssql/server:2022-latest

REM Wait ~10-15 seconds for the instance to finish starting, then:
sqlcmd -S localhost,1433 -U sa -P "YourStrong!Passw0rd" -C ^
    -i EB_SampleDB_sqlserver.sql

The script is idempotent — safe to re-run against the same container as many times as you want while practicing. It builds EB_SampleDB with all 37 tables across 6 industries, plus the temporal table, SQL Agent objects, Database Mail profile, and SSIS package listed above.

ℹ

Confirm everything loaded before moving on:

sqlcmd -S localhost,1433 -U sa -P "YourStrong!Passw0rd" -C -Q "
SELECT COUNT(*) AS tables FROM EB_SampleDB.sys.tables;
SELECT temporal_type_desc FROM EB_SampleDB.sys.tables WHERE name='products';
SELECT COUNT(*) AS jobs FROM msdb.dbo.sysjobs WHERE name LIKE 'EB_%';
SELECT COUNT(*) AS mail_profiles FROM msdb.dbo.sysmail_profile;
"

Expected: 38 tables (37 + products_history), SYSTEM_VERSIONED_TEMPORAL_TABLE, 3 jobs, 1 mail profile.

Configure Connections

Open Endrias Bridge and fill in Step 5's Source and Target connection fields.

Endrias Bridge — Step 5: Source & Target

SOURCE DATABASE

DB Type

SQL Server 2022

Host/IP

localhost

Port

1433

Database

EB_SampleDB

Username

Password

••••••••••••

TARGET DATABASE

DB Type

SQL Server (your version)

Host/IP

your-local-host

Port

1433

Database

(leave blank — auto-defaults)

Username

your-sql-login

Password

••••••••••••

Test Connection

💡

Click Test Connection on both sides before proceeding — confirms network access and credentials independently of the migration itself.

Run DMF Health Check

From the Tools tab, click Run DMF Scan. Against a fully-loaded sample database, expect exactly these flags — anything else is worth investigating.

[health] Compatibility level ................. OK

[health] Deprecated data types ................ OK

[health] Linked servers ....................... OK (none configured)

[health] Database Mail ........................ ⚠ Found (1 mail profile(s))

[health] SQL Agent operators .................. ⚠ Found (1 operator(s))

[health] SQL Agent alerts ..................... ⚠ Found (1 alert(s))

[health] SSIS packages ......................... ⚠ Found (1 package(s))

ℹ

These four ⚠ flags are the point of the lab, not a problem to fix — they demonstrate the detection working correctly. Database Mail and SSIS stay detect-only regardless of what you do next; the SQL Agent operator/alert flags go away once you migrate them in Step 4.

Load Tables & Set Options

Switch to the Migrate tab, click Load Tables from Source, confirm all 37 tables are checked, and tick the SQL Agent checkbox to include jobs/operator/alert in this run.

Endrias Bridge

Assessment

Migrate

Schema Objects

Tools

Migrate Schema & Data

Select tables and copy schema / data to target database.

Schema + Data

Verify after migration

Also migrate SQL Agent jobs, operators & alerts

Load Tables from Source

Start Migration

⚠

The Agent-objects checkbox is off by default everywhere in the app — it creates server-level objects on the target instance, not scoped to the database being migrated. Turn it on deliberately for this lab.

Start Migration & Monitor

Click Start Migration. Watch for these specific log lines — they confirm the temporal-table and self-referencing-FK handling engaged correctly, not just that the copy finished.

14:02:11 --- Temporal tables: disabling system-versioning on target for 1 table(s) before data copy ---

14:02:11 dbo.products: versioning already OFF — skip

14:02:12 Schema: created 38 table(s)

14:02:14 gov_employees: self-ref FK disabled for bulk copy (FK_gov_employees_supervisor)

14:02:15 gov_employees: self-ref FK re-enabled and validated

14:02:40 --- Full copy: 745 row(s) ---

14:02:44 --- Schema objects: applying 26 view(s)/function(s)/procedure(s)/trigger(s) ---

14:02:45 --- Temporal tables: re-enabling system-versioning for 1 table(s) ---

14:02:45 dbo.products: system-versioning ON (history table: dbo.products_history)

14:02:46 --- SQL Agent objects: migrating 1 operator(s), 1 alert(s), 3 job(s) ---

14:02:46 SQL Agent objects: operators 1/1, alerts 1/1, jobs 3/3

14:02:47 --- Done ---

💡

The self-ref FK disabled for bulk copy /

re-enabled and
          validated

pair on gov_employees is the one to watch for — this is exactly the mechanism that prevents a live FK violation from a child row (e.g. an employee) landing in a different parallel-copy segment than its own parent row (its supervisor).

Verify Results

Post-migration verification runs automatically (if left checked in Step 4). Expect a clean pass on every table, including the temporal table.

14:02:48 --- Post-migration verification ---

14:02:48 [6/38] gov_employees

14:02:48 OK: 15 rows; 15/15 sampled row(s) verified

14:02:49 [26/38] products

14:02:49 OK: 25 rows; 25/25 sampled row(s) verified

14:02:50 --- Verification done ---

ℹ

gov_employees and products are called out deliberately — they're the two tables that exercise the self-referencing-FK and temporal-table fixes respectively. If either shows a row-count mismatch or a "date value out of range" error, the target build predates those fixes.

Re-apply Schema Objects (Idempotency Check)

From the Migrate tab, click Re-apply Schema Objects — this should be safe to run any number of times after a successful migration.

14:05:02 --- Re-applying schema objects ---

14:05:02 Schema objects: applied 26

14:05:03 dbo.products: system-versioning already ON — skip

14:05:03 SQL Agent objects: operators 1/1, alerts 1/1, jobs 3/3

14:05:03 --- Re-apply schema objects: complete ---

💡

Both the SQL Agent objects and the operators/jobs/alerts should log "already exists — skipped" rather than erroring or duplicating — that's the idempotency guarantee working as intended.

⚠ Known Issues & Fixes This Lab Validates

Issue	Details
Self-referencing FK data loss	Fixed — a self-referencing table (like `gov_employees`) used to risk a silent, permanent 1-row loss during parallel copy if the FK-disable guard failed to engage. Step 5's log lines confirm it now runs on every SQL Server target.
Temporal table verification crash	Fixed — a system-versioned temporal table's year-9999 "still open" sentinel used to crash verification with "date value out of range." Step 6 confirms `products` now verifies clean.
Re-apply Schema Objects on a versioned table	Fixed — re-running schema objects against an already-versioned temporal table used to fail outright (error 13592). Step 7 confirms it now skips cleanly instead.
Blank Target Database field	Fixed — leaving Step 5's Database field blank now correctly defaults to the source database's name for both the initial migration and Re-apply Schema Objects, instead of landing in whichever database your login defaults to.
Database Mail / SSIS packages	By design, detect-only. Neither can be fully automated — Database Mail's SMTP password and SSIS packages both require manual handling regardless of migration tool (see the SQL Server Agent operators/alerts note below for the same class of limitation).
SQL Agent operators/alerts on AWS RDS	Not applicable to this lab (target is a plain SQL Server instance, not RDS) — but if you swap the target for RDS, expect operators/alerts to be automatically skipped there; only jobs migrate on RDS. See SOP: SQL Server → AWS RDS.