Endrias Bridge Documentation

📖 Overview

Endrias Bridge is two tools in one install. Both are reachable from the same Setup Wizard at C:\MigrationTool.

Documentation Index

Deep-dive guides for each part of the tool:

Engine-Pair SOPs

Standalone runbooks for each supported migration path — validated row counts, live migration setup, type conversion tables, and known issues per engine pair.

🎯 Use Cases

🚀 Quick Start

1. Install

   Run MigrationBridge_Setup.exe, or use the per-user shortcut installer (install_shortcut.py). Both place a Endrias Bridge shortcut on the Desktop and Start Menu.

2. Launch the Setup Wizard

   Double-click the shortcut, or run launch_gui.pyw. The wizard opens on Step 1 (Welcome).

3. Open the Endrias Bridge

   From Step 5 (DB Migration) enter your source and target connection details, then click Open Endrias Bridge.

4. Run an Assessment

   On the Assessment tab click Run Assessment to discover tables/views, compatibility issues, automatic data type conversions, and the recommended staging hardware tier.

5. Migrate

   On the Migration tab, load tables, pick a sync mode (Full / Incremental / CDC), and click Start Migration. Progress, throughput, and an ETA are shown live.

✅ Prerequisites

• Windows 10/11 or Windows Server 2016+ to run Endrias Bridge itself.
• Network connectivity (TCP) from the machine running Endrias Bridge to both the source and target database.
• A database account on the source with read access to the tables/schema being migrated.
• A database account on the target with permission to create schema objects and insert data.
• For SQL Server CDC sync: SQL Server Agent running, and an account that can execute sys.sp_cdc_enable_db / sys.sp_cdc_enable_table.

Database drivers

Endrias Bridge connects via SQLAlchemy. Each engine needs its driver available on the machine running Endrias Bridge:

🧭 Migration Scenarios

Common source → target pairs and the recommended starting point. All pairs benefit from running Assessment first.

🔁 Sync Mode Comparison

🤖 CLI Headless Mode New v75

Run any migration from the command line — no GUI window required. Useful for Azure DevOps pipelines, PowerShell scripts, Windows Task Scheduler, and Docker containers.

MigrationBridge migrate \
  --src-type azuresql --src-host SERVER.database.windows.net --src-db SOURCE \
  --src-user user     --src-pass pass \
  --tgt-type rds      --tgt-host rds.xxxx.rds.amazonaws.com  --tgt-db TARGET \
  --tgt-user user     --tgt-pass pass \
  --mode full --schema --data --verify --report report.html

Exit code 0 = success (all tables migrated and verified). Exit code 1 = one or more errors. Use $LASTEXITCODE in PowerShell to gate pipeline stages.

See SOP → CLI Headless Mode for the full flag reference and Azure DevOps YAML example.

🧩 Endrias Bridge Tabs

🗂️ Supported Versions

🚧 Limitations

• CDC sync mode is available for SQL Server sources only; other engines use Incremental (watermark column) sync instead.
• Incremental sync requires every migrated table to have a watermark column (e.g. updated_at, RowVersion) and a primary key.
• SQLite as a target supports Full copy only — Incremental and CDC sync are not available.
• Sync is one-directional (source → target) — bi-directional / multi-master replication is not supported.
• Stored procedures, views, triggers, and functions are migrated automatically when the source and target are the same engine (e.g. SQL Server → SQL Server / Azure SQL, MySQL → MySQL, PostgreSQL → PostgreSQL). Across different engines they are not auto-translated (T-SQL ≠ PL/pgSQL ≠ PL/SQL); the Schema Objects tab exports them for manual review and rewrite.
• Oracle BFILE columns migrate the file path only — the referenced file's contents are not copied.

📋 Release Notes & Upgrading

June 2026

• Fix: Temporal table system-versioning crash — _copy_schema_objects was missing a from sqlalchemy import text import, causing a NameError on the ALTER TABLE … SYSTEM_VERSIONING = ON step for every temporal table. All temporal tables now have system-versioning re-enabled automatically after migration.
• Fix: CDC/DMS system tables processed during Resume — The resume row-count loop now skips cdc.*, *_CT, attrep_*, _attrep_*, and systranschemas entries. Previously these appeared in old unpatched table selections and caused Invalid object name errors during resume.
• Fix: "Converting decimal loses precision" not retried — The batch-error retry path (which previously only handled string truncation) now also catches 'loses precision' and 'converting decimal' errors thrown by pyodbc fast_executemany. Affected batches are retried row-by-row on a non-fast_executemany connection so all decimal rows land correctly.
• Fix: Sequences not created on Resume / data-only runs — ensure_sequences_exist was called only inside if do_schema:, so resume and data-only passes skipped it. Sequence creation now runs before the data copy on all paths when the target is SQL Server family.
• Azure SQL → AWS RDS DDL compatibility conversions — json columns, NullType columns (including hierarchyid / spatial types), decimal precision above 38, and Azure-only server-side defaults (getutcdate(), newsequentialid(), etc.) are automatically rewritten before CREATE TABLE — see Azure SQL → AWS RDS Compatibility.
• Fix: "Not Responding" on large databases — The UI queue was flooded with a progress message on every single batch, and the _log widget called .index() on every single log line (an expensive Tk operation). Progress messages are now emitted every 10 batches and the line-count trim runs every 50 log calls instead of every call. Eliminates the Tkinter freeze on large databases such as acme_erp (200+ tables).
• Feature: Email alerts on migration failure or completion — Configure SMTP credentials in migrationbridge.conf [alerts] to receive an HTML email when a table errors, the migration crashes (FATAL), or the migration completes. Disabled by default (leave smtp_host blank). Supports Office 365 / STARTTLS (port 587) and SSL (port 465).
• Migration tab table list — table name column is wider with a horizontal scrollbar so long fully-qualified names (e.g. salesdata.ProviderRateMatrix) are fully readable.
• CDC/DMS table exclusion on Load Tables — Load Tables now filters cdc.*, *_CT, attrep_*, and systranschemas out of the table list automatically.

a previous build

• Initial release: Setup Wizard (guest initialization) and DB Migration Assistant.
• Assessment, Migration, Schema Objects, Tools, Connection Profiles, and Logs tabs.
• Full, Incremental, and SQL Server CDC sync modes with live progress, ETA, and throughput.
• Automatic data type conversion and compatibility matrix across SQL Server, PostgreSQL, MySQL, Oracle, and SQLite.
• Hardware/VM sizing recommendations and a Windows installer (MigrationBridge_Setup.exe).

Upgrading

Download and run the latest MigrationBridge_Setup.exe over an existing installation — it updates the application files in place. Connection profiles (%APPDATA%\Endrias Bridge\connection_profiles.json) and error logs (C:\Endrias Bridge\ErrorLogs) live outside the install directory and are preserved across upgrades.

☁️ Azure SQL → AWS RDS DDL Compatibility

Azure SQL Database and AWS RDS for SQL Server are both SQL Server family engines, so Endrias Bridge applies their DDL directly — no cross-engine type rewrite. However, Azure SQL exposes certain types and schema artifacts that are not valid on AWS RDS. These are automatically rewritten by retype_azure_for_rds during schema creation, with a note line in the migration log for each affected column.

⚡ Change Data Capture (CDC) Replication

SQL Server CDC is Endrias Bridge's most advanced sync mode: it continuously replicates inserts, updates, and deletes from a SQL Server source to any supported target — a continuous copy / replication relationship built directly into the Migration tab.

How it works

• The Migration tab calls sys.sp_cdc_enable_db and sys.sp_cdc_enable_table on the source (if not already enabled) so SQL Server begins recording changes in CDC capture tables.
• Each sync pass reads only the rows that changed since the last run (tracked via the CDC log sequence number), and applies inserts, updates, and deletes to the target in the same order.
• Per-table and overall change throughput (changes/sec), % complete, and ETA are shown live — see Sync Mode Comparison.

Requirements & fallback

• Source must be SQL Server Standard Edition or higher (Express and Web editions do not support CDC) with SQL Server Agent running.
• If CDC isn't available, Assessment recommends Incremental sync instead (requires a watermark column and primary key on each table).

🔒 Encryption & Secure Connections

Endrias Bridge connects via SQLAlchemy connection strings. Append the engine-specific SSL/TLS parameters below whenever the source or target is reachable over a public network — including any cloud-hosted database.

☁️ Working with Cloud-Hosted Databases

Azure SQL Database / Managed Instance, AWS RDS / Aurora, Google Cloud SQL, and SQL Server / MySQL / PostgreSQL running on a cloud VM all work as a standard source or target — just supply the cloud endpoint hostname, port, and credentials on the connection screen.

• Allow-list the public IP address of the machine running Endrias Bridge in the cloud database's firewall / security group rules.
• Cloud-hosted databases almost always require SSL/TLS — see Encryption & Secure Connections.
• For large or long-running migrations, run Endrias Bridge on a VM in the same region/VNet/VPC as the target to minimize latency — see Hardware & Sizing.
• SQL Server CDC requires Standard Edition or higher — check the tier of a managed instance (e.g. Azure SQL Database Business Critical/General Purpose, or AWS RDS SQL Server Standard/Enterprise) before relying on CDC sync.

🗺️ Compatibility Matrix

Shown on the Assessment tab as Compatibility Issues, based on the selected source/target engines.

SQL Server → PostgreSQL

• IDENTITY → SERIAL / GENERATED ALWAYS AS IDENTITY
• DATETIME → TIMESTAMP
• NVARCHAR(MAX) → TEXT
• BIT → BOOLEAN
• TOP N → LIMIT N
• Stored procedures need rewriting in PL/pgSQL
• CHECK constraints with functions may differ

SQL Server → MySQL

• IDENTITY → AUTO_INCREMENT
• NVARCHAR → VARCHAR (UTF8MB4)
• TOP N → LIMIT N
• Schema namespaces may need adjustment
• Clustered index behaviour differs

PostgreSQL → MySQL

• SERIAL → AUTO_INCREMENT
• BOOLEAN → TINYINT(1)
• LIMIT y OFFSET x → LIMIT x,y
• Arrays / JSONB not natively supported in MySQL 5.x

MySQL → PostgreSQL

• AUTO_INCREMENT → SERIAL
• TINYINT(1) → BOOLEAN
• ENGINE=InnoDB → remove (not applicable)
• LIMIT x,y → LIMIT y OFFSET x

Oracle → PostgreSQL

• NUMBER → NUMERIC
• VARCHAR2 / NVARCHAR2 → VARCHAR / TEXT
• SEQUENCE + trigger → SERIAL / GENERATED ALWAYS AS IDENTITY
• ROWNUM → LIMIT / OFFSET
• DUAL table not needed (SELECT expr without FROM works directly)
• DECODE() → CASE WHEN ... END
• NVL() → COALESCE()
• (+) outer join syntax → ANSI LEFT/RIGHT JOIN
• CONNECT BY → WITH RECURSIVE (recursive CTE)
• PL/SQL packages / procedures need rewriting in PL/pgSQL

PostgreSQL → Oracle

• SERIAL / IDENTITY → SEQUENCE + trigger (or GENERATED ALWAYS AS IDENTITY on 12c+)
• TEXT → CLOB / VARCHAR2(4000)
• LIMIT / OFFSET → ROWNUM or FETCH FIRST n ROWS ONLY (12c+)
• BOOLEAN → NUMBER(1) (no native boolean before Oracle 23c)
• WITH RECURSIVE → CONNECT BY or recursive WITH (11g+)
• PL/pgSQL functions need rewriting in PL/SQL

Oracle → MySQL

• NUMBER → DECIMAL / INT depending on precision
• VARCHAR2 / NVARCHAR2 → VARCHAR (utf8mb4)
• SEQUENCE + trigger → AUTO_INCREMENT
• ROWNUM → LIMIT
• DECODE() → CASE WHEN ... END
• NVL() → IFNULL() / COALESCE()
• CONNECT BY → recursive CTE (MySQL 8.0+) or application-side recursion
• PL/SQL packages / procedures need rewriting as MySQL stored procedures

MySQL → Oracle

• AUTO_INCREMENT → SEQUENCE + trigger (or IDENTITY column on 12c+)
• TINYINT(1) → NUMBER(1)
• LIMIT x,y → OFFSET x ROWS FETCH NEXT y ROWS ONLY (12c+) or ROWNUM
• ENGINE=InnoDB → remove (not applicable)
• ON DUPLICATE KEY UPDATE → MERGE statement

Oracle → SQL Server

• NUMBER → DECIMAL / INT / BIGINT depending on precision
• VARCHAR2 / NVARCHAR2 → VARCHAR / NVARCHAR
• SEQUENCE + trigger → IDENTITY
• ROWNUM → TOP N or OFFSET-FETCH
• DECODE() → CASE WHEN ... END
• NVL() → ISNULL() / COALESCE()
• CONNECT BY → recursive CTE (WITH ... AS)
• PL/SQL packages / procedures need rewriting in T-SQL

SQL Server → Oracle

• IDENTITY → SEQUENCE + trigger (or IDENTITY column on 12c+)
• NVARCHAR(MAX) → CLOB / NVARCHAR2(4000)
• TOP N → ROWNUM or FETCH FIRST N ROWS ONLY
• ISNULL() → NVL()
• GETDATE() → SYSDATE / SYSTIMESTAMP
• T-SQL stored procedures / functions need rewriting in PL/SQL

Any other pair

• Review data type mappings for the target platform
• Check stored procedure / function syntax compatibility
• Verify index and constraint naming conventions
• Test NULL handling and default values

🔧 Data Type Conversions

Applied automatically when the source and target engines differ — both at schema creation time (column type) and at row-insert time (value conversion, with truncation/rounding reported as WARNING lines in the migration log).

At schema creation time, source-engine artifacts that the target won't accept are also stripped from the generated CREATE TABLE: column collations (e.g. SQL Server SQL_Latin1_General_CP1_CI_AS) and server-side defaults (e.g. SQL Server getdate() / newid()). Row values are copied explicitly, so column defaults aren't needed for the copy.

Row-value conversions

Independent of the table above, individual values are coerced so inserts don't fail against the target type:

• UUID objects → strings (when the target column is not a UUID type)
• dict / list values → JSON text (for String/Text targets)
• timedelta → string
• memoryview / bytearray → bytes
• bool → int (for Numeric targets)
• Decimal values rounded to the target column's scale (reported as WARNING: ... rounded ...)
• Strings longer than the target VARCHAR(n) truncated (reported as WARNING: ... truncated ...)

⚡ Performance & Tuning

Data is copied in batches (fetch + multi-row INSERT). Throughput is driven by a few levers, most of which apply automatically:

acme_audit observed performance

The acme_audit database (52 GB, two schemas: auditdata and analyticsdata) was observed to take 17+ hours on a laptop over VPN with the default 5,000-row batch size. Root causes: default batch size (5,000 rows) and two WAN hops per round-trip (Azure SQL → laptop → AWS RDS). Expected duration with recommended settings (100k batch size, VM co-located with source): 35–45 minutes. See Troubleshooting → Migration Is Too Slow for the step-by-step runbook.

🖥️ Hardware & Sizing

The Assessment tab measures the source database size and recommends a staging-host tier for the migration:

• Use Windows Server 2022 for the migration/staging VM where possible.
• Keep the source, staging host, and target in the same region / VNet / VPC to minimize latency and avoid cross-region egress costs.
• For large migrations, use a dedicated VM with no other workloads running on it during the migration window.

Email Alerts

MigrationBridge can send an HTML email when a migration event occurs. Configure the [alerts] section in C:\MigrationTool\migrationbridge.conf. All alerts are disabled by default — leave smtp_host blank to keep them off.

Supported events

Configuration — Office 365 / STARTTLS (port 587)

[alerts]
smtp_host     = smtp.office365.com
smtp_port     = 587
smtp_use_tls  = true
smtp_use_ssl  = false
smtp_user     = migrations@endriasbridge.com
smtp_password = YourAppPassword
alert_to      = dba@endriasbridge.com
alert_from    = MigrationBridge <migrations@endriasbridge.com>
alert_on      = error,fatal,complete

Configuration — SSL (port 465)

[alerts]
smtp_host     = smtp.gmail.com
smtp_port     = 465
smtp_use_tls  = false
smtp_use_ssl  = true
smtp_user     = you@gmail.com
smtp_password = YourAppPassword
alert_to      = you@gmail.com
alert_on      = error,fatal

What the email contains

• error — database name, table name, error text, rows copied before the error
• fatal — database name, full exception text, source and target connection summary (password masked)
• complete — database name, table count, sync mode, total duration

🧬 Configuration & Extensibility Reference

Endrias Bridge settings

Guest-init plugin & metadata API

The guest-initialization side of Endrias Bridge (the Setup Wizard's first-boot pipeline) is driven by the same migrationbridge.conf and is extensible with custom metadata sources and plugins. For the full configuration keys, plugin pipeline, and metadata source reference, see:

• SOP → Configuration Reference
• SOP → Plugin Reference

🛟 Service, Logs & Troubleshooting

For the guest-initialization side of Endrias Bridge (the Windows service / first-boot plugin pipeline), see the Standard Operating Procedure:

• Architecture
• Check Service Status
• Read the Logs
• Service Management
• Configuration Reference
• Plugin Reference
• Troubleshooting
• Event Log Commands

For Endrias Bridge logs and persistent error logs, see User Guide → Logs & Error Logs.

📊 Comparison Report Interpretation

After a migration completes, the db_comparison CSV (produced by running the comparison tool against source and target) is the primary sign-off artifact. Each row has a Status of MATCH, SOURCE ONLY, or TARGET ONLY. Here is how to read each status:

NoSQL engines: Comparison is supported for MongoDB, Cosmos DB, DynamoDB, Redis, Cassandra, and Elasticsearch. For NoSQL pairs, the comparison shows collection/index/key-group names and document/item counts (MATCH / MISMATCH / SOURCE ONLY / TARGET ONLY). Schema-level comparison (columns, indexes, constraints) is not applicable for NoSQL engines.

Why TARGET ONLY entries are usually expected

A healthy comparison report for an enterprise database may contain a large block of TARGET ONLY stored procedures, functions, and table types. These come from application schemas that are deployed via SSDT / application installers — not via MigrationBridge — and exist on the shared RDS instance but not in the source Azure SQL database being compared. Common schemas:

Pass criteria for a completed migration

• Zero SOURCE ONLY rows — every source object is present on target
• All table row counts MATCH — data volume is identical
• All column types MATCH — no schema drift
• All constraints and indexes MATCH — PKs, FKs, unique constraints all present
• TARGET ONLY entries limited to the application-deployed schemas listed above

A report that meets all five criteria can be signed off as PASS.

Known validated databases

acme_audit — detail

The db_comparison-toaudit.csv comparison run against acme_audit (schemas auditdata and analyticsdata) returned 27/27 tables MATCH, 570/570 columns MATCH, 28/28 constraints MATCH, 29/29 indexes MATCH, and 56/56 statistics MATCH. Zero SOURCE ONLY entries. TARGET ONLY entries were exclusively application-schema objects (coreapi, priceapi, customapi, etc.) deployed independently of the migration. Status: PASS — signed off June 2026.

acme_erp — detail (INCOMPLETE — pending re-migration)

The db_comparison-acme_erp.csv comparison run against acme_erp shows that all 99 data tables (schemas coredata, salesdata, customdata, referencedata, catalogdata, limitsdata, mappingdata, rulesdata) are SOURCE ONLY — target column shows — for every table row count, meaning the tables were never created on the RDS target. The migration did not land the data schema.

The SSDT-deployed API objects (148 stored procs, 7 functions, 92 TVP types across coreapi, priceapi, customapi, etc.) all show MATCH — those were deployed independently and are healthy.

Remediation — required steps:

1. Rebuild MigrationBridge.exe with PyInstaller to pick up all the current build fixes.
2. Run a Full migration (not Resume) from an Azure VM or EC2 instance.
3. The tool automatically handles any partial state on the target — no manual DROP needed. See Troubleshooting → Full vs Resume.
4. After migration, re-run the comparison tool and verify all 99 data tables show MATCH.
5. System-versioning on the 38 temporal tables (salesdata, referencedata, catalogdata, limitsdata, mappingdata, rulesdata) will be re-enabled automatically by the current build at the end of the migration.

📣 Warnings & Messages Reference

Messages that can appear in the Migration tab's log:

❓ FAQ

Which databases are supported?

SQL Server, PostgreSQL, MySQL, Oracle, and SQLite as both source and target, via SQLAlchemy. See the Compatibility Matrix for per-pair notes.

Do I need to write any SQL to migrate schema and data?

No. The Migration tab reflects the source schema, applies any required data type conversions, creates the tables on the target, and copies the data in chunks.

Does the target database have to exist first?

No. If the target database named on the connection screen doesn't exist, Endrias Bridge creates it automatically (connecting to the server's maintenance database) before creating schemas and tables - including names with dots like dba.stackexchange.com. This needs an account with permission to create databases (PostgreSQL CREATEDB, MySQL CREATE, SQL Server dbcreator); if the account lacks it, the log shows a clear message telling you to create the database manually. SQLite creates its file automatically.

Can the target database have a different name from the source?

Yes. Source and target are independent connections, each with its own Database field - the names don't have to match (e.g. AdventureWorks2019 → analytics_warehouse). Only the schema namespaces inside the database (e.g. HumanResources, Person, Sales) are recreated by the same name within your differently-named target database; the database/catalog name itself is whatever you set on the target connection.

Are stored procedures and views migrated?

For same-engine migrations (e.g. SQL Server → SQL Server / Azure SQL, MySQL → MySQL, PostgreSQL → PostgreSQL), procedures, views, triggers, and functions are applied to the target automatically after the tables and data (best-effort: applied views → functions → procedures → triggers, with one retry pass for inter-object dependencies; failures are logged, never fatal). Across different engines they can't be auto-translated - use the Schema Objects tab to export and rewrite them.

Are system-versioned (temporal) tables supported?

The temporal table and its history table migrate as ordinary tables, so all data comes across. The system-versioning itself (PERIOD FOR SYSTEM_TIME, GENERATED ALWAYS AS ROW START/END, SYSTEM_VERSIONING = ON) is detected and scripted by the Schema Objects tab for you to apply. Re-enabling versioning after migration depends on the target engine:

• SQL Server / Azure SQL target — fully automatic. The Schema Objects tab generates a T-SQL re-enable script and can apply it in one click.
• Oracle 23ai+ target — the Schema Objects tab generates an Oracle ALTER TABLE … ADD PERIOD FOR SYSTEM_TIME + ADD VERSIONING USE HISTORY TABLE script. The already-migrated SQL Server history table is wired in directly so pre-migration history is immediately queryable.
• Oracle 11g R2–21c target — the Schema Objects tab generates a Flashback Data Archive (FDA) script: CREATE FLASHBACK ARCHIVE + ALTER TABLE … FLASHBACK ARCHIVE. FDA tracks all post-migration DML automatically; the migrated history table covers pre-migration history.
• PostgreSQL / MySQL target — no native equivalent; the Schema Objects tab generates a trigger-based emulation pattern (history table + BEFORE UPDATE/DELETE triggers).

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

How do I keep the target in sync after the first migration?

Use Incremental sync mode if your tables have a watermark column (e.g. updated_at, RowVersion) and a primary key, or SQL Server CDC sync mode if the source is SQL Server Standard Edition or higher with CDC enabled.

What if my source is too large to estimate an ETA up front?

If a table's row count can't be determined, the migration log notes that progress/ETA is approximate for that table, but the copy still proceeds normally — only the percentage/ETA display is affected.

Where do I find error details after a failed migration?

Check the Migration tab's log first, then the persistent error logs via User Guide → Logs & Error Logs (folder configurable via error_log_dir in migrationbridge.conf).

Can I export the discovered schema objects (procedures, views, etc.)?

Yes — the Schema Objects tab can export everything found to a single .sql file, or apply same-platform objects directly to the target.

Why did my decimal columns fail with "Converting decimal loses precision"?

This is a pyodbc fast_executemany quirk: the driver infers the decimal parameter type from the first row of a batch, and if a later row needs more integer digits (wider precision), the driver rejects the batch. As of the current build, these batches are automatically caught and retried row-by-row on a plain (non-fast_executemany) connection — no data loss, no manual action required. See Troubleshooting → Converting decimal loses precision.

Why were some SEQUENCE objects missing after a resume run?

In a previous build, SEQUENCE objects were only created during a full schema+data migration. Resume or data-only runs skipped the step, causing INSERT failures on tables whose DEFAULT constraint references a sequence. As of the current build, sequence creation runs before the data copy on all paths (full, resume, and data-only).

Why did my temporal tables not have system-versioning after migration?

A missing import in a previous build caused a NameError on the ALTER TABLE … SYSTEM_VERSIONING = ON step. Tables and data were copied successfully, but versioning was not re-enabled. Fixed in the current build. If your database was migrated with a previous build, use Re-apply Schema Objects from the Schema Objects tab to re-enable system-versioning without touching the data.

My migration is running much slower than expected — what should I check?

The three most common causes, in order of impact:

1. Batch size still at default (5,000). Set db_migration_chunk_size = 100000 in migrationbridge.conf and restart the GUI. At 100k batches vs 5k batches, round-trips drop 20×. Verify the change loaded by checking the migration log for Copying in batches of 100000 rows.
2. Running from a laptop over VPN. Each batch makes two WAN hops (source read + target write). Move MigrationBridge to an Azure VM co-located with the Azure SQL source, or an EC2 instance co-located with the RDS target. Either eliminates one hop entirely and cuts latency from 20–80 ms to <2 ms.
3. RDS IOPS exhausted. Check CloudWatch WriteLatency during a live run — if >20 ms, switch to gp3 storage and provision 6,000–12,000 IOPS for the migration window. Scale back afterwards.

For the full diagnosis runbook with CloudWatch checks, expected throughput numbers, and the acme_audit case study (17 hrs → ~40 min), see Troubleshooting → Migration Is Too Slow.

What does a "TARGET ONLY" entry in the comparison report mean?

It means an object exists on the target RDS instance but not in the source database being compared. For enterprise deployments this is almost always expected — application-deployed schemas are installed on the shared RDS instance via SSDT or application installers, not via MigrationBridge. Only investigate TARGET ONLY entries under schemas that were part of the migration itself (e.g. auditdata, analyticsdata). See Comparison Report Interpretation for the full pass criteria.

Should I use Full migration or Resume if my previous migration did not complete?

It depends on what is already on the target:

• Data schema is missing (tables not created) — use Full migration. Resume skips schema creation (CREATE TABLE) entirely, so it will try to INSERT into tables that don't exist and fail for every table. Full migration runs drop_all(checkfirst=True) + create_all(checkfirst=True) first, which is a no-op for tables that don't exist, then copies all data. No manual DROP is needed — the tool self-manages everything.
• Tables exist but data copy was interrupted mid-run — use Resume. Resume compares source vs target row counts per table: tables that already match are skipped, partially-loaded tables are cleared (DELETE, not DROP) and re-inserted in FK-safe order, and missing tables are queued for a fresh copy.

For acme_erp (all 99 data tables absent from target), Full migration is required. See Troubleshooting → Full vs Resume.

Does migrating from Azure SQL to AWS RDS require special settings?

No manual changes are needed. Endrias Bridge detects the Azure SQL Database → AWS RDS for SQL Server pair and automatically applies DDL compatibility conversions: json → NVARCHAR(MAX), NullType (hierarchyid/spatial) → NVARCHAR(MAX), decimal precision clamped to 38, and Azure-only server defaults stripped. Each conversion is logged. See Azure SQL → AWS RDS Compatibility.