Endrias Bridge

📖 About This Guide

Endrias Bridge is an enterprise database migration platform for moving relational and NoSQL data between on-premises, cloud, and hybrid environments. It combines a GUI Setup Wizard (for VM initialization and connection setup), a Migration Engine (full/incremental/CDC modes), and a Replication subsystem (CDC Stream and Scheduled Sync) into a single deployable package.

🚀 Installing & Launching

The recommended installation method is the Windows Installer. Double-click MigrationBridge_Setup.exe and follow the prompts. It installs to %ProgramFiles%\Endrias Bridge\, registers an uninstaller in Add/Remove Programs, and creates a desktop shortcut. No Python or additional runtime dependencies are required — the installer is fully self-contained.

1. Windows Installer (recommended for production)

   Run MigrationBridge_Setup.exe as Administrator. After installation completes, launch from the Endrias Bridge shortcut in the Start Menu or Desktop.

2. Desktop shortcut (source install)

   If install_shortcut.py was run after source extraction, double-click the Endrias Bridge shortcut. Shortcut targets launch_gui.pyw with no console window.

3. Launch script

   Double-click launch_gui.pyw in the install folder (opens silently — no console window attached).

4. Command line / headless

   Open PowerShell in C:\MigrationTool and run MigrationBridge.exe gui to open the GUI, or use the migrate subcommand to run a full headless migration without opening any window — see the CLI Headless Mode section for full details and flag reference.

5. Docker (Linux / cloud-native)

   Use the included Dockerfile and docker-compose.yml. ODBC Driver 17 is installed automatically in the container image. Mount migrationbridge.conf as read-only and ./migration_state for checkpoint persistence. Run: docker compose up migration. Dashboard available at http://localhost:8765.

1️⃣ Step 1 — Welcome

The Welcome screen summarizes what the wizard will execute on this VM: set hostname, create a local user, configure networking, inject SSH keys, and run userdata scripts — plus any additional plugins enabled in Step 4. It also shows the current Endrias Bridge version and the effective config file path.

2️⃣ Step 2 — Metadata Source

Choose where Endrias Bridge should read VM metadata from at boot time.

Below the options, set the HTTP base URL (for OpenStack HTTP), and the retry count / interval used when probing a metadata endpoint.

3️⃣ Step 3 — User Settings

Configure the local Windows account that Endrias Bridge creates on first boot.

4️⃣ Step 4 — Plugins

Choose which guest-initialization tasks run on this VM. Use Select All / Clear All to quickly toggle everything.

5️⃣ Step 5 — DB Migration 🕙 Typically 2–3 min to configure

This step configures the source and target servers/databases for a database migration, and provides access to the full Endrias Bridge. If this VM only needs guest initialization, check Skip migration setup and continue to Review.

Each Server / Database block has a Test Connection button — use it to confirm credentials and reachability before opening the Endrias Bridge.

6️⃣ Step 6 — Review

A scrollable summary of every choice made so far, grouped by section:

7️⃣ Step 7 — Run

Click Run to apply the configuration. A live, color-coded log streams into the window as Endrias Bridge executes each plugin:

✅ Pre-Flight Connectivity Check

When you click Run Migration, Endrias Bridge automatically executes a 3-step pre-flight check before any data movement begins. The check validates connectivity, permissions, and CDC eligibility. Results appear at the top of the migration log.

Pre-Flight Steps

Example Pre-Flight Log Output

Common Pre-Flight Failures and Remediation

🔎 Connection String Debug Panel

On Step 5, a collapsible Show connection string control (collapsed by default) displays the exact ODBC connection string that Endrias Bridge constructs from the current field values. The password field is masked as ****. A Copy button copies the string to the clipboard.

Example Debug Output

Common Uses

• Paste the string into sqlcmd or a Python script to isolate whether the failure is in Endrias Bridge or in the underlying ODBC driver.
• Verify that Encrypt=yes is present for Azure SQL and AWS RDS connections (required; connection will fail if absent).
• Confirm the SERVER value matches the AG listener DNS name or RDS endpoint when connecting through HA topology (see Multi-AZ / HA section).
• Verify Authentication=ActiveDirectoryPassword or ActiveDirectoryInteractive is present when using Azure AD authentication.

💾 Connection Profiles

The Source Database and Target Database blocks in Step 5 each have a Connection profile row, similar to saved connections in Azure Data Studio.

1. Save As...

   Fill in DB Type, Host, Port, Database, Username (and optionally Password), then click Save As... and provide a profile name. You will be prompted whether to store the password in the Windows Credential Manager.

2. Load

   Pick a saved profile from the dropdown and click Load to populate DB Type, Host, Port, Database, Username, and Password (if saved).

3. Delete

   Select a profile from the dropdown and click Delete to remove it permanently (confirmation dialog shown).

🔎 Assessment Tab

Open the Endrias Bridge from Step 5, then click Run Assessment. This connects to the source database, lists its objects in the Source Objects tree (with row counts), and compares the source/target engine pair against the compatibility matrix in the Compatibility Issues panel.

Data Type Conversions

When source and target are different engines, the Compatibility Issues panel also lists a Data type conversions section — a column-by-column report of source types that do not exist on the target and what they become:

🔄 Migration Tab

Migrate schema and/or data from the source to the target database.

When to Use Which Sync Mode

1. Choose what to migrate

   Select Migrate schema (CREATE TABLE) and/or Migrate data (INSERT rows) — both are enabled by default. Uncheck schema to do a data-only refresh into an existing target schema.

   The third checkbox — Verify after migration (row counts + checksums) — is also enabled by default. When checked, immediately after all data is copied the tool runs a post-migration integrity check for every table: it compares COUNT(*) on source vs target, then samples up to 200 rows (ordered by PK) and computes an MD5 checksum of each row's columns. Mismatches, missing rows, and row count differences are listed in the log and included in the exported report. Uncheck it to skip verification and shorten total run time on very large databases (you can always run Verify Data Integrity manually later).

2. Choose a sync mode

   Full copy — truncate and recreate, then copy all rows. Automatically uses BCP bulk export + BULK INSERT when bcp.exe is on PATH, falling back to PK-range copy otherwise. Indexes are disabled before load and rebuilt after (2–4x faster INSERT). Incremental — copy only rows newer than the last run, using a watermark column per table. CDC — single-pass apply of changes since last run via SQL Server native CDC. CDC Stream — continuous near-real-time replication, polling the transaction log LSN every 250 ms, applying changes within < 1 second. Runs until you click Stop Stream. Requires CDC enabled on source DB and each tracked table. CT Sync — delta sync using SQL Server Change Tracking (see section below).

3. Load Tables from Source

   Populates the table list on the left with all user tables. Check the tables to migrate. Use the filter box to search by name in large schemas.

4. Start Migration

   Creates the target database if it does not exist, then copies schema and data in batches (default 100,000 rows; set db_migration_chunk_size in migrationbridge.conf to adjust). For LOB-heavy tables (nvarchar(max), varbinary(max), xml) the chunk size is automatically reduced to keep each batch under 256 MB — preventing out-of-memory errors on wide-row tables. For same-engine migrations, procedures / views / triggers / functions are applied to the target automatically. If any table's DDL is rejected by the target, schema creation retries table-by-table so a single unmapped type does not roll back the entire schema.

5. Parallel copy lanes (large vs. small tables)

   Two controls: Table concurrency (default 4 workers) and Large table threshold (default 10,000,000 rows). Tables below the threshold run concurrently in the fast lane so small lookup/reference tables complete without waiting for billion-row fact tables. Tables at or above the threshold run sequentially in the slow lane after the fast lane finishes. Set concurrency to 1 when resuming a large interrupted migration to avoid checkpoint collisions.

6. PK-range checkpoint seeding with transient-error auto-retry

   Every table with a single INTEGER or BIGINT primary key uses PK-range seeding instead of OFFSET paging. After every committed batch the last PK value is saved to migrationbridge_sync_state.json. If the migration is interrupted (network drop, OS sleep, crash), clicking Resume Migration continues from the exact last committed PK — no rows are deleted, no progress is lost.

   Transient TCP errors (Azure SQL connection resets, error 10054 / 08S01) are automatically retried up to 5 times per batch with exponential back-off (5 s → 15 s → 30 s → 60 s → 120 s). The connection pool is flushed between attempts so a fresh TCP connection is always used.

   The progress bar and ETA on Resume reflect the full database — row counts from skipped (already-complete) tables are included so the bar starts at the correct percentage (e.g. ~80% if 80% of rows are already on the target).

7. Index disable / rebuild for faster bulk INSERT

   Before data copy begins, all non-clustered non-unique indexes on the target tables are automatically disabled (SQL Server targets) or dropped (PostgreSQL / MySQL targets). This removes per-row B-tree maintenance overhead during INSERT — typically 2–4x faster for large tables. Indexes are rebuilt / recreated automatically in a single pass after all rows are loaded. The clustered index (PK) and unique indexes are never touched. Watch the log for [idx] DISABLED and [idx] REBUILT lines.

8. Keeping the VM active during migration

   For long-running migrations, prevent the staging VM from sleeping or signing out. Run the following in an Administrator Command Prompt before starting:

   powercfg /change standby-timeout-ac 0
powercfg /change monitor-timeout-ac 0

   If connecting via RDP, use tscon <sessionid> /dest:console to detach without logging off — the migration process stays alive. Restore sleep settings after migration completes.

CT Sync — SQL Server Change Tracking

Change Tracking (CT) is a lighter-weight alternative to CDC. Instead of recording old column values in the transaction log, CT records only which rows changed (PK + operation: Insert / Update / Delete). This means:

• Lower overhead on the source — no log reader agent, no log growth
• Works on Azure SQL Database, AWS RDS for SQL Server, and on-premises SQL Server 2016+
• Does not capture old values — use CDC if you need before-images
• Retention is configurable (default 5 days); syncs older than CHANGE_RETENTION require a reseed

Prerequisites

Run the following T-SQL on the source database before selecting CT Sync mode:

-- Enable Change Tracking on the database (5-day retention)
ALTER DATABASE [YourDatabase]
SET CHANGE_TRACKING = ON (CHANGE_RETENTION = 5 DAYS, AUTO_CLEANUP = ON);

-- Enable on each table you want to track
ALTER TABLE [dbo].[YourTable]
ENABLE CHANGE_TRACKING WITH (TRACK_COLUMNS_UPDATED = OFF);

To verify CT is on:

-- Database-level
SELECT name, is_change_tracking_on FROM sys.databases WHERE database_id = DB_ID();

-- Table-level
SELECT s.name + '.' + t.name AS tbl, ct.min_valid_version
FROM sys.change_tracking_tables ct
JOIN sys.tables  t ON ct.object_id = t.object_id
JOIN sys.schemas s ON t.schema_id  = s.schema_id;

Typical Workflow

1. Perform a Full copy migration first (schema + data) — CT Sync does not copy initial data.
2. Switch sync mode to CT Sync and click Start Migration to apply deltas since the last known CT version.
3. Repeat periodically (scheduled task, CI/CD pipeline, or manually) to keep the target current.
4. At cutover: do one final CT Sync, quiesce writes to the source, do a last CT Sync, then switch the application to the target.

CLI Headless Mode — Pipeline & Automation

Run migrations without opening the GUI — ideal for Azure DevOps pipelines, PowerShell scripts, and nightly jobs. The migrate subcommand accepts the same connection, table, and mode options as the GUI.

Basic syntax

MigrationBridge.exe migrate ^
    --src-host myazure.database.windows.net ^
    --src-db   MyDB ^
    --src-user sa ^
    --src-pass MyP@ssword ^
    --src-type "Azure SQL Database" ^
    --tgt-host myrds.rds.amazonaws.com ^
    --tgt-db   MyDB ^
    --tgt-user admin ^
    --tgt-pass MyP@ssword ^
    --tgt-type "AWS RDS for SQL Server" ^
    --mode full ^
    --verify ^
    --report   C:\Reports\MyDB_migration.html

Available flags

Exit codes

Azure DevOps pipeline snippet

- task: PowerShell@2
  displayName: 'Migrate MyDB to RDS'
  inputs:
    targetType: inline
    script: |
      & 'C:\MigrationTool\MigrationBridge.exe' migrate `
        --src-host $(SRC_HOST)  --src-db $(SRC_DB) `
        --src-user $(SRC_USER)  --src-pass $(SRC_PASS) `
        --src-type "Azure SQL Database" `
        --tgt-host $(TGT_HOST)  --tgt-db $(TGT_DB) `
        --tgt-user $(TGT_USER)  --tgt-pass $(TGT_PASS) `
        --tgt-type "AWS RDS for SQL Server" `
        --mode full --verify `
        --report $(Build.ArtifactStagingDirectory)\migration_report.html
      if ($LASTEXITCODE -ne 0) { throw "Migration failed" }

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'migration-report'

Phase 3 Features

1. Parallel streams per large table

   The Parallel streams per large table spinbox (default: 1) splits a table's primary key range into N segments copied simultaneously. Set to 4 for tables between 400 M and 1 B rows, or 8 for 1 B+ row tables. Each segment has its own checkpoint — if interrupted, only the affected segment resumes. Leave at 1 to use BCP (fastest for smaller tables). Available for any source/target pair with a single integer PK.

2. Type mapping overrides (migrationbridge.conf)

   Add a [type_overrides] section to override how specific source column types map to the target:

   [type_overrides]
   geography        = NVARCHAR(4000)
   uniqueidentifier = VARCHAR(36)
   xml              = TEXT

   Overrides apply before all built-in rules. Restart the tool after editing the file to clear the internal type cache.

3. Azure SQL → AWS RDS: sysname columns

   Azure SQL allows user tables to have columns of type sysname (a system alias for nvarchar(128)). AWS RDS does not permit user-created sysname columns. The migration tool automatically remaps these to NVARCHAR(128) before emitting DDL — no manual action required.

4. System-versioned temporal tables

   Temporal tables and their history tables always migrate as plain tables — all row data comes across. What happens to system-versioning after migration depends on the target engine:

   • SQL Server / Azure SQL target — system-versioning is re-enabled automatically after data copy. Reported in the log as system-versioning ON. If the target already had versioning ON from a prior run, it is turned OFF before the copy and re-enabled after.
   • Oracle 23ai+ target — the Schema Objects tab generates an ALTER TABLE … ADD PERIOD FOR SYSTEM_TIME … ADD VERSIONING USE HISTORY TABLE script. Run this after migration to wire up the already-migrated history table.
   • Oracle 11g R2–21c target — the Schema Objects tab generates a Flashback Data Archive (FDA) script. Run it after migration to enable automatic history tracking going forward.
   • PostgreSQL / MySQL target — the Schema Objects tab generates a trigger-based emulation pattern. No native system-versioning equivalent exists on these engines.

   Period columns (SysStart, SysEnd, ValidFrom, ValidTo) are migrated as plain TIMESTAMP / DATETIME2 columns on non–SQL Server targets. The migration log flags each one with a pointer to the Schema Objects tab.

5. Azure SQL → AWS RDS: DateTime.MaxValue / DateTime.MinValue

   SQL Server applications often store 9999-12-31 23:59:59.9999999 (DateTime.MaxValue) as a "never expires" sentinel. ODBC Driver 17's fast_executemany batch path cannot bind fractional-second values at the 9999-12-31 boundary (error 22007). The tool automatically clamps these to 9999-12-31 23:59:59.000000. Similarly, DateTime.MinValue (0001-01-01) is clamped to 1753-01-01 for legacy datetime columns.

6. Self-referential FK constraints

   Tables where a column references the primary key of the same table cannot be bulk-copied while the FK constraint is active — parent rows may not yet exist when a child row in the same batch is inserted. The tool automatically detects self-referential FKs, disables them on the target before copying, and re-enables them with validation after all rows are present.

7. Multi-schema databases with identically-named tables

   Databases with the same table name in multiple schemas (e.g. errordata.ClaimHeader and historydata.ClaimHeader) now use schema-qualified keys (schema.name) throughout the FK wave scheduler, table_totals, _est_rows, and copy engine dictionaries. No configuration change required — the fix is automatic.

8. Spatial column export (geography / geometry)

   SQL Server geography and geometry columns are automatically exported as WKT (Well-Known Text) strings using .STAsText(). Raw WKB bytes returned by some ODBC driver versions are hex-encoded. No additional configuration required.

9. MongoDB & Azure Cosmos DB (MongoDB API) source / target

   Install pymongo (pip install pymongo) to migrate MongoDB collections or Azure Cosmos DB databases. Select MongoDB or Cosmos DB as the engine type. For Cosmos DB, enter your account hostname (<account>.mongo.cosmos.azure.com), port 10255, account name as username, and primary key as password. SQL Server columns typed as hierarchyid or geography are automatically skipped with a per-table log message. Supports Atlas, on-premises, and Cosmos DB MongoDB API. Do not install azure-cosmos — this tool uses the MongoDB wire protocol exclusively.

10. Amazon DynamoDB source

    Install boto3 (pip install boto3) to migrate DynamoDB tables to any relational target. Provide AWS region and credentials on the source screen. The tool paginates through the full table scan and infers schema from item samples. Supports IAM roles, environment variable credentials, and DynamoDB Local for testing.

11. Live web dashboard

    Install fastapi and uvicorn (pip install fastapi "uvicorn[standard]") to enable the built-in web dashboard. When a migration starts, open http://localhost:8765 in any browser to see live progress, per-table status bars, and a color-coded log panel — without RDP access to the staging VM. The dashboard auto-refreshes every 2 seconds. The REST endpoint GET /api/status can be polled by CI/CD pipelines to await migration completion.

12. Docker / headless deployment

    Run Endrias Bridge in a Docker container for Linux or cloud-native deployments. The included Dockerfile and docker-compose.yml install the Microsoft ODBC driver automatically. Mount migrationbridge.conf as read-only and ./migration_state for checkpoint persistence:

    docker compose up migration
    # Dashboard: http://localhost:8765

    In Docker, bcp.exe is unavailable (Windows-only) — set Parallel streams to 4–8 for best throughput.

📄 Jobs Tab — Concurrent Multi-DB Migration

The Jobs tab (also called Migration Projects) is designed for bulk migrations where several source databases need to be moved at the same time — for example, migrating a fleet of tenant databases to a new RDS instance.

Step-by-Step

1. Configure a default Source and Target connection on Step 5 of the wizard (these become the defaults for every job). Opening Migration Projects from Step 5 pre-fills all credential fields automatically.
2. Open the Jobs tab.
3. Click + Add Job for each database you want to migrate. Each row shows:
   • Source DB — the database name on the source server
   • Target DB — the database name on the target (can differ from source)
   • Target Override — optionally point this job at a different target server
   • Status — Pending / Running / Done / Error
4. In the Map Targets step (Step 3), verify the "Auto-create target database if it does not exist" checkbox. This is checked by default and is recommended for RDS and Azure SQL Database targets — the engine issues CREATE DATABASE automatically before migration, so the database does not need to be pre-provisioned.
5. Set Concurrency (1–10) — how many jobs run at the same time. Start with 2–3 to avoid saturating the network.
6. Click Run All. Each job bar shows live row counts and percentage. The engine performs real schema + data migration: SQLAlchemy reflection, CREATE TABLE DDL, 10,000-row chunk copy with live progress, and FK constraint application after all tables are loaded.
7. Use Stop to abort all running jobs cleanly.
8. When finished, click Export Combined Report to save a CSV summarising all jobs: rows copied, errors, duration.

Auto-Create Target Database

Migration Projects automatically creates the target database before migration begins — no manual pre-provisioning is required. The engine issues CREATE DATABASE [name] on the target server. If the database already exists the command is silently skipped. This is the default behavior for all AWS RDS and Azure SQL Database targets.

📊 Health Monitor Tab — Live Migration Dashboard

The Health tab (labelled 📊 Health in the tab bar) is the first tab and is always visible. It updates live during migrations and retains final totals after a run completes. The entire tab body is scrollable — use the mousewheel to scroll all panels.

Stat Cards (Row 1)

Stat Cards (Row 2)

Live Table Dashboard

The table tree below the KPI cards shows one row per table with the following columns:

Middle Panel

Throughput Sparkline

Rows/sec over the last 60 seconds plotted as a line chart. Shows peak, average, and sample count. Updates every second.

Chart Hover Tooltips

All five chart canvases — Throughput, CPU %, Memory %, Net MB/s, and Disk MB/s — show a floating tooltip when the cursor hovers over the chart area. The tooltip displays the exact HH:MM:SS timestamp and the metric value at the hovered sample point (e.g. 14:32:07 — 847 rows/s or 14:32:07 — CPU 72%). A dashed vertical crosshair line tracks the cursor position. The tooltip disappears automatically when the cursor leaves the chart canvas.

System Resources Panel

Four live sparkline charts for the staging machine (requires psutil — installed automatically):

Disk Space Bar (Top of Tab)

Always-visible row beneath the header showing free / total GB for both source and target connections. Refreshes every 30 seconds automatically; the ↻ button triggers an immediate refresh.

Disk Warning Banner

A banner appears automatically above the stat cards when target disk space is low:

Status Badge

The badge in the header bar shows: ● Idle (no migration running), ● Running (green, migration active), or ● Finished (blue, last run complete).

🔁 Replication Tab

The Replication tab is a dedicated panel for ongoing data synchronization, separate from the one-time (or resumed) migration workflow on the Migration tab. It supports two modes:

Per-Table Dashboard

The Replication tab displays a live per-table dashboard showing:

Schema Drift Alerts

If a column is added to or removed from a source table while the CDC stream is running, the affected table is automatically suspended and a WARN alert is logged. All other tables in the stream continue uninterrupted. To re-enable: stop the stream, apply the matching DDL change to the target, then restart the stream.

Sync History Log

The Replication tab maintains a scrollable sync history log showing each batch apply event with timestamp, table name, row count, LSN range (for CDC), and duration. The log persists to migration_logs\replication_<db>_<date>.log for post-incident analysis.

📄 Replicas Tab — Read Replica Manager

The Replicas tab is split into two sub-panels: AWS RDS and Azure SQL. Both require optional SDK packages (installed once):

pip install boto3                          # AWS RDS panel
pip install azure-mgmt-sql azure-identity  # Azure SQL panel
# or install both:
pip install migrationbridge[all]

AWS RDS Panel

Leave Access Key / Secret Key blank to use the standard boto3 credential chain (environment variables, ~/.aws/credentials, or EC2 instance role).

Azure SQL Panel

Leave Tenant / Client ID / Secret blank to use DefaultAzureCredential (Azure CLI, environment variables, managed identity). For automation, provide a Service Principal with the minimum roles above.

☁ Export & Cloud Tab

The Export & Cloud tab appears between Replicas and Error Log in the tab bar. Each destination is a self-contained card with its own fields and status line. All exports run in a background thread — the UI stays responsive while the export runs.

1 — Amazon S3 Export (Parquet / CSV / JSON)

Exports every source table to an S3 bucket in Parquet, CSV, or JSON format. Uses pyarrow for Parquet encoding. Supports partition-by-column (e.g. partition by year to create s3://bucket/table/year=2024/data.parquet sub-paths).

Install: pip install boto3 pandas pyarrow

2 — Amazon Redshift Replication

Copies source tables into Amazon Redshift. Schema is auto-converted: NVARCHAR → VARCHAR, DATETIME → TIMESTAMP, UNIQUEIDENTIFIER → CHAR(36). Tables are created or replaced on each run.

Install: pip install sqlalchemy-redshift psycopg2 pandas

3 — Azure Event Hubs Streaming Sink

Streams every row from every source table as a JSON change event to an Azure Event Hub. Each event has the schema: { "op": "I", "table": "OrderHeader", "row": { "id": 1, ... } }. Designed to work alongside the Replication tab CDC stream — use for downstream consumers (Databricks, Stream Analytics, Azure Functions).

Install: pip install azure-eventhub

4 — Azure Blob Storage Export

Exports source tables to Azure Blob Storage as Parquet, CSV, or JSON. Streams row batches directly to blob blocks — no local temp files. Supports SAS token or DefaultAzureCredential (Azure CLI login, managed identity, environment variables).

Install: pip install azure-storage-blob pandas pyarrow

5 — Zero-ETL Direct Load (Snowflake · BigQuery · Aurora PostgreSQL)

Loads source tables directly into a cloud analytics platform with no staging files. Schema is auto-detected and tables are created or replaced on each run. All source tables are loaded in sequence; status updates inline per table.

6 — AI-Assisted Schema Compatibility Analysis

Scans up to 20 source tables and sends the schema metadata to Claude Haiku (Anthropic AI) for compatibility analysis. The AI returns a scored report for each table covering incompatible types, unsupported features, and recommended migration actions. Results open in a popup window.

Install: pip install anthropic

API Key: Set ANTHROPIC_API_KEY as an environment variable, or paste it directly into the field. Get a key at console.anthropic.com.

The analysis report includes:

• Incompatible column types per table with recommended replacements
• Unsupported features (computed columns, IDENTITY, temporal tables, rowversion, etc.)
• Compatibility score 0–100 per table
• Top 3 recommended actions before migrating each table

Azure SDK — Install Notice

The Azure SQL DB and Azure SQL MI sub-tabs in the Replicas tab, and the Azure Blob / Azure Event Hubs destinations in the Export tab, all require the Azure SDK. If not installed, a highlighted amber panel is shown:

Azure SDK not installed
Install the required packages, then restart Endrias Bridge:
    pip install azure-mgmt-sql azure-identity

Run the command in a terminal, then restart Endrias Bridge. The panel is replaced with a green Azure SDK ready badge once the packages are detected.

🧩 Schema Objects Tab

Lists stored procedures, views, triggers, functions, table types, temporal tables, and SQL Agent jobs on the source database.

👤 Users & Logins Tab

Summary Banner

After scanning, a summary banner appears at the top showing:

Users Found: 35  ·  ✅ Ready: 31  ·  ⚠ Manual: 3  ·  ❌ Unsupported: 1

User Types & Migration Status

Toolbar Buttons

Filter Bar

Filter the user list by Type (SQL User, Azure AD User, Windows User, Contained User, External Group) and/or Status (Ready, Manual Action Required, Unsupported). Filters apply live as you change the dropdowns.

Compare with Target Tab

After clicking Compare with Target, the right-hand Compare tab populates with a side-by-side view:

Azure AD Warning

🔎 Comparison Tab — Source ↔ Target Diff

Use the Comparison tab after a migration to verify that the target is structurally and data-wise identical to the source, or to detect schema drift during ongoing replication.

Step-by-Step

1. Connect both source and target on Step 5 of the wizard.
2. Open the Comparison tab.
3. Click Run Comparison. The engine queries both databases concurrently and builds a diff report.
4. Use the Show filter bar to narrow results:
   • All — every object and attribute
   • Match — identical on both sides (green rows)
   • Mismatch — present on both sides but different (red rows)
   • Source only — exists on source but not target (amber rows)
   • Target only — exists on target but not source (blue rows)
5. Click any row to inspect the Source value vs Target value.
6. Click Export to .csv to save the full diff for change management records.

Comparison Categories

🔨 Tools Tab

Shows which migration tools are available on this machine and provides the Configuration Health Check utility:

📋 Configuration Health Check

Available from the Tools tab. Click Run Configuration Health Check to validate the full deployment configuration before starting a migration. The check runs 8 automated verifications and reports each result with a specific remediation step if it fails.

Health Check Verifications

Sample Health Check Output

🏠 Multi-AZ / High Availability Topologies

Endrias Bridge supports high-availability migration architectures for both source and target databases. The key principle: always connect via the listener DNS name or managed endpoint rather than the individual instance name — this ensures Endrias Bridge follows a failover transparently without manual intervention.

HA Topology Support Matrix

Source HA: Reading from Always On AG or RDS Multi-AZ

Endrias Bridge reads from the primary replica only — it does not split reads across replicas or use the readable secondary. For Always On AGs, use the AG listener DNS name as the Host/IP in Step 5. For RDS Multi-AZ, use the RDS cluster endpoint.

Target HA: Migrating to an AG Primary or RDS Multi-AZ

Migrate to the primary replica of the target AG or RDS Multi-AZ deployment. The secondary automatically receives the same rows via SQL Server native replication (AG) or RDS-managed replication (Multi-AZ) — there is no need to separately seed the secondary.

Read Replica Seeding

After the initial migration, point CDC Stream at the target primary. The AG secondary or RDS Multi-AZ standby receives the same changes via SQL Server replication — no separate seeding step is required for the secondary replica.

Architecture Recommendation: Network Placement

📋 Logs & Error Logs

Every run writes to two locations in addition to the live log shown in Step 7:

1. Open Error Log Folder

   On the Run step (Step 7), click Open Error Log Folder to open C:\Endrias Bridge\ErrorLogs in File Explorer and inspect errors.log.

2. Change the log locations

   Edit log_file and error_log_dir in migrationbridge.conf to write logs to a different path — useful for centralized log collection on a shared drive or forwarding to a SIEM.

💻 Hardware & Sizing Recommendations

Recommended specifications for the machine running Endrias Bridge (the "staging" host), based on source database size:

Network Topology Guidance

Staging host network placement has a significant impact on migration throughput and cost:

• Same region, same VNet/VPC (recommended): Sub-millisecond latency between staging host, source, and target. No cross-region egress charges. For a 1 TB database, cross-region egress at $0.09/GB would add ~$93 in data transfer costs; same-region is free or negligible.
• Source and target in different regions: Place the staging host in the source's region for the initial full copy (minimize source-to-staging latency), then move or spin up a second staging host in the target region for CDC streaming (minimize staging-to-target latency during the cut-over window).
• Use Windows Server 2022 for the migration/staging VM where possible — it includes the latest ODBC drivers and PowerShell version.
• For large migrations, use a dedicated VM with no other workloads running during the migration window.

🛠 Phase 4 — Hardening Features

These changes ship in Phase 4 and require no GUI interaction — they are enabled via migrationbridge.conf or activate automatically.

Index Disable/Rebuild for PostgreSQL & MySQL (Change 23)

When copying data to a PostgreSQL or MySQL target, the tool now automatically drops non-unique secondary indexes before bulk INSERT and recreates them after. This provides the same 2–4x INSERT speedup that SQL Server targets already had. No configuration required — it is automatic for PostgreSQL and MySQL targets.

Per-Table Chunk Size Override (Change 24)

Add a [chunk_overrides] section to migrationbridge.conf to set an exact row batch size for specific tables. Useful for very wide tables that cause out-of-memory errors at the global chunk size, or narrow lookup tables that run faster with larger batches:

[chunk_overrides]
BigLobTable          = 500
AggregateLineFact    = 200000

Oracle Instant Client Guidance (Change 25)

When Oracle is selected as a source or target engine, the tool now checks for the required driver package before attempting a connection and shows clear step-by-step installation instructions if it is missing, rather than a cryptic DPI-1047 error. The instructions reference the correct Instant Client version for the target Oracle server version.

CDC Lag Rate Alert (Change 26)

In CDC Stream mode, the tool computes a rolling change rate (changes/second over the last 60 seconds) and logs a warning if the source is producing changes faster than the target can apply them. The rate is displayed on every cycle line in the Replication tab log: rate=127/s. If sustained above target capacity, scale up the staging host or reduce concurrency of competing workloads.

CDC Schema Drift Detection (Change 27)

If a column is added to or removed from a source table while the CDC stream is running, the affected table is automatically suspended and a warning is logged. All other tables in the stream continue uninterrupted. To re-enable a suspended table: stop the stream, apply the matching DDL change to the target, then restart the stream. The schema drift event is recorded in the replication log with the table name, column name, and change type (ADD / DROP).